[ Redis]（https://cloud.tencent.com/product/crs?from=10680）は、永続性を実現するためにメモリストレージモデルとオプションのディスク書き込みを使用するオープンソースのキー値データストアです。トランザクション間の自動フェイルオーバー、メッセージングモードの公開/サブスクライブおよびその他の機能があります。 Redisクライアントには複数の言語で記述されたバージョンがあり、推奨されるクライアントは[そのWebサイト]（http://redis.io/clients）で提供されています。
実稼働環境では、少なくとも2つのノードでデータを複製することがベストプラクティスと見なされます。これにより、環境障害が発生した場合の回復が可能になります。これは、アプリケーションのユーザーベースが拡大した場合に特に重要です。また、パフォーマンスを変更したり影響を与えたりすることなく、本番データを安全に操作できます。
このチュートリアルでは、両方ともUbuntu16.04を実行している2つのサーバー間のレプリケーションを構成します。必要に応じて、このプロセスをより多くのサーバーに簡単に調整できます。
このチュートリアルを完了するには、2つのUbuntu16.04サーバーにアクセスする必要があります。サーバーをお持ちでない方は[こちら]（https://cloud.tencent.com/product/cvm?from=10680）から購入できますが、個人的には無料のTencent Cloud [Developer Lab]（https://cloud.tencent.com/developer/labs?from=10680）を使って実験し、[サーバーを購入]（ https://cloud.tencent.com/product/cvm?from=10680）。 Redisで使用されている用語によると、書き込み要求の受け入れを担当するプライマリサーバーをマスターサーバーと呼び、セカンダリ読み取り専用サーバーをスレーブサーバーと呼びます。
各サーバーでsudoが構成された権限を持つ非rootユーザーが必要です。さらに、このチュートリアルでは、基本的なファイアウォールを準備していることを前提としています。 [Ubuntu 16.04初期サーバーセットアップガイド]（https://cloud.tencent.com/developer/article/1007167?from=10680）に従って、これらの要件を満たすことができます。
開始する準備ができたら、このチュートリアルを読み続けてください。
まず、Redisを** master サーバーと slave **サーバーにインストールします。
[ChrisLeaのRedisPPA]（https://launchpad.net/~chris-lea/+archive/ubuntu/redis-server）を使用して、最新のRedisサーバーパッケージをインストールします。サードパーティのリポジトリを有効にする場合は注意が必要です。この場合、Chris Leaは成熟したインストールパッケージであり、高品質のパッケージが多数あります。
まず、PPAを2つのサーバーに追加します。
sudo apt-add-repository ppa:chris-lea/redis-server
ENTERを押してリポジトリを受け入れます。
次に、サーバーのローカルパッケージインデックスを更新し、次のコマンドを入力してRedisサーバーパッケージをインストールします。
sudo apt-get update
sudo apt-get install redis-server
これにより、Redisサーバーがインストールされ、サービスが開始されます。
次のコマンドを入力して、Redisが正常に実行されているかどうかを確認します。
redis-cli ping
次の応答が返されます。
PONG
これは、Redisが実行されており、ローカルクライアントからアクセスできることを意味します。
レプリケーションを設定する前に、Redisセキュリティモデルの意味を理解することが重要です。 Redisはネイティブ暗号化オプションを提供せず、信頼できるピアのプライベートネットワークに展開されていることを前提としています。
サーバーが分離されたネットワークで実行されている場合は、分離されたネットワークのIPアドレスにバインドするようにRedis構成ファイルを調整するだけで済みます。
各コンピューターでRedis構成ファイルを開きます。
sudo nano /etc/redis/redis.conf
bind行を見つけて、サーバー独自の分離されたネットワークIPアドレスを追加します。
bind 127.0.0.1 isolated_IP_address
ファイルを保存して閉じます。次のコマンドを入力して、サービスを再起動します。
sudo systemctl restart redis-server.service
Redisポートへのオープンアクセス：
sudo ufw allow 6379
これで、スタンバイサーバーのIPアドレスに -hフラグを指定した redis-cliコマンドを指定することにより、別のサーバーからサーバーにアクセスできるようになります。
redis-cli -h isolated_IP_address ping
次の応答が返されます。
PONG
Redisは、分離されたネットワークからの接続を受け入れることができるようになりました。
分離されていない、または制御できないネットワークの場合、他の方法でトラフィックを保護する必要があります。 Redisサーバー間のトラフィックを保護するには、次のような多くのオプションがあります。
上記のいずれかの方法を使用して、Redisマスターサーバーとスレーブサーバー間の安全な通信方法を確立します。各コンピューターがピアデバイス上のRedisサービスに安全に接続するために必要なIPアドレスとポートを知っておく必要があります。
Redisが各サーバーで実行され、安全な通信チャネルが確立されたので、それらの構成ファイルを編集する必要があります。 プライマリサーバーとなるサーバーから始めましょう。
お気に入りのテキストエディタで / etc / redis / redis.confを開きます。
sudo nano /etc/redis/redis.conf
まず、 tcp-keepalive設定を見つけて、以下に示すように60秒に設定します。これは、Redisがネットワークまたはサービスの問題を検出するのに役立ちます。
...
tcp-keepalive 60...
requirepassコマンドを見つけて、強力なパスワードに設定します。 Redisトラフィックは外部から送信される必要がありますが、これによりRedis自体の認証が提供されます。 Redisは高速で、パスワードの試行を制限しないため、ブルートフォースの試行を防ぐために、強力で複雑なパスワードを選択してください。
requirepass your_redis_master_password
最後に、使用シナリオによっては、いくつかのオプション設定を調整することをお勧めします。
Redisがいっぱいになったときに、古くてあまり使用されていないキーを自動的にトリミングしたくない場合は、自動キー削除をオフにすることができます。
maxmemory-policy noeviction
耐久性の保証を高めるために、添付ファイルの永続性のみを開くことができます。これにより、システム障害が発生した場合のデータ損失を最小限に抑えることができますが、ファイルが大きくなり、パフォーマンスがわずかに低下します。
appendonly yes
appendfilename "redis-staging-ao.aof"
終了したら、ファイルを保存して閉じます。
Redisサービスを再起動して、構成の変更を再読み込みします。
sudo systemctl restart redis-server.service
メインサーバーが構成されたので、以下でテストできます。
Redisクライアントを起動して、設定したパスワードで認証できるかどうかを確認します。
redis-cli
まず、認証なしでコマンドを試してください。
info replication
次の応答が返されます。
Redis master outputNOAUTH Authentication required.
これは予期されたものであり、Redisサーバーが認証されていない要求を正しく拒否していることを示しています。
次に、 authコマンドを使用して認証します。
auth your_redis_master_password
資格情報が受け入れられたことの確認を受け取る必要があります。
Redis master outputOK
コマンドを再試行すると、今回は成功するはずです。
info replication
Redis master output# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
認証を実行するときは、後で複製を確認できるようにテストキーを設定してください。
set test 'this key was defined on the master server'
完了後、オペレーティングシステムシェルに戻ります。
exit
マスターサーバーの準備ができたので、引き続きスレーブサーバーのセットアップを行います。
次に、スレーブサーバーがマスターインスタンスに接続できるように、いくつかの変更を加える必要があります。
スレーブサーバーで / etc / redis / redis.confを開きます。
sudo nano /etc/redis/redis.conf
まず、 slaveof行を見つけてコメントを外します。このディレクティブは、スペースで区切って、メインのRedisサーバーに安全に接続するために使用するIPアドレスとポートを使用します。デフォルトでは、Redisサーバーはローカルインターフェイス6379でリッスンしますが、各[Network Security]（https://cloud.tencent.com/product/ns?from=10680）メソッドは、外部パーティによって何らかの方法でデフォルト値を変更します。
使用する値は、ネットワークトラフィックを保護するために使用する方法によって異なります。
slaveofisolated_IP_address 6379）。slaveof 127.0.0.1 8000です）。slaveof 10.8.0.1 6379になります）。一般的な形式は次のとおりです。
slaveof ip_to_contact_master port_to_contact_master
次に、コメントを外して、Redisマスターサーバーに設定されたパスワードを masterauth行に入力します。
masterauth your_redis_master_password
不正アクセスを防ぐために、スレーブサーバーのパスワードを設定します。パスワードの複雑さに関する同じ警告がここに適用されます。
requirepass your_redis_slave_password
完了したら、ファイルを保存して閉じます。
変更を実装するためにサービスを再起動する前に、スレーブコンピューター上のローカルRedisインスタンスに接続し、 testキーが設定されていないことを確認しましょう。
redis-cli
次のように入力して、キーを照会します。
get test
次の応答が返されます。
Redis slave output(nil)
これは、ローカルRedisインスタンスに testという名前のキーがないことを意味します。次のコマンドを入力して、シェルに戻ります。
exit
スレーブサーバーでRedisサービスを再起動して、次の変更を実装します。
sudo systemctl restart redis-server.service
これにより、Redisスレーブ構成ファイルに加えたすべての変更が適用されます。
ローカルのRedisインスタンスに再度接続します。
redis-cli
Redisマスターサーバーと同様に、許可されていない場合、操作は失敗するはずです。
get test
Redis slave output(error) NOAUTH Authentication required.
ここで、前のセクションで設定したRedisスレーブのパスワードで認証します。
auth your_redis_slave_password
Redis slave outputOK
今回キーにアクセスしようとすると、それが利用可能であることがわかります。
get test
Redis slave output"this key was defined on the master server"
スレーブでRedisサービスを再起動すると、すぐにレプリケーションが開始されます。
レプリケーションに関する情報を報告するRedisのinfoコマンドを使用して確認できます。 master_hostと master_portの値は、使用する slaveofパラメーターオプションと一致する必要があります。
info replication
Redis slave output# Replication
role:slave
master_host:10.8.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:1387
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
Redisマスターサーバーで同じ情報を表示すると、次のように表示されます。
info replication
Redis master output# Replication
role:master
connected_slaves:1
slave0:ip=10.8.0.2,port=6379,state=online,offset=1737,lag=1
master_repl_offset:1737
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:1736
ご覧のとおり、マスターサーバーとスレーブサーバーは、定義された関係でお互いを正しく識別できます。
レプリケーションを設定する主な理由は、データの損失とダウンタイムを最小限に抑えて障害を処理することです。 Redisスレーブサーバーをマスターサーバーステータスにアップグレードして、Redisマスターステーションに障害が発生したときに書き込みストリームを処理できます。
これは、Redisスレーブサーバーから手動で行うことができます。 Redisクライアントを使用してログインします。
redis-cli
Redisを使用して、サーバーパスワードから認証します。
auth your_redis_slave_password
Redisスレーブサーバーをアップグレードする前に、テストキーを上書きしてみてください。
set test 'this key was overwritten on the slave server'
デフォルトでは、Redisスレーブは slave-read-only yesオプションを使用して読み取り専用として構成されているため、これは失敗するはずです。
Redis slave output(error) READONLY You can't write against a read only slave.
レプリケーションを無効にして現在のサーバーをマスター状態にプロモートするには、 slaveof値 nooneを指定してコマンドを使用します。
slaveof no one
Redis slave outputOK
コピー情報をもう一度確認してください。
info replication
Redis slave output# Replication
role:master
connected_slaves:0
master_repl_offset:6749
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
ご覧のとおり、スレーブサーバーがRedisマスターとして指定されています。
キーをもう一度上書きしてみてください。今回は成功するはずです。
set test 'this key was overwritten on the slave server'
Redis slave output
OK
サーバーからのRedis出力：
OK
構成ファイルは引き続きこのノードをRedisスレーブサーバーとして指定しているため、構成を変更せずにサービスを再起動すると、レプリケーションが再開されることに注意してください。また、ここでRedisマスターサーバーに使用されている設定を再適用する必要がある場合があることにも注意してください（たとえば、添付ファイルのみを有効にするか、エビクションポリシーを変更します）。
他にスレーブサーバーがある場合は、新しくアップグレードされたマスターサーバーをポイントして、変更の複製を続行します。これを行うには、 slaveofコマンドと新しいマスターサーバーの接続情報を使用できます。
レプリケーションを元のマスターサーバーに手動で復元するには、構成ファイルで使用されている値を含む slaveofコマンドを使用して、一時的なマスターサーバーとスレーブサーバーを元のマスターサーバーに戻します。
slaveof ip_to_contact_master port_to_contact_master
サーバーからのRedis出力：
OK
スレーブサーバーのキーをもう一度確認すると、Redisマスターサーバーが元の値に復元されていることがわかります。
get test
Redis slave output"this key was defined on the master server"
一貫性の理由から、マスターサーバーから再同期すると、スレーブサーバー上のすべてのデータが更新されます。
Redisスレーブの自動アップグレードには、アプリケーション層との調整が必要です。つまり、実装はアプリケーション環境に大きく依存するため、特定のアクションを提案することは困難です。
ただし、自動フェイルオーバーを完了するために必要な一般的な手順については説明できます。次の手順は、すべてのRedisサーバーが相互にアクセスするように構成されていることを前提としています。
slaveof new_master_ipnew_master_portを実行します。これにより、スレーブサーバーが古いマスターサーバーから複製するのを停止し、（現在は非推奨の）データを完全に破棄して、新しいマスターサーバーからの複製を開始します。サービスを元のマスターサーバーに復元した後、新しくアップグレードされたマスターサーバーを指すスレーブサーバーとしてサービスを再参加させたり、マスターサーバーとしての作業を再開したりできます（必要な場合）。
データを複製するためのRedisマスターサーバーとスレーブサーバーの2つのサーバーで構成される環境を確立しました。これにより、システムまたはネットワークに障害が発生した場合に冗長性が提供され、パフォーマンス上の理由から、読み取り操作を複数のサーバーに分散させることができます。これは、実行しているアプリケーションとインフラストラクチャのニーズに合わせてRedis構成を設計するための優れたチュートリアルですが、このテーマに関する完全なチュートリアルではありません。
Redisを使用してアプリケーションの要件を満たす方法の詳細については、[その他のRedisチュートリアル]（https://cloud.tencent.com/developer/column/1417/tag-10249?from=10680）を確認してください。その他のLinuxチュートリアルについては、[Tencent Cloud + Community]（https://cloud.tencent.com/developer?from=10680）にアクセスして詳細を確認してください。
参照：「Ubuntu16.04でRedisレプリケーションを構成する方法」
Recommended Posts