データベースフェイルオーバー戦略：Passive vs Active

金融システムでは、データは99.99%の時間利用可能でなければなりません。プライマリデータベースが故障した場合、システムはデータを失うことなく自動的にスタンバイレプリカに切り替わる必要があります。

レプリケーションモード

1. 同期レプリケーション: プライマリは、スタンバイがデータの受信を確認するまでコミットを待ちます。
   • 利点: データ損失ゼロ (RPO = 0)。
   • 欠点: 高いレイテンシ (レプリカでのネットワーク/ディスクの待ち時間)。
2. 非同期レプリケーション: プライマリはすぐにコミットし、後でレプリカにデータを送信します。
   • 利点: 非常に高速。
   • 欠点: クラッシュ時にデータが失われる可能性。

フェイルオーバーフロー

スプリットブレイン問題

2つのデータベースノードが両方とも自身を「プライマリ」であると考えている場合、両方が書き込みを受け入れる可能性があり、データの破損につながります。

解決策: クォーラムベースのメカニズム、またはRaftやPaxosアルゴリズムを使用して、常に1つのノードのみがリーダーとして選出されるようにする専用のクラスターマネージャー(PostgreSQLのPatroniなど)。

監視メトリクス

健全なフェイルオーバーを保証するために、以下を監視します。

• レプリケーションラグ: レプリカがプライマリからどれだけ遅れているか？
• Disk I/O: レプリカは受信ストリームの書き込みに苦労していないか？
• ロック競合: バキュームプロセスまたは長時間実行クエリがレプリケーションフローをブロックしていないか？

高可用性データベースの設計は、大規模な回復力のあるFinTechシステムを構築するための重要なスキルです。