中間層サーバーが3方向に複製され、バックエンドデータベース（MySQL、PostgreSQLなど）が3方向に複製されるとします。ユーザーリクエストにより、中間層サーバーにいくつかのユーザーデータが作成されることになります。これを、障害に強い方法でバックエンドデータベースにコミットしたいと思います。
たとえば、1つのSQLデータベースにデータを送信し、他のデータベースにデータを複製する場合、1つのSQLデータベースでデータを複製する前にハードドライブがクラッシュすると、データが失われます。
実際の現実の世界で使用されているフォールトトレランスのベストプラクティスソリューションは何ですか。
多くのデータベースには、スケッチした要件に対するすぐに使えるソリューションとして、クラスタリングのオプションがあります。独自のソリューションを展開するのではなく、すぐに使用できるソリューションを使用することを強くお勧めします。この種のソリューションには、自分で解決したくない厄介な問題がいくつかあります。
古典的な例は主キーです。ミドルウェア サーバーから「テーブル x に新しいレコードを作成する」命令を受け取る可能性のある 3 つのバックエンド サーバーがあり、データを複製したい場合、データに衝突がないことを確認する必要があります。主キー。主キーのデータ型として整数を使用する場合、ID がサーバー 2 のレコードに既に使用されている場合、DB サーバー 1 が ID 1 の顧客レコードを作成しないようにする必要があります。これは不可能な課題ではありませんが、ソリューションを構築してテストする数週間は簡単に燃え尽きる可能性があります。
もう 1 つ考慮する必要があるのは、データベースが停止した場合にアプリケーションをオフラインにできる期間です。停止がまったくない場合、数分、数時間、または数日です。停止期間が短いほど、クラスタリング ソリューションはより高価で複雑なものにする必要があります。