MySQL5.6非GTIDからGTIDを使用したMySQL5.7へのオンライン移行

複製する現在のマスターはスタンドアロンのMySQL5.6（バイナリログが有効、サーバーIDが構成され、GTIDなし）であり、本番データベースにサービスを提供しています。したがって、この移行ではダウンタイムはオプションではありません。一方、ClusterControlはGTIDが有効になっている新しいMySQL 5.7を構成します。つまり、このスタンドアロンマスターから正しく複製できるようにするには、スレーブクラスター内のGTID機能をオフにする必要があります。

次の行は、[mysqld]ディレクティブの下でのマスター/etc/mysql/mysql.conf.d/mysqld.cnfの現在のレプリケーション関連の構成を示しています。

server_id=1
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
relay_log=relay-bin
expire_logs_days=7
sync_binlog=1

MySQLサーバーがGTIDなしでバイナリログを生成していることを確認します：

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000007 |   734310 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+

1 row in set (0.00 sec)

GTID以外の場合、Executed_Gtid_Setは空であると想定されます。 ClusterControlによってデプロイされた新しいMySQL5.7レプリケーションクラスターは、GTIDが有効になっているように構成されていることに注意してください。

1）mysql57aで使用するレプリケーションユーザーを作成します：

mysql> CREATE USER 'slave'@'192.168.10.31' IDENTIFIED BY 'slavepassword';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@192.168.10.31';

2）ClusterControlの自動回復を無効にします。以下のスクリーンショットに示すように、ClusterControl UI->クラスターを選択->自動回復クラスターとノードがオフになっていることを確認します（赤い電源アイコン）：

このレプリケーション構成中に、ClusterControlがノードを回復することは望ましくありません。

3）これはメジャーバージョンのアップグレードになるため、完全なmysqldumpバックアップを作成する必要があります。 PerconaXtrabackupやMySQLEnterpriseBackupなどの他の非ブロッキングバックアップツールは、別のメジャーバージョンへの復元をサポートしていません。また、-master-dataフラグを使用して現在のバイナリログファイルと位置を保持する必要があります：

$ mysqldump -u root -p --single-transaction --master-data=2 --all-databases > mysql56a-fullbackup.sql

--single-transactionのため、上記のコマンドはInnoDBテーブルをブロックしないことに注意してください。したがって、MyISAMテーブルがある場合、一貫性を維持するために、バックアップ期間中はテーブルがブロックされます。

4）バックアップをmysql56aからmysql57aおよびmysql57bにコピーします。

$ scp mysql56a-fullbackup.sql [email protected]:~
$ scp mysql56a-fullbackup.sql [email protected]:~

スレーブクラスターの準備

このフェーズでは、GTIDなしで古いマスターmysql56aからの複製を開始するようにスレーブクラスターを構成します。

1）mysql57aとmysql57bの間のレプリケーションを停止し、ClusterControlによって構成されたすべてのスレーブ関連の資格情報を削除し、mysql57bで読み取り専用を無効にします。

mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;

2）mysql57aでGTIDを無効にします：

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

3）mysql57bでGTIDを無効にします：

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

4）mysql57aでmysqldumpバックアップを復元します：

$ mysql -uroot -p < mysql56a-fullbackup.sql

5）mysql57bでmysqldumpバックアップを復元します：

$ mysql -uroot -p < mysql56a-fullbackup.sql

6）mysql57aでMySQLアップグレードスクリプトを実行します（すべてのテーブルをチェックして現在のバージョンに更新します）：

$ mysql_upgrade -uroot -p

7）mysql57bでMySQLアップグレードスクリプトを実行します（すべてのテーブルをチェックして現在のバージョンに更新します）：

$ mysql_upgrade -uroot -p

これで、スレーブクラスター上の両方のサーバーが古いマスターmysql56aからのデータスナップショットでステージングされ、複製する準備が整いました。

スレーブクラスターのレプリケーションの設定

1）mysql57aでRESET MASTERを使用してバイナリログをリセットするため、後でmysql57bでバイナリファイルとログの位置を指定する必要はありません。また、以前に構成された既存のGTID参照をすべて削除します。

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';

2）mysql57aで、binlogファイルと位置をダンプファイルmysql56a-fullbackup.sqlから取得します。

$ head -100 mysql56a-fullbackup.sql | grep LOG_POS
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;

3）前の手順で取得した正しいMASTER_LOG_FILE値とMASTER_LOG_POS値を指定して、古いマスターmysql56aから新しいマスターmysql57aへのレプリケーションスレーブを開始します。 mysql57aの場合：

mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.22', MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

次の行が表示されていることを確認してください。

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

「Seconds_Behind_Master」を監視し、それが0になることを確認して、mysql57aがmysql56aに追いつくまで待つ必要があります。

4）この時点で、mysql57aはmysql56aからのデータを複製しています。これは、ClusterControlによって作成されたすべてのユーザーがサーバーから欠落していることを意味します（mysql57aがmysql56aのデータをフォローしているため）。 ClusterControlはmysql57aに接続する際に問題が発生し、「ダウン」として表示されます。これは基本的に、許可がないためにClusterControlがMySQLサーバーに接続できないことを意味します。行方不明のユーザーは次のとおりです。

