Skip to content
Latchkey

データベースレプリカとは? 負荷を分担するコピー

データベースレプリカは、プライマリと同期して保たれるデータベースのコピーであり、読み取りを提供したり、プライマリがダウンしたときにフェイルオーバーしたりするために使われます。

ほとんどのデータベースは、書き込みよりもはるかに多くの読み取りを受けます。レプリカはプライマリからデータをコピーし、書き込みは依然としてプライマリに向かいつつ、読み取りトラフィックをレプリカに分散できるようにします。レプリカはフェイルオーバー用のスタンバイも提供します。難点はレプリケーションのラグです。レプリカは任意の時点でプライマリよりわずかに遅れていることがあります。

レプリケーションの仕組み

書き込みはプライマリに向かい、プライマリはその変更を、それを適用する一つ以上のレプリカにストリームします。読み取りはレプリカから提供してプライマリの負荷を軽減できます。レプリカは、アプリケーションの書き込みに関する限り読み取り専用です。

チームがレプリカを使う理由

  • 読み取りのスケーリング: 読み取りトラフィックをレプリカに分散します。
  • 高可用性: プライマリが故障したらレプリカを昇格します。
  • 地理的な近接性: レプリカをユーザーの近くに配置します。
  • 重い分析的な読み取りを書き込み経路から隔離します。

レプリケーションのラグ

レプリカは通常プライマリより一瞬遅れています。自分の書き込みを早すぎるうちにレプリカから読むと、まだそれが見えないことがあります。これは結果整合性の具体的な形であり、紛らわしく断続的な振る舞いの頻繁な原因です。

テストの落とし穴

プライマリに書き込んでからレプリカを読むコードは、ローカル (単一データベース) では通り、本番 (読み書きの分離) では失敗しえます。実際のトポロジーを模したテスト、あるいはラグを考慮したテストが、これらのバグを出荷前に捕まえます。

デプロイとフェイルオーバー

レプリカの昇格は、どのノードがプライマリかを変えます。アプリケーションは再接続し、短い利用不可の期間を処理しなければなりません。ハッピーパスだけでなくフェイルオーバーもテストするパイプラインが、昇格をインシデントではなく日常的なものにします。

トポロジーを意識した統合テスト

CIでプライマリとレプリカの構成を再現するのは、単一インスタンスより重くなります。ウォームなrunner (Latchkeyなど) は、そのより現実的なトポロジーを毎回の実行で手頃に保ちます。

重要なポイント

  • データベースレプリカは、読み取りのスケーリングとフェイルオーバーに使われる同期されたコピーです。
  • レプリケーションのラグは、レプリカが短時間プライマリより遅れうることを意味します。
  • 自分の書き込みを早すぎるうちにレプリカから読むのは、典型的な断続的バグです。

関連ガイド