サーバーインスタンスから本番デプロイメントを作成する前に、各インスタンスの MySQL が正しく構成されていることを確認する必要があります。 インスタンスの構成の一部として構成をチェックする dba.configureInstance() に加えて、dba.checkInstanceConfiguration(instance) 関数を使用できます。 これにより、インスタンスの構成を変更せずに、instance が セクション6.2.1「MySQL InnoDB クラスタ の要件」 を満たしていることが保証されます。 インスタンス上のデータはチェックされません。詳細は、インスタンスの状態の確認 を参照してください。

instance への接続に使用するユーザーには、AdminAPI のユーザーの構成 での構成など、適切な権限が必要です。 実行中の MySQL Shell でこれを発行する方法を次に示します:

mysql-js> dba.checkInstanceConfiguration('icadmin@ic-1:3306')
Please provide the password for 'icadmin@ic-1:3306': ***
Validating MySQL instance at ic-1:3306 for use in an InnoDB cluster...

This instance reports its own address as ic-1
Clients and other cluster members will communicate with it through this address by default.
If this is not correct, the report_host MySQL system variable should be changed.

Checking whether existing tables comply with Group Replication requirements...
No incompatible tables detected

Checking instance configuration...

Some configuration options need to be fixed:
+--------------------------+---------------+----------------+--------------------------------------------------+
| Variable                 | Current Value | Required Value | Note                                             |
+--------------------------+---------------+----------------+--------------------------------------------------+
| enforce_gtid_consistency | OFF           | ON             | Update read-only variable and restart the server |
| gtid_mode                | OFF           | ON             | Update read-only variable and restart the server |
| server_id                | 1             |                | Update read-only variable and restart the server |
+--------------------------+---------------+----------------+--------------------------------------------------+

Please use the dba.configureInstance() command to repair these issues.

{
    "config_errors": [
        {
            "action": "restart",
            "current": "OFF",
            "option": "enforce_gtid_consistency",
            "required": "ON"
        },
        {
            "action": "restart",
            "current": "OFF",
            "option": "gtid_mode",
            "required": "ON"
        },
        {
            "action": "restart",
            "current": "1",
            "option": "server_id",
            "required": ""
        }
    ],
    "status": "error"
}

クラスタの一部として使用する予定のサーバーインスタンスごとに、このプロセスを繰り返します。 dba.checkInstanceConfiguration() の実行後に生成されたレポートには、続行する前に必要な構成変更に関する情報が表示されます。 レポートの config_error セクションの action フィールドには、構成ファイルに対する変更を検出するために、インスタンス上の MySQL の再起動が必要かどうかが示されます。

構成変更の永続化を自動的にサポートしていないインスタンス (設定の永続化 を参照) では、サーバーに接続し、MySQL Shell を実行し、インスタンスにローカルに接続して dba.configureLocalInstance() を発行する必要があります。 これにより、リモートインスタンスに対して次のコマンドを実行した後、MySQL Shell はインスタンスオプションファイルを変更できます:

SSH などを使用してリモートマシンにログインし、root ユーザーとして MySQL Shell を実行してから、ローカル MySQL サーバーに接続することをお薦めします。 たとえば、--uri オプションを使用してローカル instance に接続します:

shell> sudo -i mysqlsh --uri=instance

または、\connect コマンドを使用してローカルインスタンスにログインします。 次に、instance がローカルインスタンスへの接続情報である dba.configureInstance(instance) を発行して、ローカルインスタンスオプションファイルに加えられた変更を永続化します。

mysql-js> dba.configureLocalInstance('icadmin@ic-2:3306')

構成変更の永続化を自動的にサポートしていないクラスタ内のインスタンスごとに、このプロセスを繰り返します。 たとえば、構成変更の永続化を自動的にサポートしないクラスタに 2 つのインスタンスを追加する場合は、各サーバーに接続し、インスタンスを再起動する前に InnoDB クラスタ に必要な構成変更を永続化する必要があります。 同様に、インスタンス数の変更など、クラスタ構造を変更する場合は、サーバーインスタンスごとにこのプロセスを繰り返して、クラスタ内のインスタンスごとに InnoDB クラスタ メタデータを更新する必要があります。

cluster.checkInstanceState() 関数を使用すると、インスタンス上の既存のデータがクラスタへの参加を妨げないことを検証できます。 このプロセスは、クラスタによってすでに処理されている GTID と比較して、インスタンスグローバルトランザクション識別子 (GTID) の状態を検証することで機能します。 GTID の詳細は、GTID 形式および格納 を参照してください。 このチェックでは、トランザクションを処理したインスタンスをクラスタに追加できるかどうかを判断できます。

実行中の MySQL Shell でこれを発行する方法を次に示します:

mysql-js> cluster.checkInstanceState('icadmin@ic-4:3306')

この関数の出力は、次のいずれかです:

OK ステータスのインスタンスは、インスタンス上のデータがクラスタと一貫性があるため、クラスタに追加できます。 つまり、チェック中のインスタンスは、クラスタによって実行された GTID と競合するトランザクションを実行しておらず、残りのクラスタインスタンスと同じ状態にリカバリできます。