GTID レプリケーションと問題処理-mysql チュートリアル-php.cn

まず、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 サイトの他の関連記事を参照してください。