MySQL :: MySQL 8.0 リファレンスマニュアル :: 18.4.6 グループレプリケーションでの MySQL Enterprise Backup の使用

9.1 English
9.0 English
8.4 English
8.0 English
5.7 English

MySQL 8.0 リファレンスマニュアル / ... / グループレプリケーションでの MySQL Enterprise Backup の使用

このページは機械翻訳したものです。

18.4.6 グループレプリケーションでの MySQL Enterprise Backup の使用

MySQL Enterprise Backup は、MySQL Enterprise Edition で使用可能な MySQL Server の商用ライセンスバックアップユーティリティです。このセクションでは、MySQL Enterprise Backup を使用してグループレプリケーションメンバーをバックアップしてからリストアする方法について説明します。同じ方法を使用して、新しいメンバーをグループにすばやく追加できます。

MySQL Enterprise Backup を使用したグループレプリケーションメンバーのバックアップ

グループレプリケーションメンバーのバックアップは、スタンドアロンの MySQL インスタンスのバックアップと似ています。次の手順は、MySQL Enterprise Backup を使用してバックアップを実行する方法をすでに理解していることを前提としています。そうでない場合は、「MySQL Enterprise Backup 8.0 ユーザーガイド」 (特に Backing Up a Database Server) を確認してください。 Grant MySQL Privileges to Backup Administrator および Using MySQL Enterprise Backup with Group Replication で説明されている要件にも注意してください。

同じ名前のホストで実行されている s1、s2 および s3 の 3 つのメンバーを持つ次のグループについて考えてみます:

mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s1          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s3          |        3306 | ONLINE       |
+-------------+-------------+--------------+

MySQL Enterprise Backup を使用して、そのホストで次のコマンドなどを発行し、s2 のバックアップを作成します:

s2> mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/backups/my.mbi_`date +%d%m_%H%M` \
		      --backup-dir=/backups/backup_`date +%d%m_%H%M` --user=root -p \
		      --host=127.0.0.1 backup-to-image

メモ

MySQL Enterprise Backup 8.0.18 以前の場合システム変数 sql_require_primary_key がグループに対して ON に設定されている場合、MySQL Enterprise Backup はバックアップの進行状況をサーバーに記録できません。これは、サーバー上の backup_progress テーブルが CSV テーブルであり、主キーがサポートされていないためです。その場合、mysqlbackup はバックアップ操作中に次の警告を発行します:

