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

17.3.3.1 レプリケーション PRIVILEGE_CHECKS_USER アカウントの権限

レプリケーションチャネルの PRIVILEGE_CHECKS_USER アカウントとして CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを使用して指定されたユーザーアカウントには、REPLICATION_APPLIER 権限が必要です。権限がない場合、レプリケーションアプライアンススレッドは起動しません。 セクション17.3.3「レプリケーション権限チェック」 で説明されているように、アカウントには、レプリケーションチャネルで予想されるすべてのトランザクションを適用するのに十分な追加の権限が必要です。 これらの権限は、関連するトランザクションが実行された場合にのみチェックされます。

PRIVILEGE_CHECKS_USER アカウントを使用して保護されているレプリケーションチャネルには、行ベースのバイナリロギング (binlog_format=ROW) を使用することを強くお薦めします。 ステートメントベースのバイナリロギングでは、PRIVILEGE_CHECKS_USER アカウントがトランザクションを正常に実行するために、一部の管理者レベルの権限が必要になる場合があります。 MySQL 8.0.19 から、REQUIRE_ROW_FORMAT 設定を保護されたチャネルに適用できます。これにより、チャネルはこれらの権限を必要とするイベントを実行できなくなります。

REPLICATION_APPLIER 権限によって、PRIVILEGE_CHECKS_USER アカウントはレプリケーションスレッドが実行する必要がある次の操作を明示的または暗黙的に実行できます:

• システム変数 gtid_next, original_commit_timestamp, original_server_version, immediate_server_version および pseudo_slave_mode の値を設定して、トランザクションの実行時に適切なメタデータおよび動作を適用します。

• 内部使用の BINLOG ステートメントを実行して mysqlbinlog 出力を適用します (アカウントにそれらのステートメントのテーブルおよび操作に対する権限もある場合)。

• レプリケーションメタデータを更新するためのシステムテーブル mysql.gtid_executed, mysql.slave_relay_log_info, mysql.slave_worker_info および mysql.slave_master_info の更新。 (イベントが他の目的でこれらのテーブルに明示的にアクセスする場合は、テーブルに対する適切な権限を付与する必要があります。)

• バイナリログ Table_map_log_event を適用します。これは、テーブルメタデータを提供しますが、データベースの変更は行いません。

CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントの REQUIRE_TABLE_PRIMARY_KEY_CHECK オプションがデフォルトの STREAM に設定されている場合、PRIVILEGE_CHECKS_USER アカウントには、ソースからレプリケートされた設定と一致するようにセッション期間中に sql_require_primary_key システム変数の値を変更できるように、制限付きセッション変数を設定するのに十分な権限が必要です。 SESSION_VARIABLES_ADMIN 権限により、アカウントにこの機能が付与されます。 この権限により、アカウントは --disable-log-bin オプションを使用して作成された mysqlbinlog 出力を適用することもできます。 REQUIRE_TABLE_PRIMARY_KEY_CHECK を ON または OFF のいずれかに設定した場合、レプリカはレプリケーション操作で sql_require_primary_key システム変数にその値を常に使用するため、これらのセッション管理レベルの権限は必要ありません。

テーブルの暗号化が使用されており、table_encryption_privilege_check システム変数が ON に設定されており、イベントに関係するテーブルスペースの暗号化設定が (default_table_encryption システム変数で指定された) サーバーのデフォルトの暗号化設定の適用と異なる場合、PRIVILEGE_CHECKS_USER アカウントでは、デフォルトの暗号化設定をオーバーライドするために TABLE_ENCRYPTION_ADMIN 権限が必要です。 この権限を付与しないことを強くお薦めします。 かわりに、レプリカのデフォルトの暗号化設定がレプリケートするテーブルスペースの暗号化ステータスと一致し、レプリケーショングループメンバーのデフォルトの暗号化設定が同じであることを確認して、権限が不要になるようにします。

特定のレプリケートされたトランザクションをリレーログから実行するか、必要に応じて mysqlbinlog 出力から実行するには、PRIVILEGE_CHECKS_USER アカウントに次の権限が必要です:

• (Write_rows_log_event として記録される) 行形式で記録される行挿入の場合、関連するテーブルに対する INSERT 権限。

• (Update_rows_log_event として記録される) 行形式で記録された行更新の場合、関連するテーブルに対する UPDATE 権限。

• (Delete_rows_log_event として記録される) 行形式で記録された行の削除の場合、関連するテーブルに対する DELETE 権限。

ステートメントベースのバイナリロギングが使用されている (PRIVILEGE_CHECKS_USER アカウントでは推奨されません) 場合、BEGIN、COMMIT、DML logged in statement format (Query_log_event として記録されます) などのトランザクション制御ステートメントでは、PRIVILEGE_CHECKS_USER アカウントにはイベントに含まれるステートメントを実行する権限が必要です。

レプリケーションチャネルで LOAD DATA 操作を実行する必要がある場合は、行ベースのバイナリロギング (binlog_format=ROW) を使用します。 このロギング形式では、イベントの実行に FILE 権限は必要ないため、PRIVILEGE_CHECKS_USER アカウントにこの権限を付与しないでください。 PRIVILEGE_CHECKS_USER アカウントを使用して保護されているレプリケーションチャネルでは、行ベースのバイナリロギングを使用することを強くお勧めします。 チャネルに REQUIRE_ROW_FORMAT が設定されている場合は、行ベースのバイナリロギングが必要です。 LOAD DATA イベントによって作成された一時ファイルを削除する Format_description_log_event は、権限チェックなしで処理されます。 詳細は、セクション17.5.1.19「レプリケーションと LOAD DATA」を参照してください。

レプリケーション SQL スレッドの起動時に実行される 1 つ以上の SQL ステートメントを指定するように init_slave システム変数が設定されている場合、PRIVILEGE_CHECKS_USER アカウントにはこれらのステートメントの実行に必要な権限が必要です。

CREATE USER, CREATE ROLE, DROP ROLE や GRANT OPTION などの ACL 権限を PRIVILEGE_CHECKS_USER アカウントに付与しないこと、およびアカウントによる mysql.user テーブルの更新を許可しないことをお薦めします。 これらの権限では、アカウントを使用してサーバー上のユーザーアカウントを作成または変更できます。 ソースサーバーで発行された ACL ステートメントが実行のために保護されたチャネルにレプリケートされないようにするには (これらの権限がない場合は失敗します)、すべての ACL ステートメントの前に SET sql_log_bin = 0 を発行し、その後に SET sql_log_bin = 1 を発行して、ソースバイナリログからステートメントを除外します。 または、すべての ACL ステートメントを実行する前に専用の現行データベースを設定し、レプリケーションフィルタ (--binlog-ignore-db) を使用してレプリカでこのデータベースを除外することもできます。