MySQLスレーブが不整合になる可能性があります。あなたはそれを避けようとすることができますが、それは本当に難しいです。 super_read_onlyを設定し、行ベースのレプリケーションを使用すると大いに役立ちますが、何をしても、スレーブが不整合になる可能性があります。
まず、スレーブを再構築するために何が必要かについて説明しましょう。ノードをMySQLレプリケーションに取り込むには、レプリケーショントポロジ内のノードの1つからのデータをプロビジョニングする必要があります。このデータは、収集された時点で一貫している必要があります。プロビジョニングされたノードが内部的に不整合になるため、テーブルごとまたはスキーマごとに取得することはできません。つまり、一部のデータは、データセットの他の部分よりも古いものになります。
データの一貫性に加えて、データとレプリケーションの状態との関係に関する情報を収集することも可能である必要があります。収集されたデータが一貫しているバイナリログ位置、またはデータのソースであるノードで最後に実行されたトランザクションのグローバルトランザクションIDのいずれかが必要です。
これにより、次の考慮事項が発生します。このツールが一貫性のあるバックアップを生成でき、バックアップが一貫している時点のレプリケーション座標が含まれている限り、任意のバックアップツールを使用してスレーブを再構築できます。これにより、いくつかのオプションから選択できます。
Mysqldumpを使用して一貫性のないMySQLスレーブを再構築する
Mysqldumpは、これを実現するために必要な最も基本的なツールです。これにより、特にSQLステートメントの形式で論理バックアップを作成できます。重要なのは、基本的でありながら、一貫性のあるバックアップを取ることです。トランザクションを使用して、トランザクションの開始時にデータの一貫性を確保できます。また、そのポイントのレプリケーション座標、さらにはCHANGE MASTERステートメント全体を書き留めることができるため、バックアップを使用してレプリケーションを簡単に開始できます。
Mydumperを使用して一貫性のないMySQLスレーブを再構築する
もう1つのオプションは、mydumperを使用することです。このツールはmysqldumpと同様に論理バックアップを生成し、mysqldumpと同様にデータベースの一貫したバックアップを作成するために使用できます。 mydumperとmysqldumpの主な違いは、mydumperをmyloaderと組み合わせると、データを並行してダンプおよび復元できるため、ダンプが改善され、特に復元時間が短縮されることです。
クラウドプロバイダーを使用している場合は、基盤となるブロックストレージのスナップショットを作成する可能性があります。スナップショットは、データのポイントインタイムビューを生成します。ただし、データの一貫性とデータを復元する機能は主にMySQLの構成に依存するため、このプロセスは非常に注意が必要です。
データベースが永続モードで動作することを確認する必要があります（MySQLのクラッシュによってデータが失われないように構成されています）。これは、（MySQLの観点から）ボリュームスナップショットを取得し、そこに格納されているデータから別のMySQLインスタンスを開始することは、基本的に、mysqldを強制終了してから再起動する場合と同じプロセスであるためです。 InnoDBのリカバリ、バイナリログに保存されているトランザクションの再生、クラッシュ前に完了していなかったロールバックトランザクションなどを実行する必要があります。
スナップショットベースの再構築プロセスの欠点は、現在のベンダーと強く結びついていることです。あるクラウドプロバイダーから別のクラウドプロバイダーにスナップショットデータを簡単にコピーすることはできません。異なるリージョン間で移動できる場合もありますが、それでも同じプロバイダーになります。
XtrabackupまたはMariabackupを使用して一貫性のないMySQLスレーブを再構築する
最後に、xtrabackup / mariabackup-これは、Perconaによって作成され、MariaDBによってフォークされたツールであり、物理バックアップを生成できます。論理バックアップよりもはるかに高速であり、主にハードウェアのパフォーマンスによって制限されます。ディスクまたはネットワークが最も可能性の高いボトルネックです。ワークロードのほとんどは、MySQLデータディレクトリから別の場所（同じホスト上またはネットワーク経由）へのファイルのコピーに関連しています。
ブロックストレージスナップショットほど高速ではありませんが、xtrabackupははるかに柔軟性があり、あらゆる環境で使用できます。生成されるバックアップはファイルで構成されているため、バックアップを任意の場所にコピーすることが完全に可能です。別のクラウドプロバイダーであるローカルデータセンターは、現在の場所からファイルを転送できる限り問題ありません。
ネットワークに接続する必要はありません。バックアップをUSBSSDやUSBスティックなどの「転送可能な」デバイスにコピーするだけで、すべてのデータを含めることができます。あるデータセンターから別のデータセンターに移動する間、データをポケットに保存します。
Xtrabackupを使用してMySQLスレーブを再構築する方法
MySQLが存在できるほとんどの環境で動作する柔軟性と機能を考慮して、xtrabackupに焦点を当てることにしました。 xtrabackupを使用してスレーブをどのように再構築しますか？見てみましょう。
最初は、いくつかのレプリケーションの問題に悩まされていたマスターとスレーブがあります：
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.141
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000004
Read_Master_Log_Pos: 386
Relay_Log_File: relay-bin.000008
Relay_Log_Pos: 363
Relay_Master_Log_File: binlog.000004
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1007
Last_Error: Error 'Can't create database 'mytest'; database exists' on query. Default database: 'mytest'. Query: 'create database mytest'
Skip_Counter: 0
Exec_Master_Log_Pos: 195
Relay_Log_Space: 756
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1007
Last_SQL_Error: Error 'Can't create database 'mytest'; database exists' on query. Default database: 'mytest'. Query: 'create database mytest'
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1001
Master_UUID: 53d96192-53f7-11ea-9c3c-080027c5bc64
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 200306 11:47:42
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:9
Executed_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:1-8,
ce7d0c38-53f7-11ea-9f16-080027c5bc64:1-3
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set (0.00 sec)ご覧のとおり、スキーマの1つに問題があります。このノードを再構築してレプリケーションに戻す必要があると仮定します。実行する必要のある手順は次のとおりです。
まず、xtrabackupがインストールされていることを確認する必要があります。この例ではMySQL8.0を使用しているため、互換性を確保するためにバージョン8でxtrabackupを使用する必要があります。
[email protected]:~# apt install percona-xtrabackup-80
Reading package lists... Done
Building dependency tree
Reading state information... Done
percona-xtrabackup-80 is already the newest version (8.0.9-1.bionic).
0 upgraded, 0 newly installed, 0 to remove and 143 not upgraded.エクストラバックアップはPerconaリポジトリによって提供され、インストールのガイドはここにあります：
https://www.percona.com/doc/percona-xtrabackup/8.0/installation/apt_repo.html
ツールは、再構築するマスターとスレーブの両方にインストールする必要があります。
次のステップとして、「壊れた」スレーブからすべてのデータを削除します。
[email protected]:~# service mysql stop
[email protected]:~# rm -rf /var/lib/mysql/*次に、マスターでバックアップを取り、スレーブにストリーミングします。この特定のワンライナーには、マスターからスレーブへのパスワードなしのSSHルート接続が必要であることに注意してください。
[email protected]：〜＃xtrabackup --backup --compress --stream =xbstream --target-dir =./ | ssh [email protected] "xbstream -x --decompress -C / var / lib / mysql /"
最後に、重要な行が表示されます：
200306 12:10:40 completed OK!これは、バックアップが正常に完了したことを示します。いくつかの問題がまだ発生する可能性がありますが、少なくともデータは正しく取得されています。次に、スレーブでバックアップを準備する必要があります。
[email protected]:~# xtrabackup --prepare --target-dir=/var/lib/mysql/
.
.
.
200306 12:16:07 completed OK!ここでも、プロセスが正常に完了したことがわかります。ここで、データをMySQLデータディレクトリにコピーして戻すことができます。ストリーミングバックアップを/var/ lib / mysqlに直接保存したので、これを行う必要はありません。ただし、私たちがやりたいのは、ファイルの正しい所有権を確保することです。
[email protected]:~# chown -R mysql.mysql /var/lib/mysqlそれでは、バックアップのGTID座標を確認しましょう。後でレプリケーションを設定するときに使用します。
[email protected]:~# cat /var/lib/mysql/xtrabackup_binlog_info
binlog.000007 195 53d96192-53f7-11ea-9c3c-080027c5bc64:1-9わかりました、すべて問題ないようです。MySQLを起動して、レプリケーションの構成に進みましょう。
[email protected]:~# service mysql start
[email protected]:~# mysql -ppass
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.18-9 Percona Server (GPL), Release '9', Revision '53e606f'
Copyright (c) 2009-2019 Percona LLC and/or its affiliates
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>次に、バックアップで見つかったGTIDセットにgtid_purgedを設定する必要があります。これらは、バックアップによって「カバー」されたGTIDです。新しいGTIDのみがマスターから複製する必要があります。
mysql> SET GLOBAL gtid_purged='53d96192-53f7-11ea-9c3c-080027c5bc64:1-9';
Query OK, 0 rows affected (0.00 sec)
Now we can start the replication:
mysql> CHANGE MASTER TO MASTER_HOST='10.0.0.141', MASTER_USER='rpl_user', MASTER_PASSWORD='yIPpgNE4KE', MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)
mysql> START SLAVE;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.141
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000007
Read_Master_Log_Pos: 380
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 548
Relay_Master_Log_File: binlog.000007
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 380
Relay_Log_Space: 750
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1001
Master_UUID: 53d96192-53f7-11ea-9c3c-080027c5bc64
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:10
Executed_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:1-10
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set (0.00 sec)ご覧のとおり、スレーブはマスターから複製しています。
ClusterControlを使用してMySQLスレーブを再構築する方法は？
ClusterControlユーザーの場合、このプロセスを実行する代わりに、数回クリックするだけでスレーブを再構築できます。最初は、レプリケーションに明らかな問題があります：
エラーのため、スレーブが正しく複製されていません。
必要なのは、「レプリケーションスレーブの再構築」ジョブを実行することだけです。 。
マスターノードを選択するダイアログが表示されます。再構築するスレーブ。次に、[続行]をクリックすると、すべて設定されます。 ClusterControlはスレーブを再構築し、レプリケーションをセットアップします。
すぐに、データセットのサイズに基づいて、動作中のスレーブが表示されるはずです：
ご覧のとおり、数回クリックするだけで、ClusterControlは一貫性のないレプリケーションスレーブを再構築するタスクを実行しました。