PDF (US Ltr)
- 1.4Mb
PDF (A4)
- 1.4Mb
このページは機械翻訳したものです。
このセクションでは、InnoDB クラスタ の使用時に知っておくとよい情報について説明します。
グループレプリケーションが停止するたびに、インスタンスへの書込みが行われないように、super_read_only 変数が ON に設定されます。 このようなインスタンスを次の AdminAPI コマンドで使用しようとすると、インスタンスに super_read_only=OFF を設定することを選択できます:
dba.configureInstance()dba.configureLocalInstance()dba.dropMetadataSchema()
AdminAPI が super_read_only=ON を持つインスタンスを検出すると、対話モードで super_read_only=OFF を設定することを選択できます。 例:
mysql-js> var myCluster = dba.dropMetadataSchema()
Are you sure you want to remove the Metadata? [y/N]: y
The MySQL instance at 'localhost:3310' currently has the super_read_only system
variable set to protect it from inadvertent updates from applications. You must
first unset it to be able to perform any changes to this instance.
For more information see:
https://dev.mysql.com/doc/refman/en/server-system-variables.html#sysvar_super_read_only.
Do you want to disable super_read_only and continue? [y/N]: y
Metadata Schema successfully removed.
インスタンスに対する現在のアクティブセッションの数が表示されます。 アプリケーションが誤ってインスタンスに書き込めないようにする必要があります。 y に応答することで、AdminAPI がインスタンスに書き込めることを確認します。 リストされているインスタンスに複数のオープンセッションがある場合は、AdminAPI に super_read_only=OFF の設定を許可する前に注意してください。
InnoDB クラスタ または InnoDB ReplicaSet に属するインスタンスを使用するには、インスタンスを管理する適切な権限を持つユーザーでインスタンスに接続する必要があります。AdminAPI には、適切なユーザーを管理する次の方法が用意されています:
8.0.20 以降のバージョンでは、
setupAdminAccount(操作を使用して、InnoDB クラスタ または InnoDB ReplicaSet の管理に必要な権限を持つ MySQL ユーザーアカウントを作成またはアップグレードします。user)8.0.20 より前のバージョンでは、管理用のユーザーを作成するには、
dba.configureInstance()操作でclusterAdminオプションを使用することをお薦めします。
詳細は、管理用のユーザーアカウントの作成を参照してください。 管理ユーザーを手動で構成する場合、そのユーザーには次の権限 (すべて GRANT OPTION を含む) が必要です:
-
RELOAD,SHUTDOWN,PROCESS,FILE,SELECT,SUPER,REPLICATION SLAVE,REPLICATION CLIENT,REPLICATION_APPLIER,CREATE USER,SYSTEM_VARIABLES_ADMIN,PERSIST_RO_VARIABLES_ADMIN,BACKUP_ADMIN,CLONE_ADMINおよびEXECUTEの *.* に対するグローバル権限。注記SUPERには、次の必要な権限が含まれます:SYSTEM_VARIABLES_ADMIN,SESSION_VARIABLES_ADMIN,REPLICATION_SLAVE_ADMIN,GROUP_REPLICATION_ADMIN,REPLICATION_SLAVE_ADMIN,ROLE_ADMIN。 mysql_innodb_cluster_metadata.*、mysql_innodb_cluster_metadata_bkp.*およびmysql_innodb_cluster_metadata_previous.*のスキーマ固有の権限はALTER,ALTER ROUTINE,CREATE,CREATE ROUTINE,CREATE TEMPORARY TABLES,CREATE VIEW,DELETE,DROP,EVENT,EXECUTE,INDEX,INSERT,LOCK TABLES,REFERENCES,SHOW VIEW,TRIGGER,UPDATEで、mysql.*の権限はINSERT,UPDATE,DELETEです。
注記
この権限のリストは、現在のバージョンの MySQL Shell に基づいています。 権限はリリース間で変更される可能性があります。 したがって、アカウントを管理するための推奨方法は、管理用のユーザーアカウントの作成 で説明されている操作を使用することです
監視目的でユーザーを作成する場合など、読取り操作のみが必要な場合は、より制限された権限を持つアカウントを使用できます。 InnoDB クラスタ の監視に必要な権限をユーザー your_user に付与するには、次のコマンドを発行します:
GRANT SELECT ON mysql_innodb_cluster_metadata.* TO your_user@'%';
GRANT SELECT ON performance_schema.global_status TO your_user@'%';
GRANT SELECT ON performance_schema.global_variables TO your_user@'%';
GRANT SELECT ON performance_schema.replication_applier_configuration TO your_user@'%';
GRANT SELECT ON performance_schema.replication_applier_status TO your_user@'%';
GRANT SELECT ON performance_schema.replication_applier_status_by_coordinator TO your_user@'%';
GRANT SELECT ON performance_schema.replication_applier_status_by_worker TO your_user@'%';
GRANT SELECT ON performance_schema.replication_connection_configuration TO your_user@'%';
GRANT SELECT ON performance_schema.replication_connection_status TO your_user@'%';
GRANT SELECT ON performance_schema.replication_group_member_stats TO your_user@'%';
GRANT SELECT ON performance_schema.replication_group_members TO your_user@'%';
GRANT SELECT ON performance_schema.threads TO your_user@'%' WITH GRANT OPTION;詳細は、アカウント管理ステートメントを参照してください。
InnoDB クラスタ の一部としてインスタンスを使用している場合、マルチプライマリクラスタの自動増分衝突が最大 9 (グループレプリケーショングループの最大サポートサイズ) になる可能性を回避するために、auto_increment_increment および auto_increment_offset 変数が構成されます。 これらの変数の構成に使用されるロジックは、次のように要約できます:
グループがシングルプライマリモードで実行されている場合は、
auto_increment_incrementを 1 に、auto_increment_offsetを 2 に設定します。グループがマルチプライマリモードで実行されている場合、クラスタに 7 つ以下のインスタンスがあると、
auto_increment_incrementは 7 に設定され、auto_increment_offsetは 1 +server_id% 7 に設定されます。 マルチプライマリクラスタに 8 つ以上のインスタンスがある場合、auto_increment_incrementをインスタンス数に設定し、auto_increment_offsetを 1 +server_id% をインスタンス数に設定します。
MySQL 8 では、バイナリログは (binlog_expire_logs_seconds で定義されているように) 自動的にパージされます。 つまり、binlog_expire_logs_seconds より長い時間実行されていたクラスタには、最終的に、インスタンスによって適用されたすべてのトランザクションを含む完全なバイナリログを持つインスタンスが含まれていない可能性があります。 これにより、インスタンスをクラスタに参加させる前に、たとえば MySQL Enterprise Backup を使用してインスタンスを自動的にプロビジョニングする必要がある場合があります。 8.0.17 以降を実行しているインスタンスは、増分リカバリに依存しない自動プロビジョニングソリューションを提供することでこの問題を解決する MySQL クローンプラグインをサポートしています。セクション6.2.2.2「InnoDB クラスタ での MySQL クローンの使用」 を参照してください。 8.0.17 より前のバージョンを実行しているインスタンスは増分リカバリのみをサポートしているため、インスタンスが実行されている MySQL のバージョンによっては、インスタンスを自動的にプロビジョニングする必要がある場合があります。 そうしないと、Cluster.addInstance()
以前のバージョンの MySQL を実行しているインスタンスでは、バイナリログのパージに次のルールが使用されます:
8.0.1 より前のバージョンを実行しているインスタンスでは、
expire_logs_daysのデフォルト値が 0 であるため、バイナリログの自動パージは行われません。8.0.1 より後のバージョンを実行しているが、8.0.4 より前のバージョンを実行しているインスタンスでは、
expire_logs_daysのデフォルト値が 30 であるため、30 日後にバイナリログがパージされます。binlog_expire_logs_secondsのデフォルト値は 2592000 で、expire_logs_daysのデフォルト値は 0 であるため、8.0.10 より後のバージョンを実行しているインスタンスは 30 日後にバイナリログをパージします。
したがって、クラスタでバイナリログが実行されている期間によっては、パージされた可能性があり、インスタンスを手動でプロビジョニングする必要がある場合があります。 同様に、バイナリログを手動でパージした場合も、同じ状況が発生する可能性があります。 したがって、分散リカバリのために MySQL クローンによって提供される自動プロビジョニングを最大限に活用し、InnoDB クラスタ のインスタンスをプロビジョニングする際の停止時間を最小限に抑えるために、8.0.17 より後のバージョンの MySQL にアップグレードすることを強くお薦めします。
バージョン 8.0.18 から、Cluster.resetRecoveryAccountsPassword()Cluster.resetRecoveryAccountsPassword()force オプションを使用してこのようなインスタンスを無視できますが、これはお薦めしません。この操作を使用する前に、インスタンスをオンラインに戻す方が安全です。 この操作は、InnoDB クラスタによって作成されたパスワードにのみ適用され、手動で作成されたパスワードの更新には使用できません。
注記
リカバリアカウントのパスワードをパスワード verification-required ポリシーに関係なく変更できるようにするには、この操作を実行するユーザーには、特に CREATE USER で必要なすべての管理権限が必要です。 つまり、password_require_current システム変数が有効かどうかには関係ありません。