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

6.2.11 既知の制限事項

このセクションでは、InnoDB クラスタ の既知の制限事項について説明します。 InnoDB クラスタ ではグループレプリケーションを使用するため、制限にも注意する必要があります。グループレプリケーションの制限事項 を参照してください。

• グローバルセッションの作成時にセッションタイプが指定されていない場合、MySQL Shell では、最初に NodeSession の作成を試行し、失敗した場合は ClassicSession の作成を試行する自動プロトコル検出が提供されます。 読取り/書込みポートが 1 つおよび読取り専用ポートが 2 つある 3 つのサーバーインスタンスで構成される InnoDB クラスタでは、MySQL Shell が読取り専用インスタンスのいずれかにのみ接続する可能性があります。 したがって、グローバルセッションの作成時には、常にセッションタイプを指定することをお薦めします。

• 非サンドボックスサーバーインスタンス (dba.deploySandboxInstance() を使用せずに手動で構成したインスタンス) をクラスタに追加する場合、MySQL Shell はインスタンス構成ファイルで構成の変更を永続化できません。 これにより、次のいずれかまたは両方のシナリオが発生します:

  1. グループレプリケーション構成はインスタンス構成ファイルに永続化されず、再起動時にインスタンスはクラスタに再参加しません。

  2. インスタンスはクラスタ使用に対して有効ではありません。 インスタンスは dba.checkInstanceConfiguration() を使用して検証でき、MySQL Shell では、インスタンスをクラスタで使用できるようにするために必要な構成変更が行われますが、これらの変更は構成ファイルに永続化されないため、再起動が発生すると失われます。

  a のみが発生した場合、インスタンスは再起動後にクラスタに再参加しません。

  b も発生し、再起動後にインスタンスがクラスタに再参加しなかった場合、この状況では推奨される dba.rebootClusterFromCompleteOutage() を使用してクラスタをオンラインに戻すことはできません。 これは、インスタンスが MySQL Shell によって行われた構成変更を失い、永続化されなかったため、インスタンスはクラスタ用に構成される前に前の状態に戻ります。 これにより、Group Replication が応答を停止し、最終的にコマンドがタイムアウトします。

  この問題を回避するには、構成の変更を永続化するために、クラスタにインスタンスを追加する前に dba.configureInstance() を使用することを強くお薦めします。

• オプションファイルを指定するための --defaults-extra-file オプションの使用は、InnoDB クラスタ サーバーインスタンスではサポートされていません。InnoDB クラスタ では、インスタンス上の単一のオプションファイルのみがサポートされ、追加のオプションファイルはサポートされません。 したがって、インスタンスオプションファイルを操作する場合は、メインファイルを指定する必要があります。 複数のオプションファイルを使用する場合は、ファイルを手動で構成し、複数のオプションファイルの使用の優先順位ルールを考慮して正しく更新されていることを確認し、目的の設定が認識されない余分なオプションファイル内のオプションによって誤って上書きされないようにします。

• 実際のネットワークインタフェースと一致しない IP アドレスに解決されるホスト名を持つインスタンスを使用しようとすると、「このインスタンスは自身の住所を the hostname として報告」というエラーで失敗します。 これは、Group Replication 通信レイヤーではサポートされません。 Debian ベースのインスタンスでは、localhost が存在しない IP (127.0.1.1 など) に解決されるため、インスタンスは user@localhost などのアドレスを使用できません。 これは、通常は単一マシン上のローカルインスタンスを使用するサンドボックスデプロイメントの使用に影響します。

  回避策は、マシンの実際の IP アドレスを使用するように各インスタンスで report_host システム変数を構成することです。 マシンの IP を取得し、各インスタンスの my.cnf ファイルに report_host=IP of your machine を追加します。 変更するには、インスタンスが再起動されていることを確認する必要があります。

• Cluster.addInstance() を実行して dba.createCluster() を実行するか、既存の InnoDB クラスタ にインスタンスを追加すると、次のエラーが MySQL エラーログに記録されます:

  2020-02-10T10:53:43.727246Z 12 [ERROR] [MY-011685] [Repl] Plugin
  group_replication reported: 'The group name option is mandatory'
  2020-02-10T10:53:43.727292Z 12 [ERROR] [MY-011660] [Repl] Plugin
  group_replication reported: 'Unable to start Group Replication on boot'

  これらのメッセージは無害であり、AdminAPI が Group Replication を起動する方法に関連しています。

• サンドボックスデプロイメントを使用する場合、各サンドボックスインスタンスは、$PATH のローカル mysql-sandboxes ディレクトリにある mysqld バイナリのコピーを使用します。 アップグレード後などに mysqld のバージョンが変更された場合、前のバージョンに基づくサンドボックスの起動に失敗します。 これは、サンドボックスバイナリが basedir の下にある依存関係と比較して古くなっているためです。 サンドボックスインスタンスは本番用に設計されていないため、一時的とみなされ、アップグレードではサポートされません。

  この問題を回避するには、アップグレードした mysqld バイナリを各サンドボックスの bin ディレクトリに手動でコピーします。 次に、dba.startSandboxInstance() を発行してサンドボックスを起動します。 操作はタイムアウトで失敗し、エラーログには次の情報が含まれます:

  2020-03-26T11:43:12.969131Z 5 [System] [MY-013381] [Server] Server upgrade
  from '80019' to '80020' started.
  2020-03-26T11:44:03.543082Z 5 [System] [MY-013381] [Server] Server upgrade
  from '80019' to '80020' completed.

  操作はタイムアウトで失敗したようですが、サンドボックスは正常に起動しました。

• InnoDB クラスタ は、手動で構成された非同期レプリケーションチャネルを管理しません。 グループレプリケーションおよび AdminAPI では、非同期レプリケーションがプライマリでのみアクティブであり、状態がインスタンス間でレプリケートされないことは保証されません。 これにより、レプリケーションが機能しなくなり、分割ブレーンが発生する可能性がある様々なシナリオが発生する可能性があります。 したがって、ある InnoDB クラスタ と別の InnoDB クラスタ の間のレプリケーションもサポートされていません。