MySQL :: MySQL Shell 8.0 :: 6.2.2.1 新しい本番 InnoDB クラスタのデプロイ

MySQL Shell 8.0 / ... / 新しい本番 InnoDB クラスタのデプロイ

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

6.2.2.1 新しい本番 InnoDB クラスタのデプロイ

次の各セクションでは、新しい本番 InnoDB クラスタをデプロイする方法について説明します。

本番インスタンスの構成

AdminAPI には、インスタンスが InnoDB クラスタ使用のために適切に構成されているかどうかをチェックし、InnoDB クラスタと互換性のない設定が見つかった場合にインスタンスを構成する dba.configureInstance() 関数が用意されています。インスタンスに対して dba.configureInstance() コマンドを実行すると、インスタンスを InnoDB クラスタの使用に使用できるようにするために必要なすべての設定がチェックされます。インスタンスで構成の変更が不要な場合は、インスタンスの構成を変更する必要はなく、dba.configureInstance() コマンド出力によって、インスタンスで InnoDB クラスタを使用する準備ができていることが確認されます。インスタンスを InnoDB クラスタと互換性を持たせるために変更が必要な場合は、互換性のない設定のレポートが表示され、コマンドでインスタンスオプションファイルを変更できます。 MySQL Shell のインスタンスへの接続方法およびインスタンスで実行されている MySQL のバージョンに応じて、これらの変更をリモートインスタンスオプションファイルに永続化することで永続化できます。設定の永続化を参照してください。構成変更の永続化をサポートしていないインスタンスでは、インスタンスをローカルに構成する必要があります。dba.configureLocalInstance() でのインスタンスの構成を参照してください。または、インスタンスオプションファイルを手動で変更することもできます。詳細は、オプションファイルの使用を参照してください。構成の変更方法に関係なく、構成の変更が検出されるように、MySQL の再起動が必要になる場合があります。

dba.configureInstance() コマンドの構文は次のとおりです:

dba.configureInstance([instance][, options])

ここで、instance はインスタンス定義で、options は操作を構成するための追加オプションを含むデータディクショナリです。このコマンドは、操作結果に関する説明テキストメッセージを返します。

instance 定義はインスタンスの接続データです。URI 類似文字列またはキーと値のペアを使用したサーバーへの接続を参照してください。ターゲットインスタンスがすでに InnoDB クラスタに属している場合、エラーが生成され、プロセスは失敗します。

オプションディクショナリには次のものを含めることができます:

mycnfPath - インスタンスの MySQL オプションファイルのパス。
outputMycnfPath - インスタンスの MySQL オプションファイルを書き込む代替出力パス。
password - 接続で使用されるパスワード。
clusterAdmin - 作成する InnoDB クラスタ管理者ユーザーの名前。サポートされているフォーマットは、標準の MySQL アカウント名フォーマットです。ユーザー名およびホスト名の識別子または文字列をサポートします。デフォルトでは、引用符で囲まれていない場合、入力は文字列であるとみなされます。管理用のユーザーアカウントの作成を参照してください。
clusterAdminPassword - clusterAdmin を使用して作成される InnoDB クラスタ管理者アカウントのパスワード。このオプションを使用して指定できますが、これは潜在的なセキュリティリスクです。このオプションを指定せずに clusterAdmin オプションを指定すると、対話型プロンプトでパスワードの入力を求められます。
非推奨であり、将来のバージョンでの削除がスケジュールされています

clearReadOnly - super_read_only をオフに設定する必要があることを確認するために使用されるブール値。スーパー読取り専用およびインスタンスを参照してください。
interactive - ユーザーにプロンプトが表示されず、確認プロンプトが表示されないように、コマンド実行で対話型ウィザードを無効にするために使用されるブール値。
restart - 操作を終了するためにターゲットインスタンスのリモート再起動を実行する必要があることを示すブール値。

接続パスワードはインスタンス定義に含めることができますが、これはセキュアではないためお薦めしません。 MySQL Shell セクション4.4「プラガブルパスワードストア」を使用して、インスタンスパスワードを安全に格納します。

インスタンスに対して dba.configureInstance() が発行されると、このコマンドはインスタンス設定が InnoDB クラスタの使用に適しているかどうかをチェックします。 InnoDB クラスタで必要な設定を示すレポートが表示されます。インスタンスの設定を変更する必要がない場合は、InnoDB クラスタで使用でき、クラスタの作成に進むことができます。インスタンス設定が InnoDB クラスタの使用に対して有効でない場合、dba.configureInstance() コマンドは変更が必要な設定を表示します。インスタンスを構成する前に、次の情報を含むテーブルに示されている変更を確認するよう求められます:

Variable - 無効な構成変数。
Current Value - 無効な構成変数の現在の値。
Required Value - 構成変数に必要な値。

続行方法は、インスタンスが永続化設定をサポートしているかどうかによって異なります。設定の永続化を参照してください。 MySQL Shell が現在実行されている MySQL インスタンス (つまり、ローカルインスタンス) に対して dba.configureInstance() を発行すると、インスタンスの自動構成が試行されます。リモートインスタンスに対して dba.configureInstance() が発行されたときに、インスタンスが構成変更の永続化を自動的にサポートしている場合は、これを選択できます。リモートインスタンスが、InnoDB クラスタで使用できるように構成するための変更の永続化をサポートしていない場合は、インスタンスをローカルに構成する必要があります。 dba.configureLocalInstance() でのインスタンスの構成を参照してください。

一般に、dba.configureInstance() でオプションファイルを構成した後にインスタンスを再起動する必要はありませんが、特定の設定によっては再起動が必要になる場合があります。この情報は、dba.configureInstance() の発行後に生成されるレポートに表示されます。インスタンスが RESTART ステートメントをサポートしている場合、MySQL Shell はインスタンスを停止してから起動できます。これにより、インスタンスオプションファイルに加えられた変更が mysqld によって確実に検出されます。詳細は、RESTART を参照してください。

注記

RESTART ステートメントを実行すると、インスタンスへの現在の接続が失われます。自動再接続が有効な場合、サーバーの再起動後に接続が再確立されます。それ以外の場合は、接続を手動で再確立する必要があります。

dba.configureInstance() メソッドは、クラスタのメンバー間の接続に使用される適切なユーザーがクラスタの使用に使用できることを検証します。管理用のユーザーアカウントの作成を参照してください。

クラスタを管理するユーザーを指定しない場合は、対話型モードでウィザードを使用して次のいずれかのオプションを選択できます:

root ユーザーのリモート接続を有効にします。本番環境ではお薦めしません
新規ユーザーの作成
ユーザーを手動で作成する必要がある自動構成はありません

ヒント

インスタンスに super_read_only=ON がある場合は、AdminAPI で super_read_only=OFF を設定できることを確認する必要がある場合があります。詳しくはスーパー読取り専用およびインスタンスをご覧ください。

クラスタの作成

インスタンスを準備したら、MySQL Shell が接続されているインスタンスをクラスタのシードインスタンスとして使用して、dba.createCluster() 関数を使用してクラスタを作成します。シードインスタンスは、クラスタに追加した他のインスタンスにレプリケートされ、シードインスタンスのレプリカになります。この手順では、ic-1 インスタンスがシードとして使用されます。 dba.createCluster(name) MySQL Shell を発行すると、MySQL Shell の現在のグローバルセッションに接続されているサーバーインスタンスへのクラシック MySQL プロトコルセッションが作成されます。たとえば、testCluster というクラスタを作成し、返されたクラスタを cluster という変数に割り当てるには、次のようにします:

mysql-js> var cluster = dba.createCluster('testCluster')
Validating instance at icadmin@ic-1:3306...
This instance reports its own address as ic-1
Instance configuration is suitable.
Creating InnoDB cluster 'testCluster' on 'icadmin@ic-1:3306'...
Adding Seed Instance...
Cluster successfully created. Use Cluster.addInstance() to add MySQL instances.
At least 3 instances are needed for the cluster to be able to withstand up to
one server failure.

返されたクラスタを変数に割り当てるこのパターンを使用すると、Cluster オブジェクトメソッドを使用してクラスタに対してさらに操作を実行できます。返された Cluster オブジェクトは、MySQL Shell グローバルセッションから独立した新しいセッションを使用します。これにより、MySQL Shell グローバルセッションを変更した場合、Cluster オブジェクトはインスタンスへのセッションを維持します。

クラスタを管理できるようにするには、必要な権限を持つ適切なユーザーがいることを確認する必要があります。推奨される方法は、管理ユーザーを作成することです。インスタンスの構成時に管理ユーザーを作成しなかった場合は、Cluster.setupAdminAccount() 操作を使用します。たとえば、変数 cluster に割り当てられた InnoDB クラスタを管理できる icadmin という名前のユーザーを作成するには、次のように発行します:

mysql-js> cluster.setupAdminAccount(icadmin)

クラスタ管理ユーザーの詳細は、AdminAPI のユーザーの構成を参照してください。

dba.createCluster() 操作では、MySQL Shellinteractive オプションがサポートされます。 interactive がオンの場合、プロンプトは次の状況で表示されます:

クラスタに属するインスタンスで実行され、adoptFromGr オプションが false の場合、既存のクラスタを採用するかどうかを尋ねられます
force オプションが使用されていない (true に設定されていない) 場合、マルチプライマリクラスタの作成を確認するよう求められます

注記

メタデータにアクセスできないというエラーが発生した場合は、ループバックネットワークインタフェースが構成されている可能性があります。 InnoDB クラスタを正しく使用するには、ループバックインタフェースを無効にします。

クラスタが作成されたことを確認するには、クラスタインスタンスの status() 関数を使用します。 Cluster.status() によるクラスタステータスの確認を参照してください。

ヒント

サーバーインスタンスがクラスタに属したら、MySQL Shell および AdminAPI を使用してのみ管理することが重要です。クラスタに追加されたインスタンスでのグループレプリケーションの構成の手動変更の試行はサポートされていません。同様に、AdminAPI を使用してインスタンスを構成した後の、server_uuid などの InnoDB クラスタに重要なサーバー変数の変更はサポートされていません。

MySQL Shell 8.0.14 以降を使用してクラスタを作成する場合、インスタンスにアクセスできなくなった場合など、インスタンスがクラスタから削除される前にタイムアウトを設定できます。シードインスタンスで group_replication_member_expel_timeout 変数を構成する dba.createCluster() 操作に expelTimeout オプションを渡します。 expelTimeout オプションには、0 から 3600 の範囲の整数値を指定できます。 expelTimeout が構成されたクラスタに追加される MySQL サーバー 8.0.13 以降を実行しているすべてのインスタンスは、シードインスタンスで構成されているものと同じ expelTimeout 値を持つように自動的に構成されます。

dba.createCluster() に渡すことができるその他のオプションの詳細は、セクション6.2.5「InnoDB クラスタの操作」を参照してください。

クラスタへのインスタンスの追加

クラスタにインスタンスを追加するには、Cluster.addInstance(instance) 関数を使用します。ここで、instance は構成済インスタンスへの接続情報です。本番インスタンスの構成を参照してください。バージョン 8.0.17 から、Group Replication はインスタンスのパッチバージョンを考慮する互換性ポリシーを実装し、Cluster.addInstance() 操作はこれを検出し、非互換性が発生した場合はエラーで操作を終了します。インスタンスでの MySQL バージョンの確認およびグループ内の異なるメンバーバージョンの組合せを参照

1 つのインスタンスの障害を許容するには、クラスタ内に 3 つ以上のインスタンスが必要です。さらにインスタンスを追加すると、インスタンスの障害に対する許容範囲が増加します。クラスタにインスタンスを追加するには、次のコマンドを発行します:

mysql-js> cluster.addInstance('icadmin@ic-2:3306')
A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.
Please provide the password for 'icadmin@ic-2:3306': ********
Adding instance to the cluster ...
Validating instance at ic-2:3306...
This instance reports its own address as ic-2
Instance configuration is suitable.
The instance 'icadmin@ic-2:3306' was successfully added to the cluster.

新しいインスタンスがクラスタに追加されると、必要に応じて、このインスタンスのローカルアドレスがすべてのオンラインクラスタインスタンスの group_replication_group_seeds 変数に自動的に追加され、新しいインスタンスを使用してグループに再度参加できるようになります。

注記

group_replication_group_seeds にリストされているインスタンスは、リストに表示される順序に従って使用されます。これにより、ユーザー指定の設定が最初に使用され、優先されます。詳しくはInnoDB クラスタs のカスタマイズをご覧ください。

MySQL 8.0.17 以降を使用している場合は、クラスタとの同期に必要なトランザクションをインスタンスがリカバリする方法を選択できます。結合インスタンスが以前にクラスタによって処理されたすべてのトランザクションをリカバリした場合にのみ、オンラインインスタンスとして参加し、トランザクションの処理を開始できます。詳細は、セクション6.2.2.2「InnoDB クラスタでの MySQL クローンの使用」を参照してください。

また、8.0.17 以降では、Cluster.addInstance() の動作を構成して、リカバリ操作をバックグラウンドで続行したり、MySQL Shell で様々なレベルの進行状況を監視できます。

クラスタからインスタンスをリカバリするために選択したオプションに応じて、MySQL Shell に異なる出力が表示されます。インスタンス ic-2 をクラスタに追加し、ic-1 がシードまたはドナーであるとします。

MySQL クローンを使用してクラスタからインスタンスをリカバリする場合、出力は次のようになります:

Validating instance at ic-2:3306...
This instance reports its own address as ic-2:3306
Instance configuration is suitable.
A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.
Adding instance to the cluster...
Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and let it continue in background.
Clone based state recovery is now in progress.
NOTE: A server restart is expected to happen as part of the clone process. If the
server does not support the RESTART command or does not come back after a
while, you may need to manually start it back.
* Waiting for clone to finish...
NOTE: ic-2:3306 is being cloned from ic-1:3306
** Stage DROP DATA: Completed
** Clone Transfer
FILE COPY  ############################################################  100%  Completed
PAGE COPY  ############################################################  100%  Completed
REDO COPY  ############################################################  100%  Completed
NOTE: ic-2:3306 is shutting down...
* Waiting for server restart... ready
* ic-2:3306 has restarted, waiting for clone to finish...
** Stage RESTART: Completed
* Clone process has finished: 2.18 GB transferred in 7 sec (311.26 MB/s)
State recovery already finished for 'ic-2:3306'
The instance 'ic-2:3306' was successfully added to the cluster.

サーバーの再起動に関する警告が表示されます。場合によっては、インスタンスを手動で再起動する必要があります。 RESTART ステートメントを参照してください。

増分リカバリを使用してクラスタからインスタンスをリカバリする場合、出力は次のようになります:

Incremental distributed state recovery is now in progress.
* Waiting for incremental recovery to finish...
NOTE: 'ic-2:3306' is being recovered from 'ic-1:3306'
* Distributed recovery has finished

リカバリフェーズの監視を取り消すには、CONTROL+C を発行します。これにより監視は停止されますが、リカバリプロセスはバックグラウンドで続行されます。 Cluster.addInstance() 操作で waitRecovery 整数オプションを使用して、リカバリフェーズに関するコマンドの動作を制御できます。次の値を使用できます:

0: 待機せず、リカバリプロセスをバックグラウンドで終了させます
1: リカバリプロセスが終了するまで待機
2: リカバリプロセスが終了するまで待機し、詳細な静的進捗情報を表示
3: リカバリプロセスが終了するまで待機し、詳細な動的進捗情報 (進捗バー) を表示

デフォルトでは、MySQL Shell が実行されている標準出力が端末を参照する場合、waitRecovery オプションのデフォルトは 3 です。それ以外の場合は、デフォルトで 2 に設定されます。リカバリ操作の監視を参照してください。

インスタンスが追加されたことを確認するには、クラスタインスタンスの status() 関数を使用します。たとえば、2 番目のインスタンスを追加した後のサンドボックスクラスタのステータス出力は次のとおりです:

mysql-js> cluster.status()
{
    "clusterName": "testCluster",
    "defaultReplicaSet": {
        "name": "default",
        "primary": "ic-1:3306",
        "ssl": "REQUIRED",
        "status": "OK_NO_TOLERANCE",
        "statusText": "Cluster is NOT tolerant to any failures.",
        "topology": {
            "ic-1:3306": {
                "address": "ic-1:3306",
                "mode": "R/W",
                "readReplicas": {},
                "role": "HA",
                "status": "ONLINE"
            },
            "ic-2:3306": {
                "address": "ic-2:3306",
                "mode": "R/O",
                "readReplicas": {},
                "role": "HA",
                "status": "ONLINE"
            }
        }
    },
    "groupInformationSourceMember": "mysql://icadmin@ic-1:3306"
}

続行方法は、インスタンスが MySQL Shell が実行されているインスタンスに対してローカルであるかリモートであるか、およびインスタンスが構成変更の自動永続化をサポートしているかどうかによって異なります。設定の永続化を参照してください。インスタンスで構成変更の永続化が自動的にサポートされている場合、設定を手動で永続化する必要はなく、さらにインスタンスを追加するか、次のステップに進むことができます。インスタンスで構成変更の永続化が自動的にサポートされない場合は、インスタンスをローカルに構成する必要があります。 dba.configureLocalInstance() でのインスタンスの構成を参照してください。これは、クラスタから離れる場合にインスタンスがクラスタに再参加するようにするために不可欠です。

ヒント

クラスタをデプロイしたら、高可用性を提供するように MySQL Router を構成できます。セクション6.4「MySQL Router」を参照してください。

InnoDB クラスタによって作成されたユーザーアカウント

グループレプリケーションの使用の一環として、InnoDB クラスタは、クラスタ内のサーバー間の接続を可能にする内部リカバリユーザーを作成します。これらのユーザーはクラスタの内部にあり、生成されたユーザーのユーザー名は mysql_innodb_cluster_server_id@% のネーミングスキームに従います (server_id はインスタンスに対して一意です)。 8.0.17 より前のバージョンでは、生成されたユーザーのユーザー名は mysql_innodb_cluster_r[10_numbers]のネーミングスキームに従いました。内部ユーザーに使用されるホスト名は、ipAllowlist オプションが構成されているかどうかによって異なります。 ipAllowlist が構成されていない場合、デフォルトで AUTOMATIC に設定され、ホスト名の値にワイルドカードの % 文字と localhost の両方を使用して内部ユーザーが作成されます。 ipAllowlist が構成されている場合、ipAllowlist リスト内のアドレスごとに内部ユーザーが作成されます。詳細は、サーバーの許可リストの作成を参照してください。

各内部ユーザーにはランダムに生成されたパスワードがあります。バージョン 8.0.18 から、AdminAPI を使用して内部ユーザーに対して生成されたパスワードを変更できます。回復アカウントのパスワードのリセットを参照してください。ランダムに生成されたユーザーには、次の権限が付与されます:

GRANT REPLICATION SLAVE ON *.* to internal_user;

内部ユーザーアカウントがシードインスタンスに作成され、クラスタ内の他のインスタンスにレプリケートされます。内部ユーザーは次のとおりです:

dba.createCluster() を発行して新しいクラスタを作成するときに生成されます
Cluster.addInstance() を発行してクラスタに新しいインスタンスを追加するときに生成されます。

また、ipAllowlist オプションを使用してホスト名を指定すると、Cluster.rejoinInstance() 操作によって新しい内部ユーザーが生成されることもあります。たとえば、次のように発行します:

Cluster.rejoinInstance({ipAllowlist: "192.168.1.1/22"});

使用されている ipAllowlist 値を考慮して、既存のすべての内部ユーザーが削除され、新しい内部ユーザーが作成されます。

Group Replication に必要な内部ユーザーの詳細は、分散リカバリのユーザー資格証明を参照してください。

InnoDB クラスタポートの構成

クラスタに属するインスタンスは、異なるタイプの通信に異なるポートを使用します。クラシック MySQL プロトコル経由のクライアント接続に使用される 3306 のデフォルトの port と、デフォルトで 33060 に設定され、X プロトコルクライアント接続に使用される mysqlx_port に加えて、クライアント接続に使用されないクラスタ内のインスタンス間の内部接続用のポートもあります。このポートは、group_replication_local_address システム変数を構成する localAddress オプションによって構成され、クラスタ内のインスタンスが相互に通信できるように、このポートをオープンする必要があります。たとえば、ファイアウォールがこのポートをブロックしている場合、インスタンスは相互に通信できず、クラスタは機能しません。同様に、インスタンスが SELinux を使用している場合は、インスタンスが相互に通信できるように、InnoDB クラスタで使用されるすべての必須ポートが開いていることを確認する必要があります。 MySQL 機能の TCP ポートコンテキストの設定および「MySQL Shell ポートリファレンス」を参照してください。

クラスタを作成するか、クラスタにインスタンスを追加する場合、デフォルトでは、localAddress ポートはターゲットインスタンスの port 値に 10 を乗算して結果に追加することで計算されます。たとえば、ターゲットインスタンスの port がデフォルト値 3306 の場合、計算された localAddress ポートは 33061 です。クラスタインスタンスで使用されるポート番号が、localAddress の計算方法と互換性があることを確認する必要があります。たとえば、クラスタの作成に使用されているサーバーインスタンスの port 番号が 6553 より大きい場合、計算された localAddress ポート番号が最大有効ポート 65535 を超えているため、dba.createCluster() 操作は失敗します。この状況を回避するには、InnoDB クラスタに使用するインスタンスで低い port 値を使用するか、localAddress 値を手動で割り当てます。次に例を示します:

mysql-js> dba.createCluster('testCluster', {'localAddress':'icadmin@ic-1:33061'}

PREV HOME UP NEXT

6.2.2.1 新しい本番 InnoDB クラスタ のデプロイ

本番インスタンスの構成

クラスタの作成

クラスタへのインスタンスの追加

InnoDB クラスタによって作成されたユーザーアカウント

InnoDB クラスタ ポートの構成

6.2.2.1 新しい本番 InnoDB クラスタのデプロイ

InnoDB クラスタポートの構成