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

17.3.3.3 失敗したレプリケーション権限チェックからのリカバリ

PRIVILEGE_CHECKS_USER アカウントに対する権限チェックが失敗した場合、トランザクションは実行されず、チャネルのレプリケーションは停止します。 エラーの詳細と最後に適用されたトランザクションは、パフォーマンススキーマ replication_applier_status_by_worker テーブルに記録されます。 エラーから回復するには、次の手順に従います:

1. エラーの原因となったレプリケートイベントを特定し、イベントが予想されるかどうか、および信頼できるソースからのものかどうかを確認します。 mysqlbinlog を使用して、エラー発生時にログに記録されたイベントを取得して表示できます。 これを行う手順は、セクション7.5「Point-in-Time (増分) リカバリ」 を参照してください。

2. レプリケートされたイベントが予期されていないか、既知の信頼できるソースからのものでない場合は、原因を調査します。 イベントが発生した理由がわかり、セキュリティ上の考慮事項がない場合は、次の説明に従ってエラーの修正に進みます。

3. PRIVILEGE_CHECKS_USER アカウントがトランザクションの実行を許可されている必要があるが、正しく構成されていない場合は、アカウントに不足している権限を付与し、チャネルのレプリケーションを再開します。

4. トランザクションを実行する必要があり、信頼できることを確認したが、PRIVILEGE_CHECKS_USER アカウントにこの権限を通常どおりに付与しない場合は、PRIVILEGE_CHECKS_USER アカウントに必要な権限を一時的に付与できます。 レプリケートされたイベントが適用されたら、アカウントから権限を削除し、必要なステップを実行して、回避できる場合にイベントが繰り返されないようにします。

5. トランザクションがソースでのみ実行され、レプリカでは実行されない管理アクションである場合、または単一のレプリケーショングループメンバーでのみ実行される必要がある場合は、レプリケーションを停止したサーバーでトランザクションをスキップし、START REPLICA | SLAVE を発行してチャネルでレプリケーションを再起動します。 今後の状況を回避するために、その前に SET sql_log_bin = 0 を使用し、その後に SET sql_log_bin = 1 を使用してこのような管理ステートメントを発行して、ソースに記録されないようにすることができます。

6. トランザクションがソースまたはレプリカで行われてはならない DDL ステートメントまたは DML ステートメントである場合は、レプリケーションを停止したサーバー上のトランザクションをスキップし、トランザクションを元のサーバー上で手動で取り消してから、START REPLICA | SLAVE を発行してレプリケーションを再起動します。

GTID が使用中の場合にトランザクションをスキップするには、失敗したトランザクションの GTID を持つ空のトランザクションをコミットします。次に例を示します:

SET GTID_NEXT='aaa-bbb-ccc-ddd:N';
BEGIN;
COMMIT;
SET GTID_NEXT='AUTOMATIC';

GTID が使用されていない場合は、SET GLOBAL sql_slave_skip_counter ステートメントを発行してイベントをスキップします。 この代替方法を使用する手順およびトランザクションのスキップの詳細は、セクション17.1.7.3「トランザクションのスキップ」 を参照してください。