6.2 MySQL InnoDB クラスタ
6.2.10 InnoDB クラスタ のヒント
InnoDB クラスタ のヒント
"ic-2:3306": [], "ic-3:3306": [], "global": [ {
"option": "location:", "value": "US East"
} ] } } }
ユーザー定義タグ付け
AdminAPI では、特定のクラスタ、ReplicaSet またはインスタンスに関連付けられたキーと値のペアに情報を格納で きる tag ネームスペースがサポートされています。 tag ネームスペースの下のオプションは制約されません。つま り、有効な MySQL ASCII 識別子であるかぎり、選択した情報でタグ付けできます。 名前が次の構文に従っているか ぎり、タグには任意の名前と値を使用できます: _または文字の後に英数字と_文字が続きます。
namespace オプションは、namespace:option という形式のコロン区切りの文字列です。ここで、namespace は
ネームスペースの名前、option は実際のオプション名です。 タグは、インスタンスレベル、クラスタレベルまたは ReplicaSet レベルで設定および削除できます。タグ名には、文字またはアンダースコアで始まり、オプションで英数字および_文字が続く任意の値
(^[a-zA-Z_][0-9a-zA-Z_]* など) を指定できます。 _のアンダースコア文字で始めることができるのは組込みタグのみです。
カスタムタグの使用方法はユーザーによって異なります。 クラスタにカスタムタグを設定して、そのタグが動作して いるリージョンをマークできます。 たとえば、クラスタ上で EMEA の値を持つ location という名前のカスタムタグを 設定できます。
このページは機械翻訳したものです。
InnoDB クラスタ のヒント
Do you want to disable super_read_only and continue? [y/N]: y Metadata Schema successfully removed.
インスタンスに対する現在のアクティブセッションの数が表示されます。 アプリケーションが誤ってインスタ ンスに書き込めないようにする必要があります。 y に応答することで、AdminAPI がインスタンスに書き込める ことを確認します。 リストされているインスタンスに複数のオープンセッションがある場合は、AdminAPI に
super_read_only=OFF の設定を許可する前に注意してください。
AdminAPI のユーザーの構成
InnoDB クラスタ または InnoDB ReplicaSet に属するインスタンスを使用するには、インスタンスを管理する適切な 権限を持つユーザーでインスタンスに接続する必要があります。AdminAPI には、適切なユーザーを管理する次の方 法が用意されています:
• 8.0.20 以降のバージョンでは、setupAdminAccount(user) 操作を使用して、InnoDB クラスタ または InnoDB ReplicaSet の管理に必要な権限を持つ MySQL ユーザーアカウントを作成またはアップグレードします。
• 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 クラスタ のヒント
InnoDB クラスタ および自動増分
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 % をインスタンス数に設定します。
InnoDB クラスタおよびバイナリログのパージ
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() 操作を使用して、カスタムパスワード存続期間 ポリシーに従うなど、InnoDB クラスタ によって作成された内部リカバリアカウントのパスワードをリセットできま す。 Cluster.resetRecoveryAccountsPassword() 操作を使用して、クラスタで使用されるすべての内部リカバリアカ ウントのパスワードをリセットします。 この操作では、オンラインの各インスタンスの内部リカバリアカウントに新 しいランダムパスワードが設定されます。 インスタンスに到達できない場合、操作は失敗します。 force オプション を使用してこのようなインスタンスを無視できますが、これはお薦めしません。この操作を使用する前に、インスタ ンスをオンラインに戻す方が安全です。 この操作は、InnoDB クラスタによって作成されたパスワードにのみ適用さ れ、手動で作成されたパスワードの更新には使用できません。
注記
リカバリアカウントのパスワードをパスワード verification-required ポリシーに関係なく変 更できるようにするには、この操作を実行するユーザーには、特に CREATE USER で必要
このページは機械翻訳したものです。
既知の制限事項
なすべての管理権限が必要です。 つまり、password_require_current システム変数が有効か どうかには関係ありません。