• [email protected]
• [email protected]'{1つの特定のクラスター内のすべてのノード}'
• [email protected]'{ClusterControl host}'

すべての資格情報は、ClusterControlとデータベースサーバー自体に安全に保存されます。関連するファイルからクレデンシャルを取得するには、ルートアクセス権が必要です。

それでは、新しいマスターmysql57aで欠落しているユーザーを再作成しましょう：

a）バックアップユーザーを作成します（mysql57aの/etc/mysql/secrets-backup.cnfから取得したパスワード）：

mysql> CREATE USER [email protected] IDENTIFIED BY '[email protected]!65%JlNB1z';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO [email protected];

b）すべてのDBホストのレプリケーションユーザーを作成します（ClusterControlサーバーの/etc/cmon.d/cmon_X.cnf内のrepl_password変数から取得したパスワード。XはスレーブクラスターのクラスターIDです）：

mysql> CREATE USER 'rpl_user'@'192.168.10.31' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.31';
mysql> CREATE USER 'rpl_user'@'192.168.10.32' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.32';

c）ClusterControlの使用（ClusterControlサーバーの/etc/cmon.d/cmon_X.cnf内のmysql_password変数から取得したパスワード。XはスレーブのクラスターID）用に2つのcmonデータベースユーザー（1つはIPアドレス用、もう1つはホスト名用）を作成します。クラスター）：

mysql> CREATE USER [email protected]'192.168.10.19' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'192.168.10.19' WITH GRANT OPTION;
mysql> CREATE USER [email protected]'cc.local' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'cc.local' WITH GRANT OPTION;

5）この時点で、mysql57aはClusterControlで緑色で表示されます。これで、mysql57aからmysql57bへのレプリケーションリンクを設定できます。 mysql57bの場合：

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J';
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

** MASTER_LOG_FILEとMASTER_LOG_POSを指定する必要はありません。これは、ステップ1のRESETMASTERの後に常に固定の初期位置から開始されるためです。

次の行が表示されていることを確認してください：

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

レプリケーションステータスを監視し、mysql57bがmysql57aに対応し、mysql57aがmysql56aに対応していることを確認します。その後、偶発的な書き込みから保護するために、mysql57b（および/またはmysql57a）で読み取り専用を有効にする必要がある場合があります。

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

ClusterControl UIから、[概要]セクションに現在の状態が表示されます：

この時点で、新しいマスターmysql57a、192.168.10.31は古いスタンドアロンホストmysql56a、192.168.10.22、新しいスレーブmysql57b（読み取り専用）はmysql57a、192.168.10.31から複製しています。すべてのノードがレプリケーションラグ0で同期されます。

または、[mysqld]セクションのMySQL構成ファイル内の次の行をコメントアウトすることもできます。

#gtid_mode=ON
#enforce_gtid_consistency=1

スレーブクラスターでGTIDを有効にする

MySQL 5.6以降では、ClusterControlは、RebuildReplicationSlaveやChangeReplicationMasterなどの一部の管理機能で非GTID実装をサポートしていないことに注意してください。したがって、スタンドアロンMySQLサーバー（mysql56a）からのカットオフ時間（アプリケーションを新しいクラスターにポイントするとき）に、次の手順でmysql57aおよびmysql57bでGTIDを有効にすることをお勧めします。

1）ClusterControl自動回復機能を必ずオフにしてください：

2）カットオフメンテナンスウィンドウの間、複製を停止する必要があります古いマスターmysql56aから、mysql57aのすべてのスレーブ構成を削除し、GTIDを有効にします。 mysql57aで、次のコマンドを正しい順序で実行します。

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

この時点で、アプリケーションが新しいマスターmysql57aへの書き込みを開始することは実質的に安全です。古いスタンドアロンのMySQLはレプリケーションチェーンから外れ、シャットダウンできます。

3）mysql57bについても同じ手順を繰り返します。正しい順序で手順を実行することを忘れないでください：

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

4）次に、新しいマスターmysql57aでマスターをリセットします：

mysql> RESET MASTER;

3）次に、新しいスレーブで、mysql57bがGTIDを使用してmysql57aへのレプリケーションリンクを設定します。

mysql> RESET MASTER;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

Retrieved_Gtid_SetフィールドとExecuted_Gtid_SetフィールドにGTID値があることを確認してください。

4）この時点で、クラスターの展開段階でClusterControlによって以前に構成されたレプリケーション構成を復元しました。次に、新しいスレーブmysql57bで読み取り専用を有効にして、偶発的な書き込みから保護します。

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

最後に、電源アイコンを緑色に切り替えて、クラスターのClusterControl自動回復を再度有効にします。その後、古いマスターmysql56aを廃止できます。 MySQL5.6からMySQL5.7へのオンライン移行を最小限のダウンタイムで完了しました。同様の手順は、MySQL8.0への移行でも機能するはずです。