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

6.2.2.2 InnoDB クラスタ での MySQL クローンの使用

6.2.2.2.1 MySQL クローンを使用するクラスタの操作

MySQL 8.0.17 では、InnoDB クラスタ は MySQL クローンプラグインを統合して、参加インスタンスの自動プロビジョニングを提供します。 インスタンスがクラスタと同期できるようにクラスタデータを取得するプロセスは、分散リカバリと呼ばれます。 インスタンスでクラスタトランザクションをリカバリする必要がある場合は、ドナー (データを提供するクラスタインスタンス) と受信者 (ドナーからデータを受信するインスタンス) を区別します。 以前のバージョンでは、グループレプリケーションは、結合しているインスタンスがクラスタに結合できるようにクラスタと同期するために必要なトランザクションをリカバリするために非同期レプリケーションのみを提供していました。 以前に処理されたトランザクションが大量にあるクラスタでは、クラスタに参加する前に、新しいインスタンスがすべてのトランザクションをリカバリするのに時間がかかる場合があります。 または、GTID をパージしたクラスタ (定期的な保守の一部など) で、新しいインスタンスのリカバリに必要なトランザクションの一部が欠落している可能性があります。 このような場合の唯一の代替方法は、グループレプリケーションでの MySQL Enterprise Backup の使用 に示すように、MySQL Enterprise Backup などのツールを使用してインスタンスを手動でプロビジョニングすることでした。

MySQL クローンは、インスタンスがクラスタとの同期に必要なトランザクションをリカバリするための代替方法を提供します。 非同期レプリケーションを使用してトランザクションをリカバリするかわりに、MySQL クローンはドナーインスタンス上のデータのスナップショットを取得し、そのスナップショットを受信者に転送します。

警告

レシーバ内の以前のデータはすべて、クローン操作中に破棄されます。 ただし、テーブルに格納されていないすべての MySQL 設定は保持されます。

クローン操作によってスナップショットが受信者に転送されると、スナップショットの転送中にクラスタでトランザクションが処理された場合、非同期レプリケーションを使用して、受信者とクラスタの同期に必要なデータがリカバリされます。 これは、非同期レプリケーションを使用してすべてのトランザクションをリカバリするインスタンスよりもはるかに効率的であり、パージされた GTID によって発生する問題を回避して、InnoDB クラスタ の新しいインスタンスを迅速にプロビジョニングできます。 詳細は、クローンプラグインおよび分散リカバリのためのクローニングを参照してください

MySQL クローンの使用とは対照的に、増分リカバリは、クラスタに参加しているインスタンスが非同期レプリケーションのみを使用してクラスタからインスタンスをリカバリするプロセスです。 InnoDB クラスタ が MySQL クローンを使用するように構成されている場合、クラスタに参加するインスタンスは、MySQL クローンまたは増分リカバリのいずれかを使用してクラスタトランザクションをリカバリします。 デフォルトでは、クラスタは最適な方法を自動的に選択しますが、オプションでこの動作を構成してクローニングを強制できます。これにより、結合インスタンスによってすでに処理されているトランザクションが置換されます。 MySQL Shell を対話モードで使用している場合、デフォルトでは、クラスタがリカバリを続行できるかどうかがわからない場合は、対話型プロンプトが表示されます。 このセクションでは、提供される様々なオプションと、選択できるオプションに影響する様々なシナリオについて説明します。

また、RECOVERING 状態のメンバーに対する Cluster.status() の出力には、MySQL クローンを使用しているか増分リカバリを使用しているかにかかわらず、リカバリ操作を簡単に監視できるリカバリ進捗情報が含まれています。InnoDB クラスタ は、Cluster.status() の出力で MySQL クローンを使用するインスタンスに関する追加情報を提供します。

6.2.2.2.1 MySQL クローンを使用するクラスタの操作

MySQL クローンを使用する InnoDB クラスタ では、次の追加動作が提供されます。

dba.createCluster() および MySQL クローン

バージョン 8.0.17 からは、MySQL クローンプラグインが使用可能なインスタンスに新しいクラスタが作成されると、デフォルトで自動的にインストールされ、クラスタはクローニングをサポートするように構成されます。 InnoDB クラスタ リカバリアカウントは、必要な BACKUP_ADMIN 権限で作成されます。

disableClone ブールオプションを true に設定して、クラスタの MySQL クローンを無効にします。 この場合、この構成のメタデータエントリが追加され、MySQL クローンプラグインがインストールされている場合はアンインストールされます。 disableClone オプションは、dba.createCluster() を発行するとき、または Cluster.setOption() を使用してクラスタを実行しているときにいつでも設定できます。

Cluster.addInstance(instance) および MySQL クローン

新しいインスタンスが MySQL 8.0.17 以降を実行しており、MySQL 8.0.17 以降を実行しているドナーがクラスタ内に少なくとも 1 人 (group_replication_group_seeds リストに含まれている) 存在する場合、MySQL クローンを結合 instance に使用できます。 MySQL クローンを使用するクラスタは、クラスタへのインスタンスの追加 に記載されている動作に従い、クラスタからのインスタンスのリカバリに必要なデータの転送方法の選択肢が追加されています。 Cluster.addInstance(instance) の動作は、次の要因によって異なります:

• MySQL クローンがサポートされているかどうか。

• 増分リカバリが可能かどうか。バイナリログの可用性によって異なります。 たとえば、ドナーインスタンスに必要なすべてのバイナリログ (GTID_PURGED が空) がある場合、増分リカバリが可能です。 すべてのバイナリログが必要なクラスタインスタンスがない場合、増分リカバリはできません。

• 増分リカバリが適切かどうか。 増分リカバリが可能な場合でも、インスタンス上のデータと競合する可能性があるため、ドナーおよびレシーバ上の GTID セットがチェックされ、増分リカバリが適切であることが確認されます。 比較の結果は次のようになります:

  • 新規: レシーバに空の GTID_EXECUTED GTID セットがあります

  • 同一: 受け側にドナー GTID セットと同じ GTID セットがあります

  • 回収可能: 受け側にトランザクションが欠落している GTID セットがありますが、これらはドナーから回収できます

  • 回復不能: トランザクションが欠落している GTID セットがドナーにあります。パージされた可能性があります

  • 多様: ドナーとレシーバの GTID セットが相違しています

  比較の結果が同一またはリカバリ可能と判断された場合、増分リカバリが適切とみなされます。 比較の結果がリカバリ不能または分散と判断された場合、増分リカバリは適切とみなされません。

  新規とみなされるインスタンスの場合、バイナリログがパージされたかどうか、または GTID_PURGED 変数と GTID_EXECUTED 変数がリセットされたかどうかを判断できないため、増分リカバリは適切とみなされません。 または、バイナリログおよび GTID が有効になる前に、サーバーがすでにトランザクションを処理している可能性があります。 したがって、対話型モードでは、増分リカバリを使用することを確認する必要があります。

• gtidSetIsComplete オプションの状態。 完全な GTID セットを使用してクラスタが作成されていることが確実であるため、余分な確認なしで GTID セットが空のインスタンスを追加できる場合は、クラスタレベルの gtidSetIsComplete ブールオプションを true に設定します。

  警告

  gtidSetIsComplete オプションを true に設定すると、含まれているデータに関係なく、結合サーバーがリカバリされ、注意して使用されます。 トランザクションを適用したインスタンスを追加しようとすると、データ破損のリスクがあります。

これらの要因の組合せは、Cluster.addInstance() の発行時にインスタンスがクラスタに参加する方法に影響します。 recoveryMethod オプションはデフォルトで auto に設定されています。つまり、MySQL Shell 対話モードでは、クラスタはクラスタからインスタンスをリカバリするための最適な方法を選択し、続行方法を指示するプロンプトが表示されます。 つまり、クラスタでは、最適なアプローチとサーバーでサポートされている内容に基づいて、MySQL クローンまたは増分リカバリを使用することをお薦めします。 対話モードを使用せず、MySQL Shell をスクリプト化している場合は、recoveryMethod を使用するリカバリのタイプに設定する必要があります - clone または incremental。 このセクションでは、考えられる様々なシナリオについて説明します。

MySQL Shell を対話モードで使用している場合、インスタンスを追加するために使用可能なすべてのオプションを含むメインプロンプトは次のとおりです:

Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone):

前述の要因によっては、これらのオプションの一部が提供されない場合があります。 このセクションで後述するシナリオでは、提供されるオプションについて説明します。 このプロンプトで提供されるオプションは次のとおりです:

• クローン: クラスタに追加するインスタンスにドナーをクローニングし、インスタンスに含まれるトランザクションを削除するには、このオプションを選択します。 MySQL クローンプラグインが自動的にインストールされます。 InnoDB クラスタ リカバリアカウントは、必要な BACKUP_ADMIN 権限で作成されます。 空 (トランザクションを処理していない) または保持しないトランザクションを含むインスタンスを追加する場合は、クローンオプションを選択します。 次に、クラスタは MySQL クローンを使用して、参加しているインスタンスをドナークラスタメンバーからのスナップショットで完全に上書きします。 この方法をデフォルトで使用し、このプロンプトを無効にするには、cluster recoveryMethod オプションを clone に設定します。

• 増分リカバリでは、このオプションを選択して増分リカバリを使用し、非同期レプリケーションを使用して、クラスタで処理されたすべてのトランザクションを結合インスタンスにリカバリします。 増分リカバリは、クラスタで処理されたすべての更新が GTID を有効にして実行されたことが確実な場合に適しており、パージされたトランザクションはなく、新しいインスタンスにはクラスタまたはそのサブセットと同じ GTID セットが含まれています。 この方法をデフォルトで使用するには、recoveryMethod オプションを incremental に設定します。

前述の要因の組合せは、次のようにプロンプトで使用可能なこれらのオプションに影響します:

注記

group_replication_clone_threshold システム変数が AdminAPI の外部で手動で変更されている場合、クラスタは次のシナリオのかわりにクローンリカバリを使用することを決定できます。

• 次の場合

  • 増分リカバリが可能です

  • 増分リカバリが適切ではありません

  • クローンがサポートされています

  いずれかのオプションを選択できます。 デフォルトの MySQL クローンを使用することをお薦めします。

• 次の場合

  • 増分リカバリが可能です

  • 増分リカバリが適切です

  プロンプトが表示されず、増分リカバリが使用されます。

• 次の場合

  • 増分リカバリが可能です

  • 増分リカバリが適切ではありません

  • クローンはサポートされていないか、無効です

  MySQL クローンを使用してインスタンスをクラスタに追加することはできません。 プロンプトが表示され、増分リカバリを続行することをお薦めします。

• 次の場合

  • 増分リカバリはできません

  • クローンはサポートされていないか、無効です

  インスタンスをクラスタに追加できず、およびエラー: ターゲットインスタンスをターゲットクラスタに追加する前に、クローニングするか完全にプロビジョニングする必要があります。 Cluster.addInstance: インスタンスプロビジョニングが必要です (RuntimeError) が示されます。 これは、バイナリログがすべてのクラスタインスタンスからパージされた結果である可能性があります。 クラスタをアップグレードするか、disableClone オプションを false に設定して、MySQL クローンを使用することをお薦めします。

• 次の場合

  • 増分リカバリはできません

  • クローンがサポートされています

  MySQL クローンは、インスタンスをクラスタに追加するためにのみ使用できます。 これは、たとえばパージされたときに、クラスタにバイナリログがないことが原因である可能性があります。

プロンプトからオプションを選択すると、デフォルトで、クラスタからトランザクションをリカバリするインスタンスの進行状況が表示されます。 この監視により、リカバリフェーズが機能していること、およびインスタンスがクラスタに参加してオンラインになるまでにかかる時間を確認できます。 リカバリフェーズの監視を取り消すには、CONTROL+C を発行します。

Cluster.checkInstanceState() および MySQL クローン

MySQL クローンを使用しているクラスタに対してインスタンスを検証するために Cluster.checkInstanceState() 操作を実行するときに、インスタンスにバイナリログがない場合 (たとえば、パージされたがクローンが使用可能で無効化されていない (disableClone は false) は、クローンを使用できることを示す警告を表示します。 例:

The cluster transactions cannot be recovered on the instance, however,
Clone is available and can be used when adding it to a cluster.

{
"reason": "all_purged",
"state": "warning"
}

同様に、クローンが使用できないか無効になっており、バイナリログがパージされたなどの理由で使用できないインスタンスでは、出力には次のものが含まれます:

The cluster transactions cannot be recovered on the instance.

{
"reason": "all_purged",
"state": "warning"
}

dba.checkInstanceConfiguration() および MySQL クローン

MySQL クローンは使用可能だが無効になっているインスタンスに対して dba.checkInstanceConfiguration() 操作を実行すると、警告が表示されます。