PDF (US Ltr)
- 1.4Mb
PDF (A4)
- 1.4Mb
このページは機械翻訳したものです。
InnoDB ReplicaSet は、InnoDB クラスタ とほぼ同じ方法で操作します。 たとえば、ReplicaSet へのインスタンスの追加 に表示されているように、ReplicaSet オブジェクトを変数に割り当て、ReplicaSet.addInstance()Cluster.addInstance()ReplicaSet オブジェクトでは、次の操作がサポートされています:
\help ReplicaSetまたはReplicaSet.help()\help dbaまたはdba.help()を使用して、ReplicaSetオブジェクトおよび AdminAPI のオンラインヘルプを取得します。 セクション6.1「MySQL AdminAPI」を参照してください。-
nameまたはReplicaSet.getName()ReplicaSetオブジェクトの名前をすばやく確認できます。 たとえば、次は同等です:mysql-js> rs.name example mysql-js> rs.getName() example -
様々なレベルの詳細を取得する
extendedオプションをサポートするReplicaSet.status()extendedのデフォルトは 0(通常の詳細レベル) です。 デフォルト以外または予期しないレプリケーション設定およびステータスに加えて、インスタンスおよびレプリケーションのステータスに関する基本情報のみが含まれます。extendedを 1 に設定すると、メタデータバージョン、サーバー UUID、ラグやワーカースレッドなどのレプリケーション情報、インスタンスのステータスの導出に使用される RAW 情報、アプライヤキューのサイズ、予期しない書込みから保護するシステム変数の値などが含まれます。extendedを 2 に設定すると、暗号化された接続などの重要なレプリケーション関連の構成設定が含まれます。
ReplicaSet.status(extended=1)Cluster.status(extended=1)replicationフィールドを使用できることです。 フィールドの詳細は、Cluster.status() ReplicaSet.addInstance()ReplicaSet.removeInstance()ReplicaSet.rejoinInstance()ReplicaSet.setPrimaryInstance()ReplicaSet.forcePrimaryInstance()InnoDB クラスタ とまったく同じ方法で、ReplicaSet に対してブートストラップされた MySQL Router インスタンスを操作します。
ReplicaSet.listRouters()ReplicaSet.removeRouterMetadata()-
バージョン 8.0.23 から、InnoDB ReplicaSet はパラレルレプリケーションアプライヤ (マルチスレッドレプリカと呼ばれることもあります) をサポートし、有効にします。 InnoDB ReplicaSet でパラレルレプリケーションアプライヤを使用するには、インスタンスに正しい設定が構成されている必要があります。 以前のバージョンからアップグレードする場合、インスタンスには更新された構成が必要です。 InnoDB ReplicaSet に属するインスタンスごとに、
dba.configureReplicaSetInstance(instance)を発行して構成を更新します。 通常、dba.configureReplicaSetInstance()はレプリカセットにインスタンスを追加する前に使用されますが、この特別なケースでは、インスタンスを削除する必要はなく、構成の変更はオンライン中に行われます。 詳細は、パラレルレプリケーションアプリケーションの構成を参照してください。InnoDB ReplicaSet インスタンスは、
replicationフィールドの下のReplicaSet.status(extended=1)
詳細は、リンクされた InnoDB クラスタ のセクションを参照してください。
次の操作は InnoDB ReplicaSet に固有であり、ReplicaSet オブジェクトに対してのみコールできます:
ReplicaSet.setPrimaryInstance()
プライマリを安全に変更できるようにするには、すべてのレプリカセットインスタンスが MySQL Shell から到達可能であり、一貫性のある GTID_EXECUTED セットを持つ必要があります。 プライマリが使用できず、リストアする方法がない場合は、かわりに強制フェイルオーバーが唯一のオプションである可能性があります。ReplicaSet でのプライマリインスタンスの強制 を参照してください。
プライマリの変更中、昇格されたインスタンスは古いプライマリと同期され、トポロジの変更がコミットされる前にプライマリに存在するすべてのトランザクションが適用されます。 この同期化ステップに時間がかかりすぎるか、セカンダリインスタンスで実行できない場合、操作は中断されます。 このような状況でフェイルオーバーを可能にするには、これらの問題のあるセカンダリインスタンスを修復するか、ReplicaSet から削除する必要があります。
プライマリで予期しない障害が発生した場合に自動フェイルオーバーをサポートする InnoDB クラスタ とは異なり、InnoDB ReplicaSet には、グループレプリケーションによって提供されるプロトコルなどの自動障害検出またはコンセンサスベースのプロトコルはありません。 プライマリが使用できない場合は、手動フェイルオーバーが必要です。 プライマリを失った InnoDB ReplicaSet は事実上読取り専用であり、書込みの変更を可能にするには、新しいプライマリを選択する必要があります。 プライマリに接続できず、ReplicaSet プライマリの計画済変更 で説明されているように ReplicaSet.setPrimaryInstance()ReplicaSet.forcePrimaryInstance()
警告
強制フェイルオーバーは潜在的に破壊的なアクションであり、注意して使用する必要があります。
ターゲットインスタンスが指定されていない (または null である) 場合、最新のインスタンスが自動的に選択され、新しいプライマリに昇格されます。 ターゲットインスタンスが指定されている場合はプライマリに昇格され、他の到達可能なセカンダリインスタンスは新しいプライマリからレプリケートするように切り替えられます。 ターゲットインスタンスは、到達可能なインスタンス間で最新の GTID_EXECUTED セットを持っている必要があります。そうでない場合、操作は失敗します。
フェイルオーバーは、古いプライマリとの同期や更新を行わずにセカンダリインスタンスを昇格するため、計画されたプライマリ変更とは異なります。 これには次のような大きな影響があります:
古いプライマリで障害が発生した時点でセカンダリによってまだ適用されていないトランザクションは失われます。
古いプライマリがまだ実行中でトランザクションを処理している場合は、スプリットブレインが存在し、古いプライマリと新しいプライマリのデータセットが相違します。
最新の既知のプライマリがまだ到達可能な場合、ReplicaSet.forcePrimaryInstance()
強制フェイルオーバーの後、古いプライマリは新しいプライマリによって無効とみなされ、レプリカセットに含めることはできなくなります。 後でインスタンスをリカバリする方法が見つかった場合は、ReplicaSet から削除し、新しいインスタンスとして再追加する必要があります。 フェイルオーバー中に新しいプライマリに切り替えることができなかったセカンダリインスタンスがあった場合は、それらも無効とみなされます。
フェイルオーバー後にデータが失われる可能性があります。これは、古いプライマリに、昇格されるセカンダリにまだレプリケートされていないトランザクションがある可能性があるためです。 さらに、障害が発生したとみなされたインスタンスがまだトランザクションを処理できる場合、たとえば、そのインスタンスが配置されているネットワークはまだ機能していますが、MySQL Shell からアクセスできないため、昇格されたインスタンスとの相違は続行されます。 インスタンスでのトランザクションセットの相違後のリカバリには手動操作が必要であり、障害が発生したインスタンスをリカバリできる場合でも状況によっては実行できなかった可能性があります。 多くの場合、強制フェイルオーバーが必要な障害からリカバリする最も高速で簡単な方法は、このような相違されたトランザクションを破棄し、新しく昇格されたプライマリから新しいインスタンスを再プロビジョニングすることです。
バージョン 8.0.20 から、AdminAPI はロックメカニズムを使用して、InnoDB ReplicaSet で様々な操作が同時に変更を実行しないようにしています。 以前は、MySQL Shell の異なるインスタンスが同時に InnoDB ReplicaSet に接続し、AdminAPI 操作を同時に実行できました。 これにより、ReplicaSet.addInstance()ReplicaSet.setPrimaryInstance()
InnoDB ReplicaSet 操作には、次のロックがあります:
dba.upgradeMetadata()およびdba.createReplicaSet()は、グローバルに排他的な操作です。 これは、MySQL Shell が InnoDB ReplicaSet でこれらの操作を実行する場合、InnoDB ReplicaSet またはそのインスタンスに対して他の操作を実行できないことを意味します。ReplicaSet.forcePrimaryInstance()ReplicaSet.setPrimaryInstance()ReplicaSet.addInstance(),ReplicaSet.rejoinInstance()ReplicaSet.removeInstance()dba.getReplicaSet()およびReplicaSet.status()
実際には、同時に実行できない別の操作の実行中に InnoDB ReplicaSet 関連の操作を実行しようとすると、必要なリソースのロックの取得に失敗したことを示すエラーが表示されます。 この場合、ロックを保持する実行中の操作が完了するまで待機してから、次の操作の実行を試行する必要があります。 例:
mysql-js> rs.addInstance("admin@rs2:3306");
ERROR: The operation cannot be executed because it failed to acquire the lock on
instance 'rs1:3306'. Another operation requiring exclusive access to the
instance is still in progress, please wait for it to finish and try again.
ReplicaSet.addInstance: Failed to acquire lock on instance 'rs1:3306' (MYSQLSH
51400)
この例では、ReplicaSet.setPrimaryInstance()rs1:3306) のロックを取得できなかったため、ReplicaSet.addInstance()
タグ付けは、ReplicaSets とそのインスタンスでサポートされます。 タグ付けのために、ReplicaSets は setOption()、setInstanceOption() および options() 操作をサポートしています。 これらの操作は、通常、Cluster と同等の方法で機能します。 詳細は、セクション6.2.9「メタデータのタグ付け」を参照してください。 このセクションでは、ReplicaSets のタグの使用における相違点について説明します。
重要
ReplicaSets およびそのインスタンス用に構成できる他のオプションはありません。 ReplicaSets では、InnoDB クラスタ のオプションの設定 に記載されているオプションはサポートされていません。 サポートされているオプションは、ここで説明するタグ付けのみです。
ReplicaSet.options()
ReplicaSet.setOption()ReplicaSet.setInstanceOption()option 引数では、tag ネームスペースのオプションのみがサポートされ、それ以外の場合はエラーがスローされます。
ReplicaSet.setInstanceOption(instance, option, value)ReplicaSet.setOption(option, value)Cluster の同等の操作と同じように動作します。
ルーティングからのインスタンスの削除 で説明されているように、インスタンスの非表示に違いはありません。 たとえば、ReplicaSet インスタンス rs-1 を非表示にするには、次のコマンドを発行します:
mysql-js> myReplicaSet.setInstanceOption(icadmin@rs-1:3306, "tag:_hidden", true);
ReplicaSet に対してブートストラップされた MySQL Router は、変更を検出し、rs-1 インスタンスをルーティング先から削除します。