Redisのレプリケーション

マスター＆レプリカモデル

• マスターの更新内容を複数のレプリカに反映
• 主な目的は 高可用性の確保

---

実装

• レプリケーションは 非同期 → 遅延や一貫性の欠如が発生する可能性あり
• レプリカは基本的に 読み取り専用
• マスターを再起動すると、レプリカも再初期化され、データが消失する可能性あり

---

レプリケーションのメカニズム

1. レプリカが PSYNC を使用してマスターに同期をリクエスト
   → 現在のレプリケーションIDとオフセットを送信
2. マスターは自分のレプリケーションIDとレプリカのIDを比較
3. オフセットがレプリケーション・バックログに存在するか確認
   • 存在する → 部分同期が可能
   • 存在しない／リクエストサイズがバックログを超える → 全体同期

---

全体同期（Full Sync）

1. マスターが子プロセスをフォーク（BGSAVE）
2. マスターのメモリ内容をスナップショット化（RDBファイル生成）
3. RDBファイルをディスクに保存し、ネットワーク経由でレプリカへ送信

※ ネットワーク帯域に負荷がかかる場合あり
※ 初回のレプリケーションは全体同期が必要
※ ディスクレスレプリケーション（RDBをディスクに書かず、直接ソケットに送信）も可能で、よく使用される

---

全体同期の補足

• すでにレプリカにRDBファイルが存在する場合、一貫性のため既存ファイルは削除される
• 同期完了前のレプリカは、古い（stale）データをクライアントに返す可能性がある
  • replica-serve-stale-data=false を設定すれば、クライアントへは エラーを返す

---

複数レプリカの同期

• 2台目以降のレプリカが同期を開始したタイミングにより動作が異なる
  • 既存のBGSAVEが進行中 → そのスナップショットを再利用
  • BGSAVE完了後 → 新たにBGSAVEを実行

---

レプリカとTTL（Time to Live）

• expire（期限切れ）したキーは RDBファイルに含まれない
• AOF（Append Only File）では DEL コマンドとしてレプリカに転送される

---

同期的レプリケーション（セミシンク）

• データ損失を防ぐために WAIT コマンドが使用できる
  • 指定した数のレプリカから応答が返るまでクライアントは待機
  • レプリカの応答遅延検出にも有効

---

ヘルスチェック機構

• マスターは repl-ping-replica-period に従って、定期的に全レプリカへPINGを送信
• レプリカは REPLCONF ACK <OFFSET> を返し、処理済みのオフセットを報告
• マスターは各レプリカからの最終ACK時刻を記録

設定パラメータ:

• min-replicas-max-lag:
  → マスターが「レプリカが遅延している」と判断する最大許容時間
• min-replicas-to-write:
  → 有効なレプリカがこの数未満の場合、マスターは書き込みを停止してエラーを返す
• repl-timeout:
  → マスターからのPINGがこの時間を超えて届かない場合、レプリカは再同期を行う

---

フェイルオーバー（Failover）

• Redisは 自動フェイルオーバー機能を提供しない
  • レプリカをマスターに昇格させるには REPLICAOF NO ONE を使用
  • 一部マネージドサービス（例: AWS ElastiCache など）では自動フェイルオーバーをサポート
• フェイルオーバー中は CLIENT PAUSE によって、クライアントからのリクエストを一時停止可能