発生する可能性のある DDL ステートメントを含む MySQL データベースに加えられたすべての変更をログに記録し、その情報を使用してリモート データベースと同期できるようにする可能性を研究しています。
アプリケーション自体は C# で記述されているため、これまでに利用可能であることがわかっている最高の同期テクノロジは Microsoft Sync Framework です。このフレームワーク自体は、削除された行を格納するためのトリガーと追加のテーブルを追加することにより、DB に加えられた変更を追跡するソリューションを提案します。
4 つ以上の製品で使用される標準 DB のスキーマを変更する必要があるため、これは私の場合には良い考えではないようです。この方法はまた、(各テーブルの削除された行に新しいテーブルを追加することによって) テーブルの数を効果的に 2 倍にしていますが、これも気分が悪いものです。
一方、MySQL にはこの素晴らしい binlog があります。これはすべての変更を追跡し、いわゆる混合モードを使用してほとんどの場合ステートメントを追跡することもできます (したがって、リモート DB で再度実行してデータを複製できます) と生データ非決定論的関数 (NOW() など) が呼び出されると、更新されるデータは両方の場所で同じになります。
また、このデータを取得するには 2 つの標準的な方法があるようです: 1) mysqlbinlog ユーティリティ 2) 'SHOW BINLOG EVENTS' を呼び出す
別の外部アプリケーションを呼び出したり、DB マシンでアプリケーションを実行したりする必要がないため、オプション 2 の方が適しているように思えますが、ログに記録された ROW 形式ステートメントの実際のデータは含まれません (次のようなもののみ: table_id: 47 flags:何も教えてくれないSTMT_END_F)。
最後に私の質問は次のとおりです。
構造全体を変更したり、大量のトリガーやテーブルを追加したりせずに、MySQL データベースに加えられた変更を追跡するより良い方法はありますか? 製品を変更して変更をログに記録することもできますが、このデータベースを使用してすべての製品を変更して、すべてを確実にログに記録する必要があります...そして、すべての人を納得させることはほとんど不可能だと思います.
SHOW BINLOG EVENTS を使用して行われた変更に関するすべての情報を取得できますか? ROW データを含みます。
PS私もMySQL Proxyを調査しましたが、すべてのケースでステートメントをログに記録する際の問題は、非決定論的関数の実際のデータが含まれていないことです。