MySQL 5.6 GTID 新機能 practice_MySQL

GTIDの紹介

GTIDとは

GTID (グローバル トランザクション ID) は、送信されたトランザクションの番号であり、世界的に一意の番号です。

GTID は実際には UUID+TID で構成されます。 UUID は、MySQL インスタンスの一意の識別子です。 TID は、このインスタンスでコミットされたトランザクションの数を表し、トランザクションがコミットされるにつれて単調に増加します。 GTID の具体的な形式は次のとおりです

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

より詳細な紹介については、公式ドキュメントを参照してください

GTIDの役割

それでは、GTID 関数の目的は何でしょうか?具体的なまとめは主に以下の2点です

GTID に基づいて、トランザクションが最初に送信されたインスタンスを知ることができます。GTID の存在により、レプリケーションのフェイルオーバーが容易になります。2 番目の点については、ここで詳しく説明します。 MySQL 5.6 の GTID が登場する前のレプリケーション フェイルオーバーの動作プロセスを見てみましょう。以下に示すような環境があるとします

現在、サーバーAのサーバーがダウンしているため、サーバーBに業務を切り替える必要があります。同時に、サーバー C のレプリケーション ソースをサーバー B に変更する必要があります。コピー元変更のコマンド構文は非常に単純です。つまり、CHANGE MASTER TO MASTER_HOST='xxx'、MASTER_LOG_FILE='xxx'、MASTER_LOG_POS=nnnn です。問題は、同じトランザクションのバイナリログ名とマシンごとの場所が異なるため、サーバー C の現在の同期停止ポイントと、サーバー B に対応する master_log_file および master_log_pos が何であるかを見つけることが問題になることです。これは、M-S レプリケーション クラスターで MMM や MHA などの追加の管理ツールを使用する必要がある重要な理由です。

GTID 5.6 が登場してからは、この問題は非常に簡単になったようです。同じトランザクションの GTID はすべてのノードで同じ値を持つため、サーバー B の GTID はサーバー C の現在の停止ポイントの GTID に基づいて一意に特定できます。 MASTER_AUTO_POSITION 関数の登場により、GTID の特定の値を知る必要がなく、CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION コマンドを直接使用してフェイルオーバー作業を直接完了できます。とても簡単ですね

GTID ベースのマスター/スレーブ レプリケーションの概要

建物

構築は mysql_sandbox スクリプトに基づいており、最初に 1 つのマスターと 3 つのスレーブを持つロケーションベースのレプリケーション環境が作成されます。その後、構成を変更することで、アーキテクチャ全体が GTID ベースのレプリケーション用に設計されます。

公式 MySQL ドキュメントに記載されている GTID 構築の提案に基づいています。マスターノードとスレーブノードの構成を一度変更し、サービスを再起動する必要があります。運用環境でアップグレードする場合、このような操作は明らかに受け入れられません。 Facebook、Booking.com、Percona はすべてパッチを通じてこれを最適化し、よりエレガントなアップグレードを実現しました。具体的な操作方法は今後のブログで紹介していきます。ここでは、公式ドキュメントに従って実験的なアップグレードを実行します。

主なアップグレード手順は次のとおりです:

マスターとスレーブの同期を確保します。マスターで my.cnf を変更するために新しいデータが書き込まれないようにします。サービスを再起動して、マスターを on に変更します。 =1 GTID ベースのレプリケーションの有効化は実験環境であるため、read_only とサービスを再起動しても問題は発生しません。公式の GTID 構築推奨事項に従っている限り、アップグレードを正常に完了できます。詳細なプロセスについてはここでは説明しません。以下に、アップグレード プロセス中に発生しやすいエラーをいくつか示します。

よくある間違い

gtid_mode=ON、log_slave_updates、および enforce_gtid_consistency を my.cnf で同時に設定する必要があります。そうしないと、mysql.err に次のエラーが表示されます

2016-10-08 20:11:08 32147 [エラー] --gtid-mode=ON または UPGRADE_STEP_1 または UPGRADE_STEP_2 には --log-bin および --log-slave-updates が必要です
2016-10-08 20:13:53 32570 [エラー] --gtid-mode=ON または UPGRADE_STEP_1 には --enforce-gtid-consistency が必要です

マスターをに変更した後の警告

ドキュメントに従ってマスターを変更すると、2 つの警告が表示されます。実際、これらは 2 つのセキュリティ警告であり、通常の同期には影響しません (興味のある読者は、この警告の詳細な紹介を読むことができます。警告の具体的な内容は次のとおりです:

リーリー

実験 1: スレーブが必要とするトランザクションに対応する GTID がマスター上でパージされている場合

show global variables like '%gtid%' のコマンド結果によると、GTID に関連する変数の中に gtid_purged があることがわかります。文字通りの意味と公式ドキュメントから、この変数に記録されているのは、ローカル マシン上で実行されたが、コマンドへのバイナリ ログのパージによってクリーンアップされた gtid_set であることがわかります。
このセクションでは、スレーブによってフェッチされていないいくつかの GTID イベントをマスターがパージした場合に何が起こるかをテストします。

次の命令はマスター上で実行されます

リーリー

在slave2上重新做一次主从，以下命令在slave2上执行

slave2 [localhost] {msandbox} ((none)) > change master to master_host='127.0.0.1',master_port =21288,master_user='rsandbox',master_password='rsandbox',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)
slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)
slave2 [localhost] {msandbox} ((none)) > show slave status\G
*************************** 1. row ***************************
......
Slave_IO_Running: No
Slave_SQL_Running: Yes
......
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 0
Relay_Log_Space: 151
......
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
Last_SQL_Errno: 0
Last_SQL_Error:
......
Auto_Position: 1
1 row in set (0.00 sec)

实验二：忽略purged的部分，强行同步

那么实际生产应用当中，偶尔会遇到这样的情况：某个slave从备份恢复后（或者load data infile）后，DBA可以人为保证该slave数据和master一致；或者即使不一致，这些差异也不会导致今后的主从异常（例如：所有master上只有insert没有update）。这样的前提下，我们又想使slave通过replication从master进行数据复制。此时我们就需要跳过master已经被purge的部分，那么实际该如何操作呢？

我们还是以实验一的情况为例：

先确认master上已经purge的部分。从下面的命令结果可以知道master上已经缺失24024e52-bd95-11e4-9c6d-926853670d0b:1这一条事务的相关日志

master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
7 rows in set (0.00 sec)

在slave上通过set global gtid_purged='xxxx'的方式，跳过已经purge的部分

slave2 [localhost] {msandbox} ((none)) > stop slave;
Query OK, 0 rows affected (0.04 sec)
slave2 [localhost] {msandbox} ((none)) > set global gtid_purged = '24024e52-bd95-11e4-9c6d-926853670d0b:1';
Query OK, 0 rows affected (0.05 sec)
slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)
slave2 [localhost] {msandbox} ((none)) > show slave status\G 
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
......
Master_Log_File: mysql-bin.000005
Read_Master_Log_Pos: 359
Relay_Log_File: mysql_sandbox21290-relay-bin.000004
Relay_Log_Pos: 569
Relay_Master_Log_File: mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
......
Exec_Master_Log_Pos: 359
Relay_Log_Space: 873
......
Master_Server_Id: 1
Master_UUID: 24024e52-bd95-11e4-9c6d-926853670d0b
Master_Info_File: /data/mysql/rsandbox_mysql-5_6_23/node2/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
......
Retrieved_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:2-3
Executed_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:1-3
Auto_Position: 1
1 row in set (0.00 sec)

可以看到此时slave已经可以正常同步，并补齐了24024e52-bd95-11e4-9c6d-926853670d0b:2-3范围的binlog日志。

以上所述是小编给大家介绍的MySQL 5.6 GTID新特性实践，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对网站的支持！