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

17.1.2.8 レプリケーション環境へのレプリカの追加

ソースサーバーを停止せずに、既存のレプリケーション構成に別のレプリカを追加できます。 これを行うには、既存のレプリカのデータディレクトリをコピーし、新しいレプリカに別のサーバー ID (ユーザー指定) およびサーバー UUID (起動時に生成) を指定して、新しいレプリカを設定します。

注記

新しいレプリカを作成するためにコピーするレプリケーションソースサーバーまたは既存のレプリカにスケジュールされたイベントがある場合は、それらが新しいレプリカで無効になっていることを確認してから開始してください。 ソースですでに実行されている新しいレプリカでイベントが実行されると、複製された操作によってエラーが発生します。 イベントスケジューラは、event_scheduler システム変数によって制御されます。このシステム変数のデフォルトは MySQL 8.0 の ON であるため、元のサーバーでアクティブなイベントは、新しいレプリカの起動時にデフォルトで実行されます。 新しいレプリカでのすべてのイベントの実行を停止するには、新しいレプリカで event_scheduler システム変数を OFF または DISABLED に設定します。 または、ALTER EVENT ステートメントを使用して個々のイベントを DISABLE または DISABLE ON SLAVE に設定し、新しいレプリカで実行されないようにすることもできます。 SHOW ステートメントまたは情報スキーマ EVENTS テーブルを使用して、サーバー上のイベントをリストできます。 詳細は、セクション17.5.1.16「呼び出される機能のレプリケーション」を参照してください。

この方法で新しいレプリカを作成するかわりに、MySQL Server クローンプラグインを使用して、既存のレプリカからクローンにすべてのデータおよびレプリケーション設定を転送できます。 この方法の使用手順は、セクション5.6.7.6「レプリケーション用のクローニング」 を参照してください。

クローニングせずに既存のレプリカを複製するには、次のステップに従います:

1. 既存のレプリカを停止し、レプリカステータス情報 (特にソースバイナリログファイルとリレーログファイルの位置) を記録します。 レプリカステータスは、パフォーマンススキーマレプリケーションテーブル (セクション27.12.11「パフォーマンススキーマレプリケーションテーブル」 を参照) で表示するか、次のように SHOW REPLICA | SLAVE STATUS を発行して表示できます:

   mysql> STOP SLAVE;
   mysql> SHOW SLAVE STATUS\G
   Or from MySQL 8.0.22:
   mysql> STOP REPLICA;
   mysql> SHOW REPLICA STATUS\G

2. 既存のレプリカを停止します:

   shell> mysqladmin shutdown

3. ログファイルやリレーログファイルなど、既存のレプリカから新しいレプリカにデータディレクトリをコピーします。 これを行うには、tar または WinZip を使用してアーカイブを作成するか、cp、rsync などのツールを使用して直接コピーを実行します。

   重要

   • コピーする前に、既存のレプリカに関連するすべてのファイルが実際にデータディレクトリに格納されていることを確認します。 たとえば、InnoDB のシステムテーブルスペース、undo テーブルスペースおよび redo ログを別の場所に格納できます。 InnoDB テーブルスペースファイルおよび file-per-table テーブルスペースが他のディレクトリに作成されている可能性があります。 レプリカのバイナリログおよびリレーログは、データディレクトリ外の独自のディレクトリに存在する場合があります。 既存のレプリカに設定されているシステム変数を確認し、指定されている代替パスを探します。 見つかった場合は、これらのディレクトリもコピーします。

   • コピー中に、レプリケーションメタデータリポジトリにファイルが使用されている場合 (セクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」 を参照)、これらのファイルも既存のレプリカから新しいレプリカにコピーしてください。 リポジトリにテーブルが使用されている場合 (MySQL 8.0 のデフォルト)、テーブルはデータディレクトリにあります。

   • コピー後、新しいレプリカのデータディレクトリのコピーから auto.cnf ファイルを削除して、生成された別のサーバー UUID で新しいレプリカが開始されるようにします。 サーバー UUID は一意である必要があります。

   新しいレプリカの追加時に発生する一般的な問題は、新しいレプリカが次のような一連の警告およびエラーメッセージで失敗することです:

   071118 16:44:10 [Warning] Neither --relay-log nor --relay-log-index were used; so
   replication may break when this MySQL server acts as a replica and has his hostname
   changed!! Please use '--relay-log=new_replica_hostname-relay-bin' to avoid this problem.
   071118 16:44:10 [ERROR] Failed to open the relay log './old_replica_hostname-relay-bin.003525'
   (relay_log_pos 22940879)
   071118 16:44:10 [ERROR] Could not find target log during relay log initialization
   071118 16:44:10 [ERROR] Failed to initialize the master info structure

   リレーログファイルにはファイル名の一部としてホスト名が含まれているため、この状況は relay_log システム変数が指定されていない場合に発生することがあります。 これは、relay_log_index システム変数が使用されない場合のリレーログインデックスファイルにも当てはまります。 これらの変数の詳細は、セクション17.1.6「レプリケーションおよびバイナリロギングのオプションと変数」 を参照してください。

   この問題を回避するには、既存のレプリカで使用された新しいレプリカの relay_log に同じ値を使用します。 このオプションが既存のレプリカで明示的に設定されていない場合は、existing_replica_hostname-relay-bin を使用します。 これが不可能な場合は、既存のレプリカリレーログインデックスファイルを新しいレプリカにコピーし、既存のレプリカで使用されたものと一致するように新しいレプリカの relay_log_index システム変数を設定します。 このオプションが既存のレプリカで明示的に設定されていない場合は、existing_replica_hostname-relay-bin.index を使用します。 または、このセクションの残りのステップに従って新しいレプリカを起動しようとし、前述のようなエラーが発生した場合は、次のステップを実行します:

   1. まだ実行していない場合は、新しいレプリカで STOP REPLICA | SLAVE を発行します。

      既存のレプリカをすでに再起動している場合は、既存のレプリカでも STOP REPLICA | SLAVE を発行します。

   2. 既存のレプリカリレーログインデックスファイルの内容を新しいレプリカリレーログインデックスファイルにコピーし、ファイル内にすでに存在する内容を上書きしてください。

   3. このセクションの残りの手順に進みます。

4. コピーが完了したら、既存のレプリカを再起動します。

5. 新しいレプリカで構成を編集し、新しいレプリカに、ソースまたは既存のレプリカで使用されていない一意のサーバー ID (server_id システム変数を使用) を指定します。

6. レプリケーションがまだ開始されないように、--skip-slave-start オプションを指定して新しいレプリカサーバーを起動します。 パフォーマンススキーマレプリケーションテーブルを使用するか、SHOW REPLICA | SLAVE STATUS を発行して、既存のレプリカと比較して新しいレプリカの設定が正しいことを確認します。 また、サーバー ID とサーバー UUID を表示し、これらが正しいことと、新しいレプリカに対して一意であることを確認します。

7. START REPLICA | SLAVE ステートメントを発行してレプリカスレッドを起動します。 これで、新しいレプリカは接続メタデータリポジトリの情報を使用してレプリケーションプロセスを開始します。