Oracle Cloud Infrastructureドキュメント

Inbound Replicationのトラブルシューティング

インバウンド・レプリケーション・エラーのトラブルシューティング

インバウンド・レプリケーション関連の情報を取得して、インバウンド・レプリケーション・エラーを分離します。

MySQLシェルの使用

インバウンド・レプリケーション関連情報を取得するには、MySQLシェルまたはMySQLクライアント・プログラムを使用します。

このタスクでは次が必要です:
  • 実行中のレプリカDBシステム。
  • レプリカDBシステムに接続されているMySQLシェルまたはMySQLクライアント・プログラム。
レプリカDBシステムで次のコマンドを実行して、インバウンド・レプリケーション関連情報を取得します:
  • SHOW REPLICA STATUS \G

    レプリカ・スレッドの必須パラメータに関するステータス情報を示します。SHOW REPLICA STATUSを参照してください。

  • SELECT * FROM performance_schema.replication_connection_status \G

    ソースへのレプリカの接続を処理するI/Oスレッドの現在のステータスを示します。replication_connection_statusを参照してください。

  • SELECT * FROM performance_schema.replication_applier_status_by_worker \G

    レプリカで適用側スレッドによって処理されるトランザクションの詳細を示します。replication_applier_status_by_workerを参照してください。

インバウンド・レプリケーション受信側エラー・コード

この表は、一般的なインバウンド・レプリケーション・レシーバのエラー・コードの一部を示しています。

表22-4インバウンド・レプリケーション受信側エラー・コード

エラー・コード 説明
MY-1045: ER_ACCESS_DENIED_ERROR; Access denied for user '%s'@'%s'
  • ソースのユーザー名またはパスワードが間違っています。資格証明を確認してください。
  • ユーザーにはソースにアクセスする権限がありません。ソースを確認し、レプリケーション・ユーザーが正しく構成されていることを確認します。
MY-1227 (42000): Access denied; you need (at least one of) the SUPER or SET_USER_ID privilege(s) for this operation 次のいずれかを実行できます。
  • DEFINERおよび「Applier username」に同じユーザー名を指定します。SET_USER_ID権限が必要なのは、DEFINERとApplier usernameのユーザー名が異なる場合のみです。レプリケーション・チャネルの作成を参照してください。
  • Oracle Supportに連絡して、SET_USER_ID権限をApplierユーザー名に付与してください。
MY-1236: ER_MASTER_FATAL_ERROR_READING_BINLOG Got fatal error %d from master when reading data from binary log: '%s' Fatal Error 1236の解決を参照してください。
MY-2003: Network connection has been refused ホスト名とポートが正しくないか、ソースが実行されていません。定義したホスト名とポートを確認し、ソースが実行中であることを確認します。
MY-3159: ER_SECURE_TRANSPORT_REQUIRED Connections using insecure transport are prohibited while --require_secure_transport=ON ソースでセキュアな接続が必要です。チャネルを定義したときに、いずれかのSSLオプションを選択したことを確認します。
MySQLエラー・メッセージの完全なリストは、サーバー・エラー・メッセージ・リファレンスを参照してください。

インバウンド・レプリケーション適用側エラー・コード

この表は、一般的なインバウンド・レプリケーション・アプリケーションのエラー・コードの一部を示しています。

表22-5インバウンド・レプリケーション適用側エラー・コード

エラー・コード 説明
  • MY-1146: ER_NO_SUCH_TABLE;
  • MY-1032: HA_ERR_KEY_NOT_FOUND
  • MY-1062: HA_ERR_FOUND_DUPP_KEY
  • MY-1064: ERROR IN SQL syntax
  • MY-1050: ER_TABLE_EXISTS_ERROR
  • MY-1051: ER_BAD_TABLE_ERROR
  • MY-1146: ER_NO_SUCH_TABLE
  • MY-1007: ER_DB_CREATE_EXISTS
  • MY-1054: ER_BAD_FIELD_ERROR

これらのエラーは、レプリカ上のデータがソースと同期しなくなった場合に発生します。たとえば、レプリカのデータが手動で編集された場合などに発生する可能性があります。

これらのエラーを修正するには、ソースとレプリカを再同期し、レプリケーション・チャネルを再開する必要があります。

MY-1205: ER_LOCK_WAIT_TIMEOUT タイムアウトが超過しました。このエラーを修正するには、レプリケーション・チャネルを再開します。チャネルの再開を参照してください。
MY-1595/ MY-013121: RELAY LOG READ FAILURE リレー・ログは破損しており、読み取れません。このエラーを修正するには、レプリケーション・チャネルをリセットします。チャネルのリセットを参照してください。
MySQLエラー・メッセージの完全なリストは、サーバー・エラー・メッセージ・リファレンスを参照してください。

Fatal Error 1236の解決

論理ダンプからのGTIDセットがDBシステムに適用されていないか、バイナリ・ログがソースからパージされた場合に、エラーが発生します。バイナリ・ログはレプリケーションの必須要件です。

MySQLシェルの使用

MySQLシェルを使用して、インバウンド・レプリケーションの実行中に返されるFatal Error 1236を解決します。

このタスクの前提は次のとおりです:
  • インバウンド・レプリケーションの実行中にFatal Error 1236が返されます: 
    Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting
      using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs
      containing GTIDs that the slave requires.

初期接続ハンドシェイクで、レプリカ(DBシステム)は、受信済、コミット済またはその両方のトランザクションを含むGTIDセットを送信します。ソースは、バイナリ・ログに記録されているすべてのトランザクション(レプリカによって送信されたGTIDセットにGTIDが含まれていないもの)を送信することで応答します。このようなやり取りにより、ソースは、レプリカがまだ記録またはコミットしていないGTIDのトランザクションのみを確実に送信できます。

この問題を解決するには、次を実行します:

レプリカとソースの同期の問題の解決

レプリカがソースから大幅に遅れており、レプリケーションがリカバリ不能になると、同期の問題が発生します。

ノート

このエラーからリカバリする前に、エラーが発生した理由を調査して修正処理を実行することをお薦めします。

MySQLシェルの使用

MySQLシェルを使用して、レプリカおよびソースの同期の問題を解決します。

このタスクの前提は次のとおりです:
  • インバウンド・レプリケーションのソースとレプリカが同期しなくなり、レプリカがソースから大幅に遅れて、レプリケーションがリカバリ不能になっています。
ノート

ソースのgtid値がレプリカの値よりも低くリセットされた場合、たとえば、ソースで誤ったreset masterが発行されると、インバウンド・レプリケーションがリカバリ不能になります。そのシナリオでは、DBシステムおよびインバウンド・レプリケーション構成を再作成します。
レプリカをソースと再同期するには、次を実行します:
  1. 既存のレプリケーション・チャネルを停止し、ソース上のすべてのトランザクションを一時停止します。
  2. ソース・データをオブジェクト・ストレージにエクスポートします。詳細は、MySQLインスタンスのエクスポートを参照してください。
  3. レプリカ上の古いデータベース・オブジェクトおよび既存のデータベースを削除します。
  4. オブジェクト・ストレージからDB Systemにダンプをインポートします。MySQLシェルを使用したインポートを参照してください。
  5. レプリカからgtidExecuted値を取得します。
  6. ソース・ダンプ@.jsonファイルからgtidExecuted値を取得します。
  7. レプリカのgtidExecutedをソース・ダンプgtidExecutedと比較し、gtidExecutedデルタを取得します。
    たとえば、ソース・ダンプのgtidExecutedがserverUUID: 1-2000で、レプリカのgtidExecutedがserverUUID:1-1000の場合、デルタ値は1001-2000になります。
  8. コマンドラインからレプリカに接続し、CALL sys.SET_GTID_PURGED("+<ServerUUID>:<DeltaValue>)ストアド・プロシージャを使用してデルタをレプリカに適用します。
    たとえば、前述の例で示したデルタ値を使用します: 
    call sys.SET_GTID_PURGED("+<ServerUUID>:1001-2000")
  9. プロセスが完了したら、レプリケーション・チャネルを再開します。