2

今のところ、redis 2.8.7 をキャッシュ ストレージとして使用しようとしています (booksleeve クライアントを使用する .NET Web アプリケーションから)。現時点では非常に興味深くエキサイティングな作業のようです。redis のドキュメントは非常に優れていますが、実際の実務経験が不足しているため、予想される構成を適切に行う方法についていくつか質問があります。

主な構成ソースとして次の記事を取り上げました。

  1. 自動起動機能を備えた redis のインストール (init スクリプトを使用して、再起動後にすべてが適切に再開されるようにします) : http://redis.io/topics/quickstart
  2. Azure への Redis のデプロイ: http://haishibai.blogspot.com/2014/01/walkthrough-setting-up-redis-cluster-on.html

最初のアイデア/仮定 - 1 つの redis マスターと 2 つのスレーブ インスタンスを Linux Ubuntu で実行することです。インスタンスの高可用性を提供するために、センチネルを使用することにしました。したがって、現時点で予想される構成は次のようになります。

  1. MasterInstance: VM1 (Linux、Ubuntu)、ポート: 6379 (Linux の再起動時に自動起動)
  2. Slave1: VM2 (linux、ubuntu)、ポート: 6380 (linux の再起動時に自動起動): slaveOf MasterID 6379
  3. Slave2: VM3 (linux、ubuntu)、ポート: 6379 (linux の再起動時に自動起動): slaveOf MasterIP 6379

VM が起動した後、2 つのスレーブが正常に接続され、マスターと同期していることがわかります: マスターからのトレース サンプル:

[1120] 25 Mar 14:11:18.629 - 1 clients connected (0 slaves), 793352 bytes in use
[1120] 25 Mar 14:11:18.634 * Slave asks for synchronization
[1120] 25 Mar 14:11:18.634 * Full resync requested by slave.
[1120] 25 Mar 14:11:18.634 * Starting BGSAVE for SYNC
[1120] 25 Mar 14:11:18.634 * Background saving started by pid 1227
[1227] 25 Mar 14:11:18.810 * DB saved on disk
[1227] 25 Mar 14:11:18.810 * RDB: 0 MB of memory used by copy-on-write
[1120] 25 Mar 14:11:18.836 * Background saving terminated with success
[1120] 25 Mar 14:11:18.837 * Synchronization with slave succeeded
[1120] 25 Mar 14:11:23.829 - DB 0: 2 keys (0 volatile) in 4 slots HT.
[1120] 25 Mar 14:11:23.829 - DB 2: 4 keys (0 volatile) in 4 slots HT.
[1120] 25 Mar 14:11:23.829 - 0 clients connected (1 slaves), 1841992 bytes in use
[1120] 25 Mar 14:11:29.011 - DB 0: 2 keys (0 volatile) in 4 slots HT.
[1120] 25 Mar 14:11:29.011 - DB 2: 4 keys (0 volatile) in 4 slots HT.
[1120] 25 Mar 14:11:29.011 - 0 clients connected (1 slaves), 1841992 bytes in use
[1120] 25 Mar 14:11:29.826 - Accepted 168.62.36.189:1024
[1120] 25 Mar 14:11:29.828 * Slave asks for synchronization
[1120] 25 Mar 14:11:29.828 * Full resync requested by slave.
[1120] 25 Mar 14:11:29.828 * Starting BGSAVE for SYNC
[1120] 25 Mar 14:11:29.828 * Background saving started by pid 1321
[1321] 25 Mar 14:11:29.871 * DB saved on disk
[1321] 25 Mar 14:11:29.871 * RDB: 0 MB of memory used by copy-on-write
[1120] 25 Mar 14:11:29.943 * Background saving terminated with success
[1120] 25 Mar 14:11:29.946 * Synchronization with slave succeeded
[1120] 25 Mar 14:11:34.195 - DB 0: 2 keys (0 volatile) in 4 slots HT.
[1120] 25 Mar 14:11:34.195 - DB 2: 4 keys (0 volatile) in 4 slots HT.
[1120] 25 Mar 14:11:34.195 - 0 clients connected (2 slaves), 1862920 bytes in use

次に、センチネル インスタンスをセットアップする必要があります ...

  1. sentinel.conf を最初の redis-stable パッケージから redis を実行している 3 つの VM (1 つのマスターと両方のスレーブ) にコピーしました。

  2. 各構成内で、次の変更を行いました。

    センチネル モニター mymaster MasterPublicIP 6379 2

  3. 各 VM で、次のコマンド ラインを使用してセンチネルを開始しました。

    redis-server /etc/redis/sentinel.conf -- センチネル

その後、センチネルが正常に開始されたという応答を受け取りました...すべての VM で... 3 つのセンチネル インスタンスをすべて開始した後、次のトレース サンプルを取得しました (sentinel.conf ファイルは、スレーブおよび他のセンチネル インスタンスに関する情報で更新されました):

[1743] 25 Mar 16:35:46.450 # Sentinel runid is 05380d689af9cca1e826ce9c85c2d68c65780878
[1743] 25 Mar 16:35:46.450 # +monitor master mymaster MasterIP 6379 quorum 2
[1743] 25 Mar 16:36:11.578 * -dup-sentinel master mymaster MasterIP 6379 #duplicate of     10.119.112.41:26379 or 83666bdd03fd064bcf2ec41ec2134d4e1e239842
[1743] 25 Mar 16:36:11.578 * +sentinel sentinel 10.119.112.41:26379 10.119.112.41 26379 @ mymaster 168.62.41.1 6379
[1743] 25 Mar 16:36:16.468 # +sdown sentinel 10.175.220.134:26379 10.175.220.134 26379 @ mymaster 168.62.41.1 6379
[1743] 25 Mar 16:36:40.876 * -dup-sentinel master mymaster MasterIP 6379 #duplicate of 10.175.220.134:26379 or fe9edeb321e04070c6ac6e28f52c05317a593ffd
[1743] 25 Mar 16:36:40.876 * +sentinel sentinel 10.175.220.134:26379 10.175.220.134 26379 @ mymaster 168.62.41.1 6379
[1743] 25 Mar 16:37:10.962 # +sdown sentinel 10.175.220.134:26379 10.175.220.134 26379 @ mymaster 168.62.41.1 6379

トレース サンプルに基づいて、次の質問があります。誰かがそれらを明確にすることができれば、それは素晴らしいことです:

  1. ここに -dup-sentinel master mymaster 構成が表示されるのはなぜですか... 同じマスターインスタンスに 3 つのセンチネルを追加したためですか (おそらく、redis のインスタンスごとに 1 つのセンチネルを登録する必要があるため、1 つのセンチネルがマスターと他の 2 つの歩哨 - 2 つのスレーブに)?
  2. redisサーバーが起動される方法でセンチネルを起動する方法(VMが再起動されても自動的に)? - 同じアクションを実行して、通常の redis-server インスタンスとして登録する必要がありますか?
  3. Sentinel インスタンスを redis-server と同じ VM でホストしても問題ありませんか?

その後、新しいパテ接続を開始し、redis-cli を開始してセンチネル API を操作しましたが、以下のコマンドで次の応答を受け取りました。

127.0.0.1:6379> SENTINEL masters

(error) ERR unknown command 'SENTINEL'

私はここで愚かなことをしたと思います... :( 私が間違ったことと、ターミナル接続からセンチネル API をテストする方法は?

よろしくお願いします。

4

2 に答える 2

14

「SENTINEL masters」はRedisセンチネルで実行する必要があると思います

redis-cli -p 26379 (デフォルトのセンチネル ポート)

次に発行

127.0.0.1:26379> センチネルマスター

そしてあなたは何かを得るでしょう

1) "name" 2) "mymaster" 3) "ip" 4) "127.0.0.1" 5) "port" 6) "6379" . . .

VM が再起動されてもセンチネルを自動的に開始するには

最初に、sentinel.conf に daemonize yes を設定します

ここで init スクリプト ( https://github.com/antirez/redis/blob/unstable/utils/redis_init_script ) を変更して、センチネル ポートと .conf の場所を反映させます。

$EXEC $CONF --sentinel # Sentinel モードで開始

残りはredisサーバーで行ったのと同じです。

于 2014-05-13T18:39:17.487 に答える
1

まず、マスターで Sentinel を実行しません。Sentinel は、マスターの障害を検出するように設計されています。マスターと同じシステムで Sentinel を実行すると、システムを失うと Sentinel も失われます。同じ理由で、スレーブを追加のテスト ポイントとして使用しないでください。

クライアントが実行されている場所から Sentinel を実行して、ネットワークの停止をテストしていることを確認します。

次に、センチネル構成にスレーブ情報を追加したと述べています。Sentinel でスレーブを構成する必要はありません。マスターを通じて検出されます。各スレーブにセンチネル監視コマンドを追加したのではないかと思います。これにより、実際に監視の試行が重複することになります。

第三に、@yofpro が述べたように、sentinel コマンドを実行するには、Redis マスターまたはスレーブではなく、sentinel に接続する必要があります。

于 2014-05-14T18:47:38.547 に答える