ソースサーバーを停止せずに、既存のレプリケーション構成に別のレプリカを追加できます。 これを行うには、既存のレプリカのデータディレクトリをコピーし、新しいレプリカに別のサーバー 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「レプリケーション用のクローニング」 を参照してください。
クローニングせずに既存のレプリカを複製するには、次のステップに従います:
-
既存のレプリカを停止し、レプリカステータス情報 (特にソースバイナリログファイルとリレーログファイルの位置) を記録します。 レプリカステータスは、パフォーマンススキーマレプリケーションテーブル (セクション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 -
既存のレプリカを停止します:
shell> mysqladmin shutdown -
ログファイルやリレーログファイルなど、既存のレプリカから新しいレプリカにデータディレクトリをコピーします。 これを行うには、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-binrelay_log_indexシステム変数を設定します。 このオプションが既存のレプリカで明示的に設定されていない場合は、existing_replica_hostname-relay-bin.index-
まだ実行していない場合は、新しいレプリカで
STOP REPLICA | SLAVEを発行します。既存のレプリカをすでに再起動している場合は、既存のレプリカでも
STOP REPLICA | SLAVEを発行します。 既存のレプリカリレーログインデックスファイルの内容を新しいレプリカリレーログインデックスファイルにコピーし、ファイル内にすでに存在する内容を上書きしてください。
このセクションの残りの手順に進みます。
コピーが完了したら、既存のレプリカを再起動します。
新しいレプリカで構成を編集し、新しいレプリカに、ソースまたは既存のレプリカで使用されていない一意のサーバー ID (
server_idシステム変数を使用) を指定します。レプリケーションがまだ開始されないように、
--skip-slave-startオプションを指定して新しいレプリカサーバーを起動します。 パフォーマンススキーマレプリケーションテーブルを使用するか、SHOW REPLICA | SLAVE STATUSを発行して、既存のレプリカと比較して新しいレプリカの設定が正しいことを確認します。 また、サーバー ID とサーバー UUID を表示し、これらが正しいことと、新しいレプリカに対して一意であることを確認します。START REPLICA | SLAVEステートメントを発行してレプリカスレッドを起動します。 これで、新しいレプリカは接続メタデータリポジトリの情報を使用してレプリケーションプロセスを開始します。