レプリケーション

レプリケーションとは

レプリケーションは、データベースの内容を別のサーバーへ自動的に複製し続ける仕組みです。書き込みを受け付けるプライマリ(主)と、その複製であるレプリカ(副)を用意し、プライマリへの変更が自動でレプリカに反映されます。

目的は大きく2つです。

1. 読み取りの分散 — 参照クエリをレプリカに逃がし、プライマリの負荷を下げる
2. 障害への備え — プライマリが壊れたらレプリカを昇格させてサービスを続ける([[高可用性設計]])

同期方式 — 同期と非同期

複製のタイミングには方式があり、性能と安全性のトレードオフになります。

非同期の場合、レプリカへの反映が遅れるレプリケーションラグ(複製遅延)が発生します。「書き込んだ直後に読んだら古いデータが返った」という現象の典型的な原因です。

実務での構成例

• [[MySQL]] のソース/レプリカ構成 — Web サービスで最も普及した形。書き込みは1台、読み取りは複数台のレプリカへ振り分ける
• クラウドのマネージドDB — 「リードレプリカを追加」ボタン1つで構成できることが多い
• 昇格(フェイルオーバー)— プライマリ障害時にレプリカを新プライマリへ切り替える。自動化されていても切り替えの数十秒〜数分は書き込みが止まる点は把握しておく

初学者向けポイント

• レプリケーションはバックアップの代わりにならない — 誤って DELETE した操作も忠実に複製されるため。過去時点に戻る手段は [[バックアップとリカバリ]] で別途確保する
• 読み取り分散はできても、書き込みの分散はできない(プライマリは1台)。書き込みを分散したい場合は [[シャーディングとパーティショニング]] の領域
• アプリ側では「更新直後の読み取りはプライマリから読む」などラグ対策の設計が必要になることがある

関連技術とのつながり

• [[高可用性設計]] — レプリカ昇格による障害対策の中核
• [[MySQL]] — レプリケーション構成の普及に貢献した代表的RDB
• [[シャーディングとパーティショニング]] — 書き込みを分散したいときの次の手段
• [[バックアップとリカバリ]] — レプリケーションでは守れない「過去に戻る」手段
• [[トランザクションログとWAL]] — レプリカへ送られる変更履歴の実体。ラグは未適用ログの量

Q: レプリケーションで書き込みを受け付けるサーバーはどれ?
- [x] プライマリ
- [ ] レプリカ
- [ ] すべてのサーバーが均等に受け付ける
解説: 書き込みはプライマリ1台が受け、レプリカは複製として読み取りを担当します。

Q: 非同期レプリケーションで起こる「書き込んだ直後に古いデータが読める」現象の原因はどれ?
- [ ] インデックスの断片化
- [x] レプリケーションラグ(複製遅延)
- [ ] トランザクションのコミット忘れ
解説: 非同期方式では複製が後追いになるため、レプリカへの反映が遅れるレプリケーションラグが発生します。

Q: レプリケーションがバックアップの代わりにならない理由はどれ?
- [x] 誤った削除操作もそのまま複製されてしまうから
- [ ] レプリカは読み取りができないから
- [ ] 複製に必ず1日以上かかるから
解説: レプリケーションは操作を忠実に複製するため、誤操作から「過去時点に戻る」手段としてバックアップが別途必要です。