MySQL 5.6.35-log(コミュニティ)
リセットマスターを実行せずに、誤って手動で挿入されたGTIDをGTIDセットから削除するにはどうすればよいですか?
STOP SLAVE;
SHOW MASTER STATUS;
278bfda1-b93d-11e4-801b-14feb5d284bc:1-129116182,
69cf02cd-1731-11e3-9a19-002590854928:1-649285403:1009231661,
708bb615-d393-11e3-a682-003048c3ab22:1-1009669227,
819c985c-d384-11e3-a621-00259002979a:1-234906555,
9204e764-d379-11e3-a5d9-0013726268ea:1-360176454,
c32252c2-1ce5-11e6-8f4b-c80aa91f9ec4:1
このセットからGTID 1009231661を削除する必要があります。
69cf02cd-1731-11e3-9a19-002590854928:1-649285403:1009231661,
GTIDセットがどこにどのように保存されているか知っていますか? GTIDがテーブルに格納されていることを5.7のドキュメントで読みました。しかし、それらは5.6のどこに保存されていますか?サーバーをシャットダウンし、ファイルを編集し、不正なGTIDを削除してから再起動して、サーバーがピックアップして続行できるようにします。
人生の後半でこれを見つけた人のために。
これは壊滅的な間違いでした。この問題を修正する方法はありません。 RESET MASTER/CHANGE MASTER TOは、ファーム全体で実行する必要があります。なぜそんなに壊滅的ですか?これは、マルチマスター循環レプリケーションでは、すべてのMySQLサーバーでRESET MASTER/CHANGE MASTER TOを実行する必要があるためです。
MySQL 5.6では、GTIDセットはマスターBINLOGファイルに格納されているため、RESET MASTERを実行する必要があります。ただし、RESET MASTERを実行すると、コマンドは最後に使用されたGTIDを0にリセットします。これで、スレーブのGTIDはマスターサーバーより大きくなります。 GTIDがマスターサーバーのスレーブGTID_EXECUTED_SET値を超えるまで、スレーブはトランザクションをスキップします。そのため、すべてのスレーブサーバーでRESET MASTER/CHANGE MASTER TOも実行する必要があります。
RESET MASTER/CHANGE MASTER TOを実行した後、影響を受けるマスターサーバー(別名マスターデータベース)で更新されていたデータベースをダンプ/復元するだけで、スレーブが同期できるようになります。
MysqldumpでGTIDを有効にしてデータベースをバックアップする場合。次のコマンドを使用して、ファイルの先頭でマスターからgtidを設定していることがわかります。
SET @@global.gtid_purged='GTID_SET';
レプリケーション環境で試してみましたが、うまくいきました。
Gtidを直接削除できないのは残念です。 mysql-5.6バージョンでは、実行されたgtidセットを示すシステム変数gtid_executedを見つけることができます。ただし、実際の変数ではないため、直接変更することはできません。Cコードであるグローバル変数「gtid_state」の内容が表示されるだけです。
唯一の解決策は、binlogのプロトコルがわかっている場合、gtid 1009231661を含むbinlogを変更することです。
これを解決する正しい方法は、不正なGTIDが実行される直前にスレーブを実行することだと思います。 START SLAVE
は、UNTIL
句をサポートしています。それについてもっと読む ここ 。
次に、悪いトランザクションに空のトランザクションを挿入してスキップできます。
STOP SLAVE;
SET GTID_NEXT="GTID_you_want_to_skip";
BEGIN; COMMIT;
#now resume just as normal:
SET GTID_NEXT="AUTOMATIC";
START SLAVE;