181011 11:17:06 MAIN WARNING: MySQL query 'CREATE TABLE IF NOT EXISTS
mysql.backup_progress( `backup_id` BIGINT NOT NULL, `tool_name` VARCHAR(4096)
NOT NULL, `error_code` INT NOT NULL, `error_message` VARCHAR(4096) NOT NULL,
`current_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP               ON
UPDATE CURRENT_TIMESTAMP,`current_state` VARCHAR(200) NOT NULL ) ENGINE=CSV
DEFAULT CHARSET=utf8 COLLATE=utf8_bin': 3750, Unable to create a table
without PK, when system variable 'sql_require_primary_key' is set. Add a PK
to the table or unset this variable to avoid this message. Note that tables
without PK can cause performance problems in row-based replication, so please
consult your DBA before changing this setting.
181011 11:17:06 MAIN WARNING: This backup operation's progress info cannot be
logged.

ただし、mysqlbackup によるバックアップの終了は妨げられません。

MySQL Enterprise Backup 8.0.20 以前の場合では、セカンダリメンバーをバックアップするときに、MySQL Enterprise Backup が読取り専用サーバーインスタンスにバックアップステータスおよびメタデータを書き込むことができないため、バックアップ操作中に次のような警告が発行される場合があります:
```
181113 21:31:08 MAIN WARNING: This backup operation cannot write to backup
progress. The MySQL server is running with the --super-read-only option.
```
警告を回避するには、backup コマンドで --no-history-logging オプションを使用します。これは MySQL Enterprise Backup 8.0.21 以上の問題ではありません。詳細は、Using MySQL Enterprise Backup with Group Replication を参照してください。

失敗したメンバーのリストア

いずれかのメンバー (次の例では s3) が破損しているとします。グループメンバー s2 の最新のバックアップを使用して、s3 をリストアできます。リストアを実行するステップは次のとおりです:

s2 のバックアップを s3 のホストにコピーします。 バックアップをコピーする正確な方法は、使用可能なオペレーティングシステムおよびツールによって異なります。この例では、ホストが両方とも Linux サーバーであると想定し、SCP を使用してホスト間でファイルをコピーします:
```
s2/backups> scp my.mbi_2206_1429 s3:/backups
```
バックアップをリストアします。 ターゲットホスト (この場合は s3 のホスト) に接続し、MySQL Enterprise Backup を使用してバックアップをリストアします。ステップは次のとおりです:
1. 破損したサーバーがまだ実行されている場合は、停止します。たとえば、systemd を使用する Linux ディストリビューションの場合:
```
s3> systemctl stop mysqld
```
2. 破損したサーバーデータディレクトリ (auto.cnf および mysqld-auto.cnf が存在する場合) 内の 2 つの構成ファイルを、データディレクトリ外の安全な場所にコピーして保持します。これは、次のステップで必要な server UUID およびセクション5.1.9.3「永続化されるシステム変数」(使用する場合) を保持するためのものです。
3. s3 のデータディレクトリ内のすべてのコンテンツを削除します。例:
```
s3> rm -rf /var/lib/mysql/*
```
  システム変数 innodb_data_home_dir、innodb_log_group_home_dir および innodb_undo_directory がデータディレクトリ以外のディレクトリを指している場合は、それらも空にする必要があります。そうしないと、リストア操作は失敗します。
4. s2 のバックアップを s3 のホストにリストアします:
```
s3> mysqlbackup --defaults-file=/etc/my.cnf \
  --datadir=/var/lib/mysql \
  --backup-image=/backups/my.mbi_2206_1429  \
  --backup-dir=/tmp/restore_`date +%d%m_%H%M` copy-back-and-apply-log
```
  注記
  
  前述のコマンドでは、s2 と s3 のバイナリログとリレーログのベース名が同じで、2 つのサーバー上の同じ場所にあることを前提としています。これらの条件が満たされていない場合は、--log-bin および --relay-log オプションを使用してバイナリログを復元し、s3 上の元のファイルパスにログをリレーするようにしてください。たとえば、s3 でバイナリログベース名が s3-bin で、リレーログベース名が s3-relay-bin であることがわかっている場合、restore コマンドは次のようになります:
```
mysqlbackup --defaults-file=/etc/my.cnf \
  --datadir=/var/lib/mysql \
  --backup-image=/backups/my.mbi_2206_1429  \
  --log-bin=s3-bin --relay-log=s3-relay-bin \
  --backup-dir=/tmp/restore_`date +%d%m_%H%M` copy-back-and-apply-log
```
  バイナリログとリレーログを正しいファイルパスに復元できるため、復元プロセスが容易になります。何らかの理由で復元できない場合は、新規メンバーとして再結合するための失敗したメンバーの再構築を参照してください。
s3 の auto.cnf ファイルをリストアします。 レプリケーショングループに再度参加するには、リストアされたメンバーが以前にグループへの参加に使用したものと同じ server_uuid を持っている必要があります。前述のステップ 2 で保持した auto.cnf ファイルをリストアされたメンバーのデータディレクトリにコピーして、古いサーバー UUID を指定します。

注記

古い auto.cnf ファイルをリストアして、障害が発生したメンバーの元の server_uuid をリストアされたメンバーに提供できない場合は、リストアされたメンバーを新しいメンバーとしてグループに参加させる必要があります。その方法は、次の新規メンバーとして再結合するための失敗したメンバーの再構築の手順を参照してください。
s3 の mysqld-auto.cnf ファイルをリストアします (s3 で永続システム変数が使用されている場合にのみ必要)。 失敗したメンバーの構成に使用されたセクション5.1.9.3「永続化されるシステム変数」の設定は、リストアされたメンバーに指定する必要があります。これらの設定は、前述のステップ 2 で保持した障害が発生したサーバーの mysqld-auto.cnf ファイルにあります。リストアされたサーバーのデータディレクトリにファイルをリストアします。ファイルのコピーがない場合の対処方法は、永続化されたシステム変数のリストアを参照してください。
リストアされたサーバーを起動します。 たとえば、systemd を使用する Linux ディストリビューションの場合:
```
systemctl start mysqld
```
注記

リストアするサーバーがプライマリメンバーである場合は、プライマリメンバーのリストアリストアされたサーバーを起動する前で説明されているステップを実行します。
Group Replication を再起動します。 mysql クライアントなどを使用して再起動した s3 に接続し、次のコマンドを発行します:
```
mysql> START GROUP_REPLICATION;
```
リストアされたインスタンスがグループのオンラインメンバーになる前に、バックアップの作成後にグループに発生したトランザクションを適用する必要があります。これは Group Replication distributed recovery メカニズムを使用して実現され、START GROUP_REPLICATION ステートメントの発行後にプロセスが開始されます。リストアされたインスタンスのメンバーステータスを確認するには、次のコマンドを発行します:
```
mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s1          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s3          |        3306 | RECOVERING   |
+-------------+-------------+--------------+
```
これは、s3 がグループをキャッチアップするためにトランザクションを適用していることを示しています。残りのグループで捕捉されると、その member_state は ONLINE に変更されます:
```
mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s1          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s3          |        3306 | ONLINE       |
+-------------+-------------+--------------+
```
注記

リストアするサーバーがプライマリメンバーである場合、グループとの同期を取得して ONLINE になったら、プライマリメンバーのリストアの最後に記載されているステップを実行して、サーバーを起動する前に行った構成の変更を元に戻します。

これで、メンバーはバックアップから完全にリストアされ、グループの通常のメンバーとして機能します。

新規メンバーとして再結合するための失敗したメンバーの再構築

バイナリログまたはリレーログが破損している、あるいは単にバックアップから欠落しているなどの理由で、失敗したメンバーのリストアで前述の手順を実行できない場合があります。このような場合は、バックアップを使用してメンバーを再構築し、新しいメンバーとしてグループに追加します。次のステップでは、再構築されたメンバーは、障害が発生したメンバーと同様に s3 という名前であり、s3 と同じホスト上で実行されていると想定しています:

s2 のバックアップを s3 のホストにコピーします。 バックアップをコピーする正確な方法は、使用可能なオペレーティングシステムおよびツールによって異なります。この例では、ホストが両方とも Linux サーバーであり、SCP を使用してホスト間でファイルをコピーすることを前提としています:
```
s2/backups> scp my.mbi_2206_1429 s3:/backups
```
バックアップをリストアします。 ターゲットホスト (この場合は s3 のホスト) に接続し、MySQL Enterprise Backup を使用してバックアップをリストアします。ステップは次のとおりです:
1. 破損したサーバーがまだ実行されている場合は、停止します。たとえば、systemd を使用する Linux ディストリビューションの場合:
```
s3> systemctl stop mysqld
```
2. 破損したサーバーデータディレクトリに見つかった場合は、データディレクトリ外の安全な場所にコピーして、構成ファイル mysqld-auto.cnf を保持します。これは、あとで必要になるサーバーセクション5.1.9.3「永続化されるシステム変数」を保持するためのものです。
3. s3 のデータディレクトリ内のすべてのコンテンツを削除します。例:
```
s3> rm -rf /var/lib/mysql/*
```
  システム変数 innodb_data_home_dir、innodb_log_group_home_dir および innodb_undo_directory がデータディレクトリ以外のディレクトリを指している場合は、それらも空にする必要があります。そうしないと、リストア操作は失敗します。
4. s2 のバックアップを s3 のホストにリストアします。このアプローチでは、s3 を新しいメンバーとして再構築するため、古いバイナリログおよびリレーログをバックアップで使用する必要はありません。したがって、これらのログがバックアップに含まれている場合は、--skip-binlog および --skip-relaylog オプションを使用して除外します:
```
s3> mysqlbackup --defaults-file=/etc/my.cnf \
  --datadir=/var/lib/mysql \
  --backup-image=/backups/my.mbi_2206_1429  \
  --backup-dir=/tmp/restore_`date +%d%m_%H%M` \
  --skip-binlog --skip-relaylog \
  copy-back-and-apply-log
```
  注記
  
  問題なくターゲットホストに転送できる正常なバイナリログおよびリレーログがバックアップにある場合は、前述の失敗したメンバーのリストアで説明した簡単な手順に従うことをお薦めします。
s3 の mysqld-auto.cnf ファイルをリストアします (s3 で永続システム変数が使用されている場合にのみ必要)。 障害が発生したメンバーの構成に使用されたセクション5.1.9.3「永続化されるシステム変数」の設定は、リストアされたサーバーに指定する必要があります。これらの設定は、前述のステップ 2 で保持した障害が発生したサーバーの mysqld-auto.cnf ファイルにあります。リストアされたサーバーのデータディレクトリにファイルをリストアします。ファイルのコピーがない場合の対処方法は、永続化されたシステム変数のリストアを参照してください。

注記

破損したサーバー auto.cnf ファイルを新しいメンバーのデータディレクトリにリストアしないでください。再構築された s3 が新しいメンバーとしてグループに参加すると、新しいサーバー UUID が割り当てられます。
リストアされたサーバーを起動します。 たとえば、systemd を使用する Linux ディストリビューションの場合:
```
systemctl start mysqld
```
注記

リストアするサーバーがプライマリメンバーである場合は、プライマリメンバーのリストアリストアされたサーバーを起動する前で説明されているステップを実行します。
グループレプリケーションに参加するようにリストアされたメンバーを再構成します。 mysql クライアントを使用してリストアされたサーバーに接続し、次のコマンドを使用してソースおよびレプリカ情報をリセットします:
```
mysql> RESET MASTER;
```
```
mysql> RESET SLAVE ALL;
Or from MySQL 8.0.22:
mysql> RESET REPLICA ALL;
```
distributed recovery の Group Replication 組込みメカニズムを使用して、リストアされたサーバーを自動的にリカバリできるようにするには、サーバーの gtid_executed 変数を構成します。これを行うには、s2 のバックアップに含まれる backup_gtid_executed.sql ファイルを使用します。これは通常、リストアされたメンバーデータディレクトリの下にリストアされます。バイナリロギングを無効にし、backup_gtid_executed.sql ファイルを使用して gtid_executed を構成してから、mysql クライアントで次のステートメントを発行してバイナリロギングを再度有効にします:
```
mysql> SET SQL_LOG_BIN=OFF;
mysql> SOURCE datadir/backup_gtid_executed.sql
mysql> SET SQL_LOG_BIN=ON;
```
次に、メンバーで Group Replication user credentials を構成します:
```
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' /
		FOR CHANNEL 'group_replication_recovery';

Or from MySQL 8.0.23:
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' /
		FOR CHANNEL 'group_replication_recovery';
```
Group Replication を再起動します。 mysql クライアントを使用して、リストアされたサーバーに次のコマンドを発行します:
```
mysql> START GROUP_REPLICATION;
```
リストアされたインスタンスがグループのオンラインメンバーになる前に、バックアップの作成後にグループに発生したトランザクションを適用する必要があります。これは Group Replication distributed recovery メカニズムを使用して実現され、START GROUP_REPLICATION ステートメントの発行後にプロセスが開始されます。リストアされたインスタンスのメンバーステータスを確認するには、次のコマンドを発行します:
```
mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s3          |        3306 | RECOVERING   |
| s2          |        3306 | ONLINE       |
| s1          |        3306 | ONLINE       |
+-------------+-------------+--------------+
```
これは、s3 がグループをキャッチアップするためにトランザクションを適用していることを示しています。残りのグループで捕捉されると、その member_state は ONLINE に変更されます:
```
mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s3          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s1          |        3306 | ONLINE       |
+-------------+-------------+--------------+
```
注記

リストアするサーバーがプライマリメンバーである場合、グループとの同期を取得して ONLINE になったら、プライマリメンバーのリストアの最後に記載されているステップを実行して、サーバーを起動する前に行った構成の変更を元に戻します。

これで、メンバーは新しいメンバーとしてグループに復元されました。

永続化されたシステム変数のリストア. mysqlbackup では、セクション5.1.9.3「永続化されるシステム変数」-the ファイルのバックアップまたは保存をサポートしていません mysqld-auto.cnf はバックアップに含まれていません。リストアされたメンバーを永続変数設定で開始するには、次のいずれかを実行する必要があります:

破損したサーバーからの mysqld-auto.cnf ファイルのコピーを保持し、リストアしたサーバーデータディレクトリにコピーします。
mysqld-auto.cnf ファイルをグループの別のメンバーからリストアされたサーバーデータディレクトリにコピーします (そのメンバーに破損したメンバーと同じ永続システム変数設定がある場合)。
リストアされたサーバーの起動後、グループレプリケーションを再起動する前に、mysql クライアントを介してすべてのシステム変数を手動で永続化された値に設定します。

プライマリメンバーのリストア. リストアされたメンバーがグループ内のプライマリである場合は、グループレプリケーション分散リカバリプロセス中にリストアされたデータベースへの書込みを防ぐように注意する必要があります。クライアントによるグループへのアクセス方法に応じて、リストアされたメンバーがネットワーク上でアクセス可能になると、メンバーがグループ外でミスしたアクティビティのキャッチアップを終了する前に、そのメンバーに対して DML ステートメントが実行される可能性があります。これを回避するには、リストアされたサーバーを起動する前でサーバーオプションファイルに次のシステム変数を構成します:

group_replication_start_on_boot=OFF
super_read_only=ON
event_scheduler=OFF

これらの設定により、起動時にメンバーが読取り専用になり、分散リカバリプロセス中にメンバーがグループで捕捉されている間、イベントスケジューラがオフになります。適切なエラー処理は、リストアされたメンバーでこの期間中に一時的に DML 操作を実行できないように、クライアントでも構成する必要があります。リストアプロセスが完全に完了し、リストアされたメンバーがグループの残りの部分と同期したら、これらの変更を元に戻し、イベントスケジューラを再起動します:

mysql> SET global event_scheduler=ON;

メンバーオプションファイルで次のシステム変数を編集して、次回の起動時に正しく構成されるようにします:

group_replication_start_on_boot=ON
super_read_only=OFF
event_scheduler=ON

PREV HOME UP NEXT