MySQL 8.0では、Oracleは開発に新しいアプローチを採用しました。メジャーバージョンで機能をプッシュする代わりに、ほとんどすべてのマイナーMySQL8.0バージョンに新しい機能または改善が付属しています。これらの新機能の1つは、このブログ投稿で焦点を当てたいものです。
これまで、MySQLにはプロビジョニング用の優れたツールが付属していませんでした。確かに、mysqldumpがありましたが、これは単なる論理バックアップツールであり、大規模な環境にはあまり適していません。 MySQLエンタープライズユーザーはMySQLEnterpriseBackupの恩恵を受けることができ、コミュニティユーザーはxtrabackupを使用できます。ただし、どちらもクリーンなMySQLコミュニティの展開には付属していません。プロビジョニングは非常に頻繁に行うタスクであるため、非常に面倒でした。新しいスレーブを構築し、失敗したスレーブを再構築する必要がある場合があります。これにはすべて、別々のノード間で何らかのデータ転送が必要になります。
MySQL 8.0.17では、MySQLデータをプロビジョニングする新しい方法であるclonepluginが導入されました。 MySQL Group Replicationを念頭に置いて、障害が発生したノードの自動プロビジョニングと再構築の方法を導入することを目的としていましたが、その有用性はその領域に限定されません。これを使用して、スレーブノードを再構築したり、新しいサーバーをプロビジョニングしたりすることもできます。このブログ投稿では、MySQL Cloneプラグインを設定する方法と、レプリケーションスレーブを再構築する方法を紹介します。
まず、プラグインはデフォルトで無効になっているため、有効にする必要があります。これを行うと、再起動しても有効のままになります。理想的には、レプリケーショントポロジ内のすべてのノードで実行します。
mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';
Query OK, 0 rows affected (0.00 sec)
クローンプラグインには、適切な権限を持つMySQLユーザーが必要です。ドナーでは「BACKUP_ADMIN」権限が必要ですが、ジョイナーでは「CLONE_ADMIN」権限が必要です。クローンプラグインを広範囲に使用したい場合は、両方の権限を持つユーザーを作成するだけです。マスターで実行すると、すべてのスレーブでもユーザーが作成されます。結局のところ、将来どのノードがマスターになるかわからないため、すべてを事前に準備しておく方が便利です。
mysql> CREATE USER [email protected]'%' IDENTIFIED BY 'clonepass';
Query OK, 0 rows affected (0.01 sec)
mysql> GRANT BACKUP_ADMIN, CLONE_ADMIN ON *.* to [email protected]'%';
Query OK, 0 rows affected (0.00 sec)
MySQL Cloneプラグインにはいくつかの前提条件があるため、健全性チェックを実行する必要があります。次の構成変数では、ドナーとジョイナーの両方が同じ値になるようにする必要があります。
mysql> SHOW VARIABLES LIKE 'innodb_page_size';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| innodb_page_size | 16384 |
+------------------+-------+
1 row in set (0.01 sec)
mysql> SHOW VARIABLES LIKE 'innodb_data_file_path';
+-----------------------+-------------------------+
| Variable_name | Value |
+-----------------------+-------------------------+
| innodb_data_file_path | ibdata1:100M:autoextend |
+-----------------------+-------------------------+
1 row in set (0.01 sec)
mysql> SHOW VARIABLES LIKE 'max_allowed_packet';
+--------------------+-----------+
| Variable_name | Value |
+--------------------+-----------+
| max_allowed_packet | 536870912 |
+--------------------+-----------+
1 row in set (0.00 sec)
mysql> SHOW GLOBAL VARIABLES LIKE '%character%';
+--------------------------+--------------------------------+
| Variable_name | Value |
+--------------------------+--------------------------------+
| character_set_client | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database | utf8mb4 |
| character_set_filesystem | binary |
| character_set_results | utf8mb4 |
| character_set_server | utf8mb4 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql-8.0/charsets/ |
+--------------------------+--------------------------------+
8 rows in set (0.00 sec)
mysql> SHOW GLOBAL VARIABLES LIKE '%collation%';
+-------------------------------+--------------------+
| Variable_name | Value |
+-------------------------------+--------------------+
| collation_connection | utf8mb4_0900_ai_ci |
| collation_database | utf8mb4_0900_ai_ci |
| collation_server | utf8mb4_0900_ai_ci |
| default_collation_for_utf8mb4 | utf8mb4_0900_ai_ci |
+-------------------------------+--------------------+
4 rows in set (0.00 sec)
次に、マスターで、UNDO表領域に一意の名前があることを再確認する必要があります。
mysql> SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES
-> WHERE FILE_TYPE LIKE 'UNDO LOG';
+-----------------+------------+
| TABLESPACE_NAME | FILE_NAME |
+-----------------+------------+
| innodb_undo_001 | ./undo_001 |
| innodb_undo_002 | ./undo_002 |
+-----------------+------------+
2 rows in set (0.12 sec)
デフォルトの詳細レベルでは、クローン作成プロセスに関するデータがあまり表示されないため、何が起こっているかをよりよく理解するために、レベルを上げることをお勧めします。
mysql> SET GLOBAL log_error_verbosity=3;
Query OK, 0 rows affected (0.00 sec)
ジョイナーでプロセスを開始できるようにするには、有効なドナーを構成する必要があります:
mysql> SET GLOBAL clone_valid_donor_list ='10.0.0.101:3306';
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW VARIABLES LIKE 'clone_valid_donor_list';
+------------------------+-----------------+
| Variable_name | Value |
+------------------------+-----------------+
| clone_valid_donor_list | 10.0.0.101:3306 |
+------------------------+-----------------+
1 row in set (0.00 sec)
配置が完了すると、次のデータをコピーするために使用できます:
mysql> CLONE INSTANCE FROM 'clone_user'@'10.0.0.101':3306 IDENTIFIED BY 'clonepass';
Query OK, 0 rows affected (18.30 sec)
これで、ジョイナーのMySQLエラーログで進行状況を追跡できます。すべての準備ができたら、レプリケーションを設定するだけです。
mysql> CHANGE MASTER TO MASTER_HOST='10.0.0.101', MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected (0.05 sec)
mysql> START SLAVE USER='rpl_user' PASSWORD='afXGK2Wk8l';
Query OK, 0 rows affected, 1 warning (0.01 sec)
デフォルトでは、クローン作成は暗号化されていないため、安全な環境でのみ使用できます。必要に応じて、ドナーにSSLが構成されていることを確認し、ジョイナーで次の変数を定義することで、クローン作成プロセスにSSL暗号化を設定できます。
clone_ssl_ca=/path/to/ca.pem
clone_ssl_cert=/path/to/client-cert.pem
clone_ssl_key=/path/to/client-key.pem
次に、「REQUIRESSL;」を追加する必要があります。 CLONEコマンドの最後に、プロセスはSSL暗号化で実行されます。これが、保存データの暗号化が有効になっているデータベースのクローンを作成する唯一の方法であることに注意してください。
最初に述べたように、クローン作成は、MySQL Group Replication / InnoDB Clusterを念頭に置いて設計された可能性が高いですが、制限が特定のユースケースに影響を与えない限り、次のように使用できます。 MySQLインスタンスをプロビジョニングするネイティブな方法。それがどれほど広く採用されるかを見ていきます-可能性はたくさんあります。すでに優れているのは、Xtrabackupに加えて、サーバーのプロビジョニングに使用できるハードウェアに依存しない別の方法があることです。競争は常に良好であり、将来がどうなるかを楽しみにしています。