mysql5.6 GTID手動スキップコピーエラー

バックアップ・レプリケーションでエラーが発生した場合、従来のエラーをスキップする方法はsql_を設定することです.slave_skip_counter、そしてSTART SLAVE.しかしGTIDを開くと、設定に失敗します.

mysql> set global sql_slave_skip_counter = 1;

ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON. Instead, for each transaction that you want to skip, generate an empty transaction with the same GTID as the transaction

プロンプトのエラーメッセージは、空のトランザクションを生成することで、エラーのトランザクションをスキップできることを示します.手動でバックアップ・レプリケーション・エラーを生成します.

Last_SQL_Error: Error ‘Unknown table ‘test.t1” on query. Default database: ‘test’. Query: ‘DROP TABLE `t1` /* generated by server */’

binlogでは、DDLに対応するGTIDが7 a 07 cd 08-ac 1 b-11 e 2-9 fcf-010184 e 9 e 08:131で、リポジトリで実行されています.

mysql> STOP SLAVE;

Query OK, 0 rows affected (0.00 sec)
mysql> SET SESSION GTID_NEXT = ’7a07cd08-ac1b-11e2-9fcf-0010184e9e08:1131′;
Query OK, 0 rows affected (0.00 sec)
mysql> BEGIN; COMMIT;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)



mysql> SET SESSION GTID_NEXT = AUTOMATIC;

Query OK, 0 rows affected (0.00 sec)



mysql> START SLAVE;

show slave statusを確認すると、エラートランザクションがスキップされていることがわかります.この方法の原理は簡単で,空のトランザクションによって生成されたGTIDがGTIDに加わる.EXECUTEDでは、このGTIDに対応するトランザクションが実行されたことをリポジトリに伝えることに相当します.b.メインライブラリの再指
change master to....を使用して、MASTER_AUTO_POSITION=1; レプリケーショントポロジ全体でgtid_を開く必要があることに注意してください.mode c.新しいuntil条件
5.6新たなutil conditionが提供され、GTIDに基づいてバックアップコピーの実行先SQL_を決定できるBEFORE_GTIDS:指定されたGTIDより前にSQL_のコピーを停止するAFTER_GTIDS:指定されたGTIDの後にレプリケーション判定関数を停止するのはRelay_log_info::is_until_satisfiedの詳細は、次のとおりです.http://dev.mysql.com/doc/refman/5.6/en/start-slave.htmld.binlogファイルのサイズを適宜小さくする
GTIDをオンにすると、各binlogファイルの最大値を理論的に小さくして、ファイルをスキャンする時間を短縮することが望ましい.四、存在するバグ
bug#69097、gtidを閉じてもmodeは、起動時にbinlogファイルもスキャンします.再起動前にgtid_を使用しなかった場合modeは、再起動後にすべてのbinlogファイルをスキャンする可能性がありますが、Binlogファイルが多い場合は、これは明らかに受け入れられません.bug#69096、GTIDを通過できませんでした_NEXT_LISTはレプリケーションエラーをスキップします.デフォルトのコンパイルではGTID_NEXT_LISTはコンパイルされていません.TODO:GTID_NEXT_LISTのロジックには言及されていませんが、暇があればまた見てください.bug#69095は、ライブラリのコピーモードをSTATEMENT/MIXEDに設定します.マスターライブラリはROWモードに設定されており、DMLを実行するとバックアップコピーが中断されます

Last_SQL_Error: Error executing row event: ‘Cannot execute statement: impossible to write to binary log since statement is in row format and BINLOG_FORMAT = STATEMENT.’

エラーを判断するbacktrace:

handle_slave_worker->slave_worker_exec_job->Rows_log_event::do_apply_event->open_and_lock_tables->open_and_lock_tables->lock_tables->THD::decide_logging_format

解決策:バックアップのコピーモードを「ROW」に設定し、プライマリ・バックアップの一貫性を保つ
このバグはGTIDに関係なくバグ＃69045であり、マスターライブラリがFLUSH PRIVILEGESのような動作を実行すると、マスターライブラリとスタンバイライブラリの両方がgtid_をオンにするmode、レプリケーションが中断します

Last_SQL_Error: Error ‘Cannot execute statements with implicit commit inside a transaction when @@SESSION.GTID_NEXT != AUTOMATIC or @@SESSION.GTID_NEXT_LIST != NULL.’ on query. Default database: ”. Query: ‘flush privileges’

MySQL 5では非常に低レベルのバグでもあります.6.11リリースで、暗黙的にコミットされるトランザクションが発生する可能性がある場合、gtid_nextはAUTOMATICに等しくなければならない.ライブラリコピースレッドにとって、簡単に中断され、判断ロジックは関数gtid_にある.pre_statement_checks中