次の各セクションでは、レプリカの設定方法について説明します。 続行する前に、次のことを確認してください:
必要な構成プロパティを使用してソースを構成しました。 セクション17.1.2.1「レプリケーションソース構成の設定」を参照してください。
データスナップショットのシャットダウン中に作成されたソースステータス情報またはソースバイナリログインデックスファイルのコピーを取得しました。 セクション17.1.2.4「レプリケーションソースのバイナリログ座標の取得」を参照してください。
-
ソースで、読み取りロックを解放します:
mysql> UNLOCK TABLES; レプリカで、MySQL 構成を編集しました。 セクション17.1.2.2「レプリカ構成の設定」を参照してください。
次のステップは、レプリカにインポートする既存のデータがあるかどうかによって異なります。 詳しくはセクション17.1.2.5「データスナップショットの方法の選択」をご覧ください。 次のいずれかを選択します:
インポートするデータベースのスナップショットがない場合は、セクション17.1.2.6.1「新しいソースおよびレプリカを使用したレプリケーションの設定」 を参照してください。
インポートするデータベースのスナップショットがある場合は、セクション17.1.2.6.2「既存のデータによるレプリケーションのセットアップ」 を参照してください。
インポートする以前のデータベースのスナップショットがない場合は、新しいソースからレプリケーションを開始するようにレプリカを構成します。
ソースと新しいレプリカ間のレプリケーションを設定するには:
レプリカを起動します。
レプリカに対して
CHANGE REPLICATION SOURCE TO|CHANGE MASTER TOステートメントを実行し、ソース構成を設定します。 セクション17.1.2.7「レプリカでのソース構成の設定」を参照してください。
各レプリカで次のレプリカ設定ステップを実行します。
この方法は、新しいサーバーを設定しているが、レプリケーション構成にロードする別のサーバーのデータベースの既存のダンプがある場合にも使用できます。 データを新しいソースにロードすると、データはレプリカに自動的にレプリケートされます。
別の既存のデータベースサーバーのデータを使用して新しいレプリケーション環境を設定して新しいソースを作成する場合は、そのサーバーから生成されたダンプファイルを新しいソースで実行します。 データベース更新はレプリカに自動的に伝播されます:
shell> mysql -h source < fulldb.dump既存のデータを使用してレプリケーションを設定する場合は、レプリケーションを開始する前に、スナップショットをソースからレプリカに転送します。 レプリカにデータをインポートするプロセスは、ソースでのデータのスナップショットの作成方法によって異なります。
MySQL の複数のインスタンスをデプロイするには、MySQL Shell で MySQL サーバーインスタンスのグループを簡単に管理できるようにする InnoDB クラスタ を使用できます。InnoDB クラスタ は MySQL Group Replication をプログラム環境でラップするため、MySQL インスタンスのクラスタを簡単にデプロイして高可用性を実現できます。 また、InnoDB クラスタ は MySQL Router とシームレスにインタフェースするため、アプリケーションは独自のフェイルオーバープロセスを記述せずにクラスタに接続できます。 ただし、高可用性を必要としない同様のユースケースでは、InnoDB ReplicaSet を使用できます。 MySQL Shell のインストール手順は、here にあります。
新しいレプリカを作成するためにコピーするレプリケーションソースサーバーまたは既存のレプリカにスケジュールされたイベントがある場合は、それらが新しいレプリカで無効になっていることを確認してから開始してください。 ソースですでに実行されている新しいレプリカでイベントが実行されると、複製された操作によってエラーが発生します。 イベントスケジューラは、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「レプリケーション用のクローニング」 を参照)、データはすでに転送されています。 それ以外の場合は、次のいずれかの方法を使用してレプリカにデータをインポートします。
-
mysqldump を使用した場合は、レプリケーションが開始されないように、
--skip-slave-startオプションを使用してレプリカを起動します。 次に、ダンプファイルをインポートします:shell> mysql < fulldb.dump -
RAW データファイルを使用してスナップショットを作成した場合は、データファイルをレプリカデータディレクトリに抽出します。 例:
shell> tar xvf dbdump.tarレプリカサーバーがファイルにアクセスして変更できるように、ファイルに対する権限と所有権の設定が必要になる場合があります。 次に、レプリケーションが開始されないように、
--skip-slave-startオプションを使用してレプリカを起動します。
-
ソースのレプリケーション座標を使用してレプリカを構成します。 これにより、レプリケーションを開始する必要があるバイナリログファイルおよびファイル内の位置がレプリカに通知されます。 また、ソースのログイン資格証明とホスト名を使用してレプリカを構成します。 必要な
CHANGE REPLICATION SOURCE TO|CHANGE MASTER TOステートメントの詳細は、セクション17.1.2.7「レプリカでのソース構成の設定」 を参照してください。START REPLICA | SLAVEステートメントを発行してレプリケーションスレッドを起動します。
この手順を実行すると、レプリカはソースに接続し、スナップショットの取得後にソースで発生した更新をレプリケートします。 なんらかの理由でレプリケートできない場合、エラーメッセージがレプリカエラーログに発行されます。
レプリカは、接続メタデータリポジトリおよび適用者メタデータリポジトリに記録された情報を使用して、処理されたソースバイナリログの量を追跡します。 MySQL 8.0 からは、デフォルトで、これらのリポジトリは mysql データベース内の slave_master_info および slave_relay_log_info という名前のテーブルです。 実行内容を正確に把握し、その影響を完全に理解していないかぎり、これらのテーブルを削除または編集しないでください。 その場合でも、レプリケーションパラメータを変更するには、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを使用することをお薦めします。 レプリカは、ステートメントで指定された値を使用して、レプリケーションメタデータリポジトリを自動的に更新します。 詳しくはセクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」,をご覧ください。
レプリカ接続メタデータリポジトリの内容は、コマンドラインまたは my.cnf で指定されたサーバーオプションの一部をオーバーライドします。 詳細については、セクション17.1.6「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。
ソースの単一のスナップショットでは、複数のレプリカで十分です。 追加のレプリカを設定するには、同じソーススナップショットを使用して、前述の手順のレプリカ部分に従います。