私たちのシナリオは次のとおりです（これはユニークではないと思います）：2つの異なるコロケーション施設にデータベースでバックアップされたWebアプリがあります。1つの施設にはマスターデータベースがあり、もう1つの施設にはスレーブがあります。
マスターデータベースがオフラインの場合でも、スレーブ機能を（必要に応じて制限付きモードで）動作させ続ける必要があります。マスターデータベースがバックアップされると、データが同期されるはずです。
メッセージキューを使用してデータ更新命令を送信できると考えていました。スレーブサーバーとマスターサーバーの間に切断がある場合、スレーブサーバーのメッセージキューはそのメッセージを保持します。接続が回復すると、メッセージが流れ、マスターサーバーがデータベースを更新します。
私は何かが足りないのですか？これはメッセージキューの良い使い方ではありませんか？
はい。ただし、データ センターでメッセージ キューを使用するほど簡単ではありません。2 つの永続的なメッセージ クラスター間のブリッジングを使用してアーキテクチャをセットアップする必要がある場合があります。これを行う 1 つの方法は、RabbitMQ ブローカー (またはブローカー クラスター) を各物理的な場所にセットアップし、この ZeroMQ プラグインで行われるような別のプロトコルを使用してそれらの場所をブリッジすることですhttps://github.com/rabbitmq/rmq-0mq /ウィキ
最終結果は、メッセージ ブローカーのフェデレーションです。データの量とロケーション間の距離に応じて、ブリッジング用の圧縮された VPN リンクまたはクラスター間の何らかのバッチ処理と圧縮を使用して、アーキテクチャに圧縮を組み込むことができます。
しかし、これが唯一の方法ではありません。もう 1 つの方法は、中央の RabbitMQ クラスターを 1 つ用意し、インターネット経由でこのクラスターへの SSL クライアント接続を使用することです。場所が比較的近い場合は、これがより良い解決策になります。たとえば、すべての場所が米国北東部にある場合、これが私が行う方法です。ただし、ロケーションが米国、ヨーロッパ、およびアジアにある場合は、フェデレーション ソリューションを使用して、ブローカーのクラスター間でデータを橋渡しすることをお勧めします。
また、3 つの大陸にまたがる 100 か所の拠点など、非常に大きな組織では、おそらく 2 つのソリューションを組み合わせたいと思うでしょう。
しかし、これがマスター db とレプリカの 2 つの場所と同じくらい単純である場合は、標準の db レプリケーション ソリューションに固執する方がよいと思います。大きい。私が認識しているレプリケーション ソリューションは、マスターとスレーブ間のリンクがダウンしたときに、後で送信する更新の保存を既に処理しています。そのシナリオでは AMQP を忘れてください。
IBM DB2 には、"Q Replication"コミットされたトランザクション データを DB2(R) UDB ソースからターゲットに複製するために呼び出される機能があります。Q レプリケーションは、WebSphere MQキューと 2 つのプログラムQ Captureを使用Q Applyしてデータを複製します。プログラムはQ Captureソース上で実行され、データを取得して WebSphere MQ キューに送信します。Q アプライ・プログラムはターゲット上で実行され、WebSphere MQ キューからメッセージを受け取り、データをターゲット・データベースに適用します。
Q レプリケーションの詳細については、こちらを参照してください。