GTID レプリケーションと問題処理

まず、GTID とは何かを見てみましょう:

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

GTID は実際には UUID+TID で構成されます。ここで、UUID は MySQL インスタンスの一意の識別子です。 TID は、このインスタンスでコミットされたトランザクションの数を表し、トランザクションがコミットされるにつれて単調に増加します。 GTID に基づいて、トランザクションが最初に送信されたインスタンスを知ることができ、フェイルオーバーが容易になります。

次に、GTID モードでスレーブをすばやく追加する方法を見てみましょう:

GTID レプリケーションが存在しない前は、MySQL レプリケーションはバイナリ ログと 位置 に基づいていたことがわかっています。次の変更ステートメントを実行します:

CHANGE MASTER TO MASTER_HOST='',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='*****',MASTER_LOG_FILE='mysqlbinlog.000003',MASTER_LOG_POS=99721204;

そして、GTID で次の変更ステートメントを実行できます:

CHANGE MASTER TO  MASTER_HOST='****', MASTER_USER='repl',  MASTER_PASSWORD='******',  MASTER_PORT=3306,  master_auto_position=1;

私たちはできますを参照してください。基本的に、元のバイナリ ログ メソッドではレプリケーションを指定するときに MASTER_LOG_FILE と MASTER_LOG_POS を指定する必要がありますが、GTID レプリケーションではこれらのパラメーターを知る必要はありません。

GTID モードでマスター/スレーブ レプリケーションを作成する方法を見てみましょう:

上記からわかるように、GTID モードでは、対照的に、MASTER_LOG_FILE と MASTER_LOG_POS の 2 つのパラメーターを知る必要はありません。マスターを指定するだけです。コピーを作成する方がはるかに簡単です。 GTIDモードでは、次の2つのグローバル変数を知る必要があります。実行されたすべてのモノの一連の GTID。これは、バイナリ ログに配置されたモノのシリアル番号です。このパラメータは読み取り専用であり、設定できません。 gtid_purged: このシーケンスは、バイナリ ログ

内で削除したものの GTID のシーケンス番号を参照します。管理を容易にするために手動で設定できます。

これら 2 つのパラメータを理解した後、GTID レプリケーションを使用してスレーブ データベースを追加する方法を見てみましょう:

(1): マスター データベースから完全バックアップを作成し、マスターのバックアップ時点での gtid_executed を記録します。データベース

(2): ライブラリからリカバリし、ライブラリからの gtid_purged を最初の手順で取得したマスターの gtid_executed に設定します

(3): CHANGE MASTER ステートメントを実行します。

mysql

dump を使用してメインデータベースをバックアップし、そのバックアップをスレーブデータベースとして新しいマシンに復元します。実行する前に、メイン ライブラリのパラメータを確認します:

root@perconatest09:23:44>show global variables like 'GTID_%'\G*************************** 1. row ***************************Variable_name: gtid_executed
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24*************************** 2. row ***************************Variable_name: gtid_executed_compression_period
Value: 1000*************************** 3. row ***************************Variable_name: gtid_mode
Value: ON*************************** 4. row ***************************Variable_name: gtid_owned
Value:*************************** 5. row ***************************Variable_name: gtid_purged
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-12

次に、メイン ライブラリでバックアップを作成します:

root@perconatest09:23:58>show global variables like 'GTID_e%'\G*************************** 1. row ***************************Variable_name: gtid_executed
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-242 rows in set (0.01 sec)
root@perconatest09:41:33>show global variables like 'GTID_p%'\G*************************** 1. row ***************************Variable_name: gtid_purged
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-121 row in set (0.01 sec)

私たちにはできますバックアップ ファイル:

mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --port=18675 --user=root--p > /home/sa/backup.sql

次のパラメータが表示されます:

[root@localhost sa]# head -30 backup.sql

つまり、リカバリを実行すると, GTID_PURGED は自動的に設定されますが、この値はたまたまマスターの gtid_executed なので、ライブラリからリストアした後は基本的に指定する必要はありません。

データベースからのデータ回復を入力します:

source Backup.sql;

GTID_PURGE の値を指定する必要がないことがわかります。不明な場合は、

で確認できます。

SET @@GLOBAL.GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24';

後でコピーを直接指定するだけです:

show global variables like 'gtid_executed';
show global variables like 'gtid_purged';

* を、指定する必要があるメインライブラリの関連情報に置き換えます。

GTID マスター/スレーブ レプリケーション モードでエラーが発生した場合、どのように回復すればよいでしょうか?

メイン ライブラリのログがパージされ、

リセット

やその他の操作が実行された場合、スレーブ ライブラリには次のエラーが表示されます:

CHANGE MASTER TO MASTER_HOST="***", MASTER_USER="root", MASTER_PASSWORD="*****", MASTER_PORT=3306, MASTER_AUTO_POSITION = 1;

は、ログを保存できないことを通知します。処理方法を見てみましょう:

(1) メインライブラリは次の操作を実行します:

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.'

(2) スレーブlibrary

root@perconatest09:41:38>show global variables like 'GTID_EXECUTED';+---------------+---------------------------------------------------------------------------------------------------------------------------------+| Variable_name | Value |+---------------+---------------------------------------------------------------------------------------------------------------------------------+| gtid_executed | 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24 |+---------------+---------------------------------------------------------------------------------------------------------------------------------+1 row in set (0.01 sec)

指定する前にこの値が空であることを確認する必要があることに注意してください。そうでない場合は、次のことを行う必要があります:

root@(none)03:04:49>set global GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,806ede0c-357e-11e7-9719-00505693235d:1-11,a38c33ee-34b7-11e7-ae1d-005056931959:1-24';

これで修復は完了しましたが、最終的にマスターとスレーブのデータの一貫性を検証するにはチェックサムを使用するのが最善です。

エラーメッセージ:

バイナリ ログからデータを読み取るときにマスターから致命的エラー 1236 が発生しました: 'スレーブは CHANGE MASTER TO MASTER_AUTO_POSITION = 1 を使用して接続していますが、マスターはスレーブが必要とする GTID を含むバイナリ ログをパージしました

（ビュー数を増やします) もちろん、上記の方法はデータの完全な一貫性を保証するものではありません。pt-table-checksum と pt-table-sync の使用も検証する必要がありますが、この効率性は必ずしも保証されません。前に紹介した方法は、完全バックアップを実行してから、マスターを指定することです。これが最も信頼性の高い方法です。

以上がGTID レプリケーションと問題処理の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。