やあ。Redisの世界へようこそ。
Redisを触り始めると、必ず突き当たる壁がある。それが「レプリケーション」、つまり「どうやって複数のサーバーで同じデータを持ち続けるか」という課題だ。
多くの人は「SYNC」や「PSYNC」というコマンド名を見て、「なんだか難しそうな同期処理だな」と身構えてしまう。でも大丈夫。この仕組みは、実は私たちの日常生活にある「ある光景」と全く同じなんだ。
今日は、Redisの心臓部の一つである「同期プロセス」の本質を、肩の力を抜いて紐解いていこう。
—
1. 同期は「日記の共有」だと考えよう
想像してみてほしい。君には「メインの日記帳（マスター）」と、そのコピーを取るための「控えの日記帳（レプリカ）」があるとする。
もし、レプリカがしばらくの間、メインの日記帳の内容を見られなかったらどうなるだろう？
戻ってきたとき、二つの選択肢があるよね。
1. 最初から最後まで、すべて書き写す（フル同期）
2. 見られなかった期間の分だけを追記する（部分同期）
Redisも全く同じことをやっているんだ。
—
2. フル同期（SYNC）：全てをゼロからやり直すとき
「フル同期」は、いわば「日記帳を丸ごとコピーする」行為だ。
レプリカが初めてメインサーバーに接続したとき、あるいは、あまりにも長い間切断されていて、どこから続きを書けばいいか分からなくなったときに発生する。
- 何が起きているか？
1. メインサーバーは、現在の全データをスナップショット（RDBファイル）として保存する。
2. そのファイルをレプリカに送る。
3. レプリカはそれを受け取り、自分自身のメモリに展開する。
「力技」だけど、確実な方法だね。 ただ、データ量が数ギガバイトあると、その間はネットワークやCPUに大きな負荷がかかる。だから、僕たちエンジニアは、できるだけこの「フル同期」を避けようとするんだ。
—
3. 部分同期（PSYNC）：効率的な「差分」の共有
さて、ここからがRedisの賢いところだ。Redisは「オフセット（Offset）」という数字を使って、「どこまで読んだか」を記録している。
- オフセットとは？
君が本を読んでいるときに挟む「しおり」のようなものだ。「今、何文字目まで読んだか」を常に記憶しているんだね。
もし、レプリカがちょっとした通信トラブルで一瞬切断されたとしても、再接続したときにこう言える。
「マスター、僕のしおりは『1005番目』までだよ。1006番目からの分だけ教えてくれ！」
これこそがPSYNC（Partial Resynchronization）だ。
メインサーバーは、直近の変更内容を一時的に「レプリケーションバッファ」という特別な場所に蓄えている。レプリカはそこから必要な分だけをもらう。これなら、全データを送る必要がないから、一瞬で同期が完了するんだ。
—
4. 運用の現場で知っておくべき「黄金律」
この仕組みを理解すると、現場でのトラブルシューティングが格段に楽になる。
- バッファサイズをケチらない
もしレプリケーションバッファが小さすぎると、ちょっとした通信エラーの間に「あ、もうその分のデータは消えちゃったよ」とマスターに言われ、結局「フル同期」を強制されることになる。大規模な環境では、このバッファを十分に大きく取ることが安定運用の鉄則だ。
- オフセットの正体を知る
`INFO replication` コマンドを叩いてみてほしい。
ターミナルで実行してみよう
127.0.0.1:6379> INFO replication
実行結果の一部
master_repl_offset:1234567 # これがマスターの「しおり」の現在地
repl_backlog_size:1048576 # これがバッファの容量（余裕があるか確認！）
この数字を見るだけで、「今どれくらい同期が進んでいるか」「バッファには余裕があるか」が一目瞭然になる。これがプロのエンジニアの視点だよ。
—
まとめ：Redisは「誠実な記録者」
Redisの同期プロセスは、決して魔法ではない。
「全部渡すか、足りない分だけ渡すか」。このシンプルで誠実なルールの上に、高速で高可用なデータベースが成り立っているんだ。
- フル同期：信頼を築くための「丸ごとコピー」。
- 部分同期：効率を最大化する「しおり（オフセット）を使った差分更新」。
この二つの違いを理解できれば、君はもうRedisのレプリケーションを恐れる必要はない。何かトラブルが起きても、「ああ、今しおりが合わなくなってフル同期に切り替わったんだな」と、冷静に判断できるはずだ。
次は、実際にこのオフセットがどう動いているか、テスト環境で実験してみるのも面白いかもしれないね。応援しているよ！
コメント