このページは機械翻訳したものです。
ReplicaSet を作成したら、
操作を使用して、ReplicaSet の現在のプライマリの読取り専用セカンダリレプリカとしてインスタンスを追加できます。 ReplicaSet のプライマリは、この操作中にアクセス可能で使用可能である必要があります。 MySQL レプリケーションは、ランダムパスワードを使用して自動的に作成された MySQL アカウントを使用して、追加されたインスタンスとプライマリの間で構成されます。 インスタンスをオペレーショナルセカンダリにするには、プライマリと同期している必要があります。 このプロセスはリカバリと呼ばれ、InnoDB ReplicaSet では、ReplicaSet
.addInstance()recoveryMethod
オプションを使用して構成する様々な方法がサポートされます。
インスタンスが ReplicaSet に参加できるようにするには、様々な前提条件を満たす必要があります。 これらは
によって自動的にチェックされ、問題が見つかった場合は操作が失敗します。 インスタンスを追加する前に、ReplicaSet
.addInstance()dba.configureReplicaSetInstance()
を使用してバイナリログおよびレプリケーション関連のオプションを検証および構成します。MySQL Shell は、ReplicaSet
ハンドルオブジェクトの取得に使用したものと同じユーザー名とパスワードを使用してターゲットインスタンスに接続します。 ReplicaSet のすべてのインスタンスには、同じ権限付与およびパスワードを持つ同じ管理者アカウントが必要です。 必要な権限を持つカスタム管理者アカウントは、インスタンスが dba.configureReplicaSetInstance()
で構成されている間に作成できます。 InnoDB ReplicaSet インスタンスの構成を参照してください。
新しいインスタンスを InnoDB ReplicaSet に追加する場合は、それに含まれる既存のデータをプロビジョニングする必要があります。 これは、次のいずれかの方法を使用して自動的に実行できます:
-
MySQL クローン:オンラインインスタンスからスナップショットを取得し、新しいインスタンスのデータをスナップショットに置き換えます。 MySQL クローンは、新しい空白インスタンスを InnoDB ReplicaSet に結合する場合に適しています。 InnoDB ReplicaSet によって適用されるすべてのトランザクションの完全なバイナリログがあることに依存するわけではありません。
警告追加されるインスタンス上の以前のデータはすべて、クローン操作中に破棄されます。 ただし、テーブルに格納されていないすべての MySQL 設定は保持されます。
増分リカバリ: MySQL レプリケーションに依存して、欠落しているすべてのトランザクションを新しいインスタンスに適用します。 新しいインスタンスで欠落しているトランザクションの量が少ない場合、これが最速の方法になる可能性があります。 ただし、この方法は、InnoDB ReplicaSet 内の少なくとも 1 つのオンラインインスタンスに、InnoDB ReplicaSet のトランザクション履歴全体を含む完全なバイナリログがある場合にのみ使用できます。 バイナリログがすべてのメンバーからパージされた場合、またはバイナリログがインスタンスにすでに存在する後にのみ有効化された場合、このメソッドは使用できません。 適用するトランザクションの量が非常に多い場合、インスタンスが InnoDB ReplicaSet に参加するまでに長い遅延が発生する可能性があります。
インスタンスが ReplicaSet に参加している場合、リカバリは InnoDB クラスタ とほぼ同じ方法で使用されます。MySQL Shell は、適切なリカバリ方法を自動的に選択しようとします。 安全に方法を選択できない場合は、MySQL Shell によって使用する内容の入力を求められます。 詳細は、セクション6.2.2.2「InnoDB クラスタ での MySQL クローンの使用」を参照してください。 このセクションでは、ReplicaSet にインスタンスを追加する場合の相違点について説明します。
操作を使用して、セカンダリインスタンスを ReplicaSet
.addInstance(instance
)ReplicaSet
に追加します。 URI のような接続文字列として instance
を指定します。 指定するユーザーは必要な権限を持っている必要があり、ReplicaSet のすべてのインスタンスで同じである必要があります。InnoDB ReplicaSet インスタンスの構成 を参照してください。
たとえば、ユーザー rsadmin
を使用して rs-2
でインスタンスを追加するには、次のように発行します:
mysql-js> rs.addInstance('rsadmin@rs-2')
Adding instance to the replicaset...
* Performing validation checks
This instance reports its own address as rsadmin@rs-2
rsadmin@rs-2: Instance configuration is suitable.
* Checking async replication topology...
* Checking transaction state of the instance...
NOTE: The target instance 'rsadmin@rs-2' has not been pre-provisioned (GTID set
is empty). The Shell is unable to decide whether replication can completely
recover its state. The safest and most convenient way to provision a new
instance is through automatic clone provisioning, which will completely
overwrite the state of 'rsadmin@rs-2' with a physical snapshot from an existing
replicaset member. To use this method by default, set the 'recoveryMethod'
option to 'clone'.
WARNING: It should be safe to rely on replication to incrementally recover the
state of the new instance if you are sure all updates ever executed in the
replicaset were done with GTIDs enabled, there are no purged transactions and
the new instance contains the same GTID set as the replicaset or a subset of it.
To use this method by default, set the 'recoveryMethod' option to 'incremental'.
Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone):
この場合、リカバリ方法を指定しなかったため、最適な方法が示されます。 この例では、ReplicaSet に参加するインスタンスに既存のトランザクションがないため、クローンオプションを選択します。 したがって、結合中のインスタンスからデータを削除するリスクはありません。
Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone): C
* Updating topology
Waiting for clone process of the new member to complete. Press ^C to abort the operation.
* Waiting for clone to finish...
NOTE: rsadmin@rs-2 is being cloned from rsadmin@rs-1
** Stage DROP DATA: Completed
** Clone Transfer
FILE COPY ############################################################ 100% Completed
PAGE COPY ############################################################ 100% Completed
REDO COPY ############################################################ 100% Completed
** Stage RECOVERY: \
NOTE: rsadmin@rs-2 is shutting down...
* Waiting for server restart... ready
* rsadmin@rs-2 has restarted, waiting for clone to finish...
* Clone process has finished: 59.63 MB transferred in about 1 second (~1.00 B/s)
** Configuring rsadmin@rs-2 to replicate from rsadmin@rs-1
** Waiting for new instance to synchronize with PRIMARY...
The instance 'rsadmin@rs-2' was added to the replicaset and is replicating from rsadmin@rs-1.
インスタンスが InnoDB ReplicaSet の使用に有効であると仮定すると、リカバリは続行されます。 この場合、新しく結合されたインスタンスは MySQL クローンを使用して、まだプライマリから適用されていないすべてのトランザクションをコピーし、ReplicaSet をオンラインインスタンスとして結合します。 確認するには、
操作を使用します:
ReplicaSet
.status()
mysql-js> rs.status()
{
"replicaSet": {
"name": "example",
"primary": "rs-1:3306",
"status": "AVAILABLE",
"statusText": "All instances available.",
"topology": {
"rs-1:3306": {
"address": "rs-1:3306",
"instanceRole": "PRIMARY",
"mode": "R/W",
"status": "ONLINE"
},
"rs-2:3306": {
"address": "rs-2:3306",
"instanceRole": "SECONDARY",
"mode": "R/O",
"replication": {
"applierStatus": "APPLIED_ALL",
"applierThreadState": "Replica has read all relay log; waiting for more updates",
"receiverStatus": "ON",
"receiverThreadState": "Waiting for source to send event",
"replicationLag": null
},
"status": "ONLINE"
}
},
"type": "ASYNC"
}
}
この出力は、example
という名前の ReplicaSet が 2 つの MySQL インスタンスで構成され、プライマリが rs-1
であることを示しています。 現在、プライマリのレプリカであるセカンダリインスタンスが rs-2
にあります。 ReplicaSet はオンラインであり、プライマリとセカンダリが同期していることを意味します。 この時点で、ReplicaSet はトランザクションを処理する準備ができています。
最適なリカバリ方法を選択しようとする対話型 MySQL Shell モードをオーバーライドする場合は、recoveryMethod
オプションを使用して、ReplicaSet に参加するために必要なデータをインスタンスがリカバリする方法を構成します。 詳細は、セクション6.2.2.2「InnoDB クラスタ での MySQL クローンの使用」を参照してください。