Documentation Home
MySQL Shell 8.0
Download this Manual
PDF (US Ltr) - 1.4Mb
PDF (A4) - 1.4Mb
MySQL Shell 8.0  /  ...  /  InnoDB クラスタ の構成

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

6.2.6 InnoDB クラスタ の構成

このセクションでは、AdminAPI を使用して InnoDB クラスタ を構成する方法について説明します。

InnoDB クラスタ のオプションの設定

インスタンスがオンラインのときに、InnoDB クラスタ の設定を確認および変更できます。 クラスタの現在の設定を確認するには、次の操作を使用します:

  • Cluster.options():クラスタとそのインスタンスの構成オプションをリストします。 ブールオプション all を指定して、すべての Group Replication システム変数に関する情報を出力に含めることもできます。

InnoDB クラスタ のオプションは、インスタンスをオンラインのまま、クラスタレベルまたはインスタンスレベルで構成できます。 これにより、InnoDB クラスタ オプションを変更するために、インスタンスを削除して再構成し、再度追加する必要がなくなります。 次の操作を使用します:

  • Cluster.setOption(option, value):すべてのクラスタインスタンスの設定をグローバルに変更するか、clusterName などのクラスタグローバル設定を変更します。

  • 個々のクラスタインスタンスの設定を変更する Cluster.setInstanceOption(instance, option, value)

リストされている操作で InnoDB クラスタ オプションを使用する方法は、オプションをすべてのインスタンスで同じになるように変更できるかどうかによって異なります。 これらのオプションは、クラスタレベル (すべてのインスタンス) とインスタンスレベルの両方で変更できます:

これらのオプションは、クラスタレベルでのみ変更できます:

  • clusterName: クラスタ名を定義する文字列値

  • disableClone: クラスタでクローンの使用を無効にするために使用されるブール値。 dba.createCluster() および MySQL クローンを参照してください。

  • expelTimeout: クラスタから削除する前に、クラスタメンバーが応答しないメンバーを待機する期間 (秒) を定義する整数値。 クラスタの作成を参照してください。

  • failoverConsistency: クラスタが提供する一貫性保証を示す文字列値。 インスタンスの自動再結合の構成を参照してください。

このオプションは、インスタンスごとのレベルでのみ変更できます:

  • label: インスタンスの文字列識別子

InnoDB クラスタs のカスタマイズ

クラスタを作成してインスタンスを追加すると、グループ名、ローカルアドレス、シードインスタンスなどの値が AdminAPI によって自動的に構成されます。 これらのデフォルト値はほとんどのデプロイメントで推奨されますが、上級ユーザーは次のオプションを dba.createCluster() および Cluster.addInstance() に渡すことでデフォルトをオーバーライドできます。

InnoDB クラスタ によって作成されたレプリケーショングループの名前をカスタマイズするには、dba.createCluster() コマンドに groupName オプションを渡します。 これにより、group_replication_group_name システム変数が設定されます。 名前は有効な UUID である必要があります。

インスタンスが他のインスタンスからの接続用に提供するアドレスをカスタマイズするには、localAddress オプションを dba.createCluster() および cluster.addInstance() コマンドに渡します。 host:port の形式でアドレスを指定します。 これにより、インスタンスに group_replication_local_address システム変数が設定されます。 アドレスは、クラスタ内のすべてのインスタンスからアクセス可能であり、内部クラスタ通信専用に予約されている必要があります。 つまり、インスタンスとの通信にこのアドレスを使用しないでください。

インスタンスがクラスタに参加するときにシードとして使用されるインスタンスをカスタマイズするには、groupSeeds オプションを dba.createCluster() および Cluster.addInstance() 操作に渡します。 シードインスタンスは、新しいインスタンスがクラスタに参加したときに接続され、新しいインスタンスにデータを提供するために使用されます。 シードインスタンスのアドレスは、host1:port1、host2:port2 などのカンマ区切りリストとして指定されます。 これにより、group_replication_group_seeds システム変数が構成されます。 新しいインスタンスがクラスタに追加されると、必要に応じて新しいインスタンスを使用してグループに再度参加できるように、このインスタンスのローカルアドレスがすべてのオンラインクラスタメンバーのグループシードのリストに自動的に追加されます。

注記

シードリスト内のインスタンスは、リストに表示される順序に従って使用されます。 つまり、ユーザー指定のシードが最初に使用され、自動的に追加されたインスタンスよりも優先されます。

詳細は、これらの AdminAPI オプションで構成されるシステム変数のドキュメントを参照してください。

選任プロセスの設定

オプションで、単一プライマリクラスタが新しいプライマリを選択する方法を構成できます。たとえば、あるインスタンスをフェイルオーバー先の新しいプライマリとして優先できます。 memberWeight オプションを使用して、クラスタの作成時に dba.createCluster() および Cluster.addInstance() メソッドに渡します。 memberWeight オプションは、フェイルオーバー時の自動プライマリ選択のパーセンテージ加重である 0 から 100 までの整数値を受け入れます。 インスタンスに memberWeight によって設定されたより大きい事前番号がある場合、単一プライマリクラスタでプライマリとして選択される可能性が高くなります。 プライマリ選択が行われると、複数のインスタンスが同じ memberWeight 値を持つ場合、インスタンスは辞書順 (最低) でサーバー UUID に基づいて優先順位が付けられ、最初のインスタンスが選択されます。

memberWeight の値を設定すると、インスタンスの group_replication_member_weight システム変数が構成されます。 グループレプリケーションでは、値の範囲が 0 から 100 に制限され、高い値または低い値が指定された場合は自動的に調整されます。 値が指定されていない場合、グループレプリケーションではデフォルト値の 50 が使用されます。 詳しくはシングルプライマリモードをご覧ください。

たとえば、現在のプライマリである ic-1 が予期せず memberWeight を使用する場合に、ic-3 がフェイルオーバー先の優先インスタンスであるクラスタを構成するには、次のようにします: 

dba.createCluster('cluster1', {memberWeight:35})
var mycluster = dba.getCluster()
mycluster.addInstance('icadmin@ic2', {memberWeight:25})
mycluster.addInstance('icadmin@ic3', {memberWeight:50})

フェイルオーバーの一貫性の構成

グループレプリケーションでは、プライマリフェイルオーバーが単一プライマリモードで発生した場合にフェイルオーバー保証 (最終的または「「書き込みを読む」」) を指定できます (トランザクション一貫性保証の構成 を参照)。 作成時に InnoDB クラスタ のフェイルオーバー保証を構成するには、consistency オプション (バージョン 8.0.16 より前のこのオプションは failoverConsistency オプションで、現在は非推奨) を dba.createCluster() 操作に渡して、シードインスタンスで group_replication_consistency システム変数を構成します。 このオプションは、単一プライマリグループで新しいプライマリが選択されたときに使用される新しいフェンシングメカニズムの動作を定義します。 フェンシングは、古いプライマリ (「「書き込みを読む」」とも呼ばれる) からの保留中の変更のバックログが適用されるまで、新しいプライマリからの接続の書込みおよび読取りを制限します。 フェンシングメカニズムが設定されている間は、バックログが適用されている間、アプリケーションは短時間前に進む時間を事実上認識しません。 これにより、アプリケーションは新しく選択されたプライマリから失効した情報を読み取らないようになります。

consistency オプションは、ターゲット MySQL サーバーのバージョンが 8.0.14 以上で、consistency オプションで構成されたクラスタに追加されたインスタンスが、そのオプションをサポートするすべてのクラスタメンバーで group_replication_consistency が同じになるように自動的に構成されている場合にのみサポートされます。 変数のデフォルト値は Group Replication によって制御され、EVENTUAL の場合は、consistency オプションを BEFORE_ON_PRIMARY_FAILOVER に変更してフェンシングメカニズムを有効にします。 または、consistency=0 for EVENTUAL および consistency=1 for BEFORE_ON_PRIMARY_FAILOVER を使用します。

注記

マルチプライマリ InnoDB クラスタ で consistency オプションを使用しても効果はありませんが、後でクラスタをシングルプライマリモードに変更できるため、Cluster.switchToSinglePrimaryMode() 操作を使用できます。

インスタンスの自動再結合の構成

MySQL 8.0.16 以降を実行しているインスタンスでは、グループレプリケーションの自動再結合機能がサポートされているため、明示的にクラスタに自動的に再参加するようにインスタンスを構成できます。 背景情報は、障害検出およびネットワークパーティション化へのレスポンス を参照してください。AdminAPI には、削除後にインスタンスがクラスタへの再参加を試行する回数を構成する autoRejoinTries オプションが用意されています。 デフォルトでは、インスタンスはクラスタに自動的に再参加しません。 次のコマンドを使用して、クラスタレベルまたは個々のインスタンスのいずれかで autoRejoinTries オプションを構成できます:

  • dba.createCluster()

  • Cluster.addInstance()

  • Cluster.setOption()

  • Cluster.setInstanceOption()

autoRejoinTries オプションは、0 から 2016 までの正の整数値を受け入れ、デフォルト値は 0 です。つまり、インスタンスは自動的に再結合を試みません。 自動再結合機能を使用している場合、クラスタは障害、特に信頼できないネットワークなどの一時的な障害に対してより許容範囲が高くなります。 ただし、クォーラムが失われた場合は、インスタンスを再結合するために大部分が必要になるため、メンバーがクラスタに自動的に再参加しないようにする必要があります。

MySQL バージョン 8.0.12 以降を実行しているインスタンスには、AdminAPI exitStateAction オプションを使用して構成できる group_replication_exit_state_action 変数があります。 これは、クラスタを予期せず終了した場合のインスタンスの動作を制御します。 デフォルトでは、exitStateAction オプションは READ_ONLY,です。つまり、クラスタを予期せず終了したインスタンスは読取り専用になります。 exitStateAction が OFFLINE_MODE (MySQL 8.0.18 から使用可能) に設定されている場合、クラスタを予期せずに残すインスタンスは読取り専用になり、オフラインモードになります。このモードでは、既存のクライアントが切断され、新しい接続は受け入れられません (管理者権限を持つクライアントを除く)。 exitStateAction が ABORT_SERVER に設定されている場合、クラスタを予期せず終了すると、インスタンスは MySQL を停止し、クラスタに再参加する前に再起動する必要があります。 自動再結合機能を使用している場合、exitStateAction オプションで構成されたアクションは、すべての再結合試行がクラスタに失敗した場合にのみ発生することに注意してください。

インスタンスに接続し、AdminAPI を使用して構成しようとする可能性がありますが、その時点でインスタンスがクラスタに再参加している可能性があります。 これは、次のいずれかの操作を使用するたびに発生する可能性があります:

  • Cluster.status()

  • dba.getCluster()

  • Cluster.rejoinInstance()

  • Cluster.addInstance()

  • Cluster.removeInstance()

  • Cluster.rescan()

  • Cluster.checkInstanceState()

これらの操作では、インスタンスがクラスタに自動的に再参加している間に、追加情報が提供される場合があります。 また、Cluster.removeInstance() を使用している場合、ターゲットインスタンスがクラスタに自動的に再参加すると、force:true を渡さないかぎり操作は中断されます。

パラレルレプリケーションアプリケーションの構成

バージョンから、8.0.23 インスタンスはパラレルレプリケーションアプリケーションスレッド (マルチスレッドレプリカと呼ばれることもあります) をサポートし、有効にします。 複数のレプリカアプライアンススレッドをパラレルに使用すると、レプリケーションアプライアンスと増分リカバリの両方のスループットが向上します。

つまり、8.0.23 以降を実行しているインスタンスでは、次のシステム変数を構成する必要があります:

  • binlog_transaction_dependency_tracking=WRITESET

  • slave_preserve_commit_order=ON

  • slave_parallel_type=LOGICAL_CLOCK

  • transaction_write_set_extraction=XXHASH64

デフォルトでは、適用者スレッドの数 (slave_parallel_workers システム変数で構成) は 4 に設定されています。

8.0.23 より前のバージョンの MySQL サーバーおよび MySQL Shell を実行しているクラスタをアップグレードする場合、インスタンスはパラレルレプリケーションアプライヤを使用するように構成されません。 パラレルアプライヤが有効になっていない場合、Cluster.status() 操作の出力では、次のようなメッセージが instanceErrors フィールドに表示されます: 

...
"instanceErrors": [
	"NOTE: The required parallel-appliers settings are not enabled on 
		the instance. Use dba.configureInstance() to fix it."
...

この場合、パラレルレプリケーションアプライヤを使用するようにインスタンスを再構成する必要があります。 InnoDB クラスタ に属するインスタンスごとに、dba.configureInstance(instance) を発行して構成を更新します。 通常、dba.configureInstance() はインスタンスをクラスタに追加する前に使用されますが、この特別なケースでは、インスタンスを削除する必要はなく、構成の変更はオンライン中に行われます。

パラレルレプリケーションアプライヤに関する情報は、Cluster.status(extended=1) 操作の出力に表示されます。 たとえば、パラレルレプリケーションアプライヤが有効な場合、インスタンスの topology セクションの出力には、applierWorkerThreads の下のスレッド数が表示されます。 パラレルレプリケーションアプライヤ用に構成されたシステム変数は、Cluster.options() 操作の出力に表示されます。

インスタンスがパラレルレプリケーションアプライヤに使用するスレッドの数は、applierWorkerThreads オプションを使用して構成できます (デフォルトは 4 スレッドです)。 このオプションは、0 から 1024 の範囲の整数を受け入れ、dba.configureInstance() および dba.configureReplicaSetInstance() 操作でのみ使用できます。 たとえば、8 つのスレッドを使用するには、次のコマンドを発行します: 

mysql-js> dba.configureInstance(instance, {applierWorkerThreads: 8, restart: true})
注記

パラレルレプリケーションアプライヤで使用されるスレッド数の変更は、インスタンスが再起動されてクラスタに再結合された後にのみ発生します。

パラレルレプリケーションアプライヤを無効にするには、applierWorkerThreads オプションを 0 に設定します。

クラスタの保護

セキュアな接続を使用するようにサーバーインスタンスを構成できます。 MySQL でのセキュアな接続の使用に関する一般情報は、暗号化された接続の使用 を参照してください。 このセクションでは、暗号化された接続を使用するようにクラスタを構成する方法について説明します。 追加のセキュリティ可能性は、クラスタにアクセスできるサーバーを構成することです。サーバーの許可リストの作成 を参照してください。

重要

暗号化された接続を使用するようにクラスタを構成したら、サーバーを ipAllowlist に追加する必要があります。

dba.createCluster() を使用してクラスタを設定する場合、サーバーインスタンスが暗号化を提供すると、シードインスタンスで自動的に有効になります。 memberSslMode オプションを dba.createCluster() メソッドに渡して、別の SSL モードを指定します。 クラスタの SSL モードは、作成時にのみ設定できます。 memberSslMode オプションは、使用する SSL モードを構成する文字列で、デフォルトは AUTO です。 許可される値は、DISABLED、REQUIRED および AUTO です。 これらのモードは次のように定義されます:

  • createCluster({memberSslMode:'DISABLED'}) を設定すると、クラスタ内のシードインスタンスで SSL 暗号化が無効になります。

  • createCluster({memberSslMode:'REQUIRED'}) を設定すると、クラスタ内のシードインスタンスに対して SSL 暗号化が有効になります。 有効にできない場合は、エラーが発生します。

  • createCluster({memberSslMode:'AUTO'}) (デフォルト) を設定すると、SSL 暗号化は、サーバーインスタンスでサポートされている場合は自動的に有効になり、サーバーでサポートされていない場合は無効になります。

注記

商用バージョンの MySQL を使用する場合、SSL はデフォルトで有効になっており、すべてのインスタンスに対して許可リストを構成する必要がある場合があります。 サーバーの許可リストの作成を参照してください。

cluster.addInstance() および cluster.rejoinInstance() コマンドを発行すると、シードインスタンスに検出された設定に基づいて、インスタンスの SSL 暗号化が有効または無効になります。

adoptFromGR オプションを指定して createCluster() を使用して既存のグループレプリケーショングループを採用する場合、採用されたクラスタで SSL 設定は変更されません:

  • memberSslMode は、adoptFromGR では使用できません。

  • 採用されたクラスタの SSL 設定が MySQL Shell でサポートされている設定と異なる場合 (つまり、グループレプリケーションリカバリおよびグループ通信の SSL )、両方の設定は変更されません。 つまり、採用されたクラスタの設定を手動で変更しないかぎり、新しいインスタンスをクラスタに追加できません。

MySQL Shell は、グループレプリケーションリカバリとグループ通信の両方でクラスタの SSL を常に有効または無効にします。Secure Socket Layer (SSL) を使用したグループ通信接続の保護 を参照してください。 検証が実行され、新しいインスタンスをクラスタに追加するときにシードインスタンスの設定が異なる場合 (たとえば、adoptFromGR を使用した dba.createCluster() の結果として)、エラーが発行されます。 クラスタ内のすべてのインスタンスで SSL 暗号化を有効または無効にする必要があります。 新しいインスタンスをクラスタに追加するときに、この不変条件が確実に保持されるように検証が実行されます。

dba.deploySandboxInstance() コマンドは、デフォルトで SSL 暗号化サポートを使用してサンドボックスインスタンスのデプロイを試行します。 不可能な場合、サーバーインスタンスは SSL サポートなしでデプロイされます。 ignoreSslError オプションを false に設定すると、サンドボックスインスタンスが SSL サポートとともにデプロイされ、SSL サポートを提供できない場合はエラーが発行されます。 ignoreSslError が true(デフォルト) の場合、SSL サポートを提供できず、サーバーインスタンスが SSL サポートなしでデプロイされていると、操作中にエラーは発行されません。

サーバーの許可リストの作成

クラスタの createCluster()、addInstance() および rejoinInstance() メソッドを使用する場合、オプションで、許可リストと呼ばれる、クラスタに属する承認済サーバーのリストを指定できます。 許可リストをこの方法で明示的に指定することで、許可リスト内のサーバーのみがクラスタに接続できるため、クラスタのセキュリティを向上させることができます。 ipAllowlist オプション (以前の ipWhitelist、現在は非推奨) を使用して、インスタンスに group_replication_ip_allowlist システム変数を構成します。 デフォルトでは、明示的に指定しない場合、allowlist は、サーバーがネットワークインタフェースを持つプライベートネットワークアドレスに自動的に設定されます。 allowlist を構成するには、メソッドの使用時に ipAllowlist オプションを使用して追加するサーバーを指定します。 IP アドレスは IPv4 形式で指定する必要があります。 サーバーを引用符で囲んだカンマ区切りリストとして渡します。 例: 

mysql-js> cluster.addInstance("icadmin@ic-3:3306", {ipAllowlist: "203.0.113.0/24, 198.51.100.110"})

これにより、アドレス 203.0.113.0/24 および 198.51.100.110 のサーバーからの接続のみを受け入れるようにインスタンスが構成されます。 allowlist には、別のサーバーによって接続リクエストが行われた場合にのみ解決されるホスト名を含めることもできます。

警告

ホスト名は本質的に許可リストの IP アドレスより安全性が低くなります。 MySQL は、適切なレベルの保護を提供する FCrDNS 検証を実行しますが、特定のタイプの攻撃によって危険にさらされる可能性があります。 厳密に必要な場合にのみ許可リストにホスト名を指定し、名前解決に使用されるすべてのコンポーネント (DNS サーバーなど) が制御下に保持されていることを確認します。 外部コンポーネントを使用しないように、hosts ファイルを使用して名前解決をローカルに実装することもできます。


PREV   HOME   UP   NEXT
Download this Manual
PDF (US Ltr) - 1.4Mb
PDF (A4) - 1.4Mb