MySQL binlog欠落クエリ
これで受け入れられた答えを直接参照してください 質問
MySQLは、更新クエリで直接database.table構文を使用する場合（たとえば、UPDATE Foo.Bar SET ...）、バイナリログファイルにログを記録しません。
上記は本当ですか？これは、回答者が提供するリンクで明示的には述べていません。そして、これを軽減する唯一の方法は、アプリケーションがクエリ内のテーブル参照にスキーマ名をプレフィックスしないようにすることですか？
私が尋ねる理由は、偶発的なdrop databaseの後で最近のバックアップから復元したためです。また、ビンログからその日のアクティビティを復元してデータを完成させたいと思っていました。 binlogsからクエリを抽出したとき、drop databaseがログに表示される前に、単一のクエリを見つけることができませんでした。 -正しいタイムスタンプを抽出したことも確信しています。
これは、STATEMENTベースのレプリケーションを使用するbinlog-do-db（および同等の）コンテキストに当てはまります。何をしているかがわからない場合（またはレプリケーションフィルターが原因でデータが失われる場合）は、binlog-do-dbを使用しないでください。レプリケーションフィルタリングを行う場合は、レプリカでreplicate-wild-do-table（およびその他のwildオプション）を使用する必要があります。イベントは簡単に除外できますが、ログに記録されていない場合は元に戻すことはできません。 ROWは、フィルタリングの動作をより健全にするのにも役立ちます。
レプリケーションフィルタリングを使用していない場合、サーバー固有でないすべての書き込みコマンドは、正しく有効化され、切り捨てられていない場合に、マスターのバイナリログに送信されます。
発生した問題（mysqlのバージョン、使用するトポロジー、オプション）を理解するには、より多くの情報を提供する必要があります。
USE Zap;
UPDATE Foo.Bar SET...
ZapではなくFooに基づいて複製するかどうかを決定します。そして、それはbinlog_do/ignore_db 決定する。