はじめに
違いは、プライマリがクライアントにコミット完了を返すとき、レプリカの応答を待つかどうかです。待つ同期複製はデータ保護を優先し、待たない非同期複製は応答速度を優先します。
対象読者：RDBのレプリケーションをこれから学ぶ人
違いを比較
| 観点 | 同期複製 | 非同期複製 |
|---|---|---|
| コミット応答 | レプリカの確認を待つ | レプリカを待たない |
| 書き込み応答 | 遅くなりやすい | 速くしやすい |
| 障害時の更新損失 | 設定した確認条件の範囲で抑えやすい | レプリカ未反映分を失う可能性がある |
| レプリカの読み取り | 確認条件による | 古いデータを読む可能性がある |
同期複製
プライマリで更新した後、設定された確認条件をレプリカが満たすまで、プライマリはクライアントにコミット完了を返しません。
レプリカ側の確認条件は製品や設定によって異なります。たとえばPostgreSQLでは、スタンバイがトランザクションログを書き込んだことなどを確認条件にできます。
- 利点：確認済みの更新がレプリカにも届いてから応答するため、プライマリ障害時に失われる更新を抑えられる
- 注意点：レプリカやネットワークの応答を待つ分、書き込みの応答が遅くなる。レプリカに障害があると、設定によっては書き込みが待たされたり止まったりする
非同期複製
プライマリは自身の更新を確定すると、レプリカの応答を待たずにクライアントへ完了を返します。更新はその後、レプリカへ送られて反映されます。
- 利点：レプリカの応答待ちがなく、書き込みへの影響を抑えやすい
- 注意点：プライマリ障害のタイミングによっては、レプリカに届いていない更新が失われることがある。また、レプリカの読み取り結果が少し古い場合がある
どちらを選ぶか
更新を失うリスクを小さくすることが最優先なら同期複製、書き込みの応答速度やプライマリへの負荷を重視するなら非同期複製が候補になります。
実際には「同期なら絶対にデータを失わない」とは限りません。どのレプリカの、どの反映段階まで確認するか、障害時に書き込みを止めるか、といった設定も合わせて確認します。
まとめ
同期複製はレプリカの確認を待ち、非同期複製は待たずに応答します。その違いが、書き込みの応答速度と障害時に失う可能性のある更新量に現れます。
参考資料