📣
TiDB Cloud Premium はパブリックプレビュー中です。エンタープライズワークロード向けの無制限のスケーリング、即時の弾力性、高度なセキュリティを提供します。このページは自動翻訳されたものです。原文はこちらからご覧ください。
AI
開発者
ベストプラクティス
API

データ移行に関する事前チェックエラー、移行エラー、およびアラート

このドキュメントではデータ移行を使用してデータを移行するときに、事前チェック エラーを解決し、移行エラーをトラブルシューティングし、アラートを購読する方法について説明します。

事前チェックのエラーと解決策

このセクションでは、データ移行時の事前チェック エラーと対応する解決策について説明します。これらのエラーはデータ移行を使用してデータを移行するときにPrecheckページに表示されます。

解決策は、使用している上位データベースによって異なります。

エラーメッセージ: mysql server_id が 0 より大きいかどうかを確認してください

  • Amazon Aurora MySQL または Amazon RDS: server_idはデフォルトで設定されています。設定する必要はありません。フルデータ移行と増分データ移行の両方をサポートするには、Amazon Aurora MySQL ライターインスタンスを使用していることを確認してください。
  • MySQL: MySQL 用にserver_idを構成するには、 レプリケーションソースコンフィグレーションの設定を参照してください。

エラーメッセージ: mysql binlogが有効になっているか確認してください

エラーメッセージ: mysql binlog_format が ROW かどうか確認してください

エラーメッセージ: mysql binlog_row_image が満杯かどうか確認してください

  • Amazon Aurora MySQL: binlog_row_imageは設定できません。この事前チェック項目は、設定変更の対象外です。完全データ移行と増分データ移行の両方をサポートするために、Amazon Aurora MySQL ライターインスタンスを使用していることを確認してください。
  • Amazon RDS: 手順はbinlog_formatパラメータの設定と似ています。唯一の違いは、変更する必要のあるパラメータがbinlog_formatではなくbinlog_row_imageであることです。MySQLバイナリログの設定を参照してください。
  • MySQL: set global binlog_row_image = FULL; 。 バイナリログのオプションと変数を参照してください。

エラーメッセージ: 移行されたデータベースが binlog_do_db/binlog_ignore_db に含まれているかどうかを確認してください

アップストリーム データベースでbinlogが有効になっていることを確認してください。 MySQLのbinlogが有効になっているか確認してくださいその後、表示されるメッセージに従って問題を解決します。

  • メッセージがThese dbs xxx are not in binlog_do_db xxxに似ている場合は、移行したいすべてのデータベースがリストに含まれていることを確認してください。-- --binlog-do-db=db_nameを参照してください。
  • メッセージがThese dbs xxx are in binlog_ignore_db xxxに似ている場合は、移行したいすべてのデータベースが無視リストに含まれていないことを確認してください。-- --binlog-ignore-db=db_nameを参照してください。

Amazon Aurora MySQL の場合、この事前チェック項目はエラーになりません。完全データ移行と増分データ移行の両方をサポートするために、Amazon Aurora MySQL ライターインスタンスを使用していることを確認してください。

Amazon RDS の場合、次のパラメータを変更する必要があります: replicate-do-db 、 replicate-do-table 、 replicate-ignore-db 、およびreplicate-ignore-table 。MySQLバイナリログの設定を参照してください。

エラーメッセージ：接続同時接続数がデータベースの最大接続制限を超えていないか確認してください。

上流のデータベースでエラーが発生した場合は、 max_connectionsを次のように設定してください。

TiDB Cloudクラスターでエラーが発生した場合は、ドキュメントの最大接続数に従ってmax_connectionsを設定します。

移行エラーとその解決策

このセクションでは、移行中に発生する可能性のある問題とその解決策について説明します。これらのエラーメッセージは、Migration Job Detailsページに表示されます。

エラーメッセージ：「移行に必要なバイナリログがソースデータベースに存在しません。移行が成功するためには、バイナリログファイルが十分な期間保持されていることを確認してください。」

このエラーは、移行対象のバイナリログが既にクリーンアップされており、新しいタスクを作成することによってのみ復元できることを意味します。

増分移行に必要なバイナリログが存在することを確認してください。バイナリログの保存期間を延長するために、 expire_logs_daysを設定することをお勧めします。移行ジョブでバイナリログのクリーンアップが必要な場合は、 purge binary logを使用してバイナリログをクリーンアップしないでください。

エラーメッセージ：「指定されたパラメータを使用してソースデータベースに接続できませんでした。ソースデータベースが稼働しており、指定されたパラメータを使用して接続できることを確認してください。」

このエラーは、ソースデータベースへの接続に失敗したことを意味します。ソースデータベースが起動しており、指定されたパラメータを使用して接続できるかどうかを確認してください。ソースデータベースが利用可能であることを確認したら、 Restartをクリックしてタスクの復旧を試みてください。

移行タスクが中断され、"driver: bad connection"または"invalid connection"というエラーが含まれています。

このエラーは、ダウンストリームの TiDB クラスタへの接続に失敗したことを意味します。ダウンストリームの TiDB クラスタが正常な状態（ AvailableおよびModifyingを含む）であり、ジョブで指定されたユーザー名とパスワードで接続できるかどうかを確認してください。ダウンストリームの TiDB クラスタが利用可能であることを確認したら、 Restartをクリックしてタスクを再開してみてください。

エラーメッセージ：「指定されたユーザー名とパスワードを使用してTiDBクラスタに接続できませんでした。TiDBクラスタが起動しており、指定されたユーザー名とパスワードで接続できることを確認してください。」

TiDB クラスターへの接続に失敗しました。TiDB クラスターが正常な状態（ AvailableおよびModifyingを含む）であるかどうかを確認することをお勧めします。ジョブで指定されたユーザー名とパスワードを使用して接続できます。TiDB クラスターが利用可能であることを確認したら、 Restartをクリックしてタスクを再開してみてください。

エラーメッセージ：「TiDBクラスタのストレージが不足しています。TiKVのノードストレージを増やしてください。」

TiDB クラスターのストレージが不足しています。 TiKVノードのストレージを増やすから、 Restartをクリックしてタスクを再開することをお勧めします。

エラーメッセージ：「ソースデータベースへの接続に失敗しました。データベースが利用可能か、または最大接続数に達していないかを確認してください。」

ソースデータベースへの接続に失敗しました。ソースデータベースが起動しているか、データベース接続数が上限に達していないか、ジョブで指定されたパラメータを使用して接続できるかを確認してください。ソースデータベースが利用可能であることを確認したら、 Restartをクリックしてジョブを再開してください。

エラーメッセージ：「エラー 1273: 新しい照合順序が有効になっている場合、サポートされていない照合順序です: 'utf8mb4_0900_ai_ci'」

ダウンストリームのTiDBクラスタでスキーマを作成できませんでした。このエラーは、アップストリームのMySQLで使用されている照合順序がTiDBクラスタでサポートされていないことを意味します。

この問題を解決するには、 サポートされている照合順序に基づいて TiDB クラスターにスキーマを作成し、 Restartをクリックしてタスクを再開します。

エラーメッセージ：「LOCK TABLES ... アクセスが拒否されました」

ソースデータベースユーザーにLOCK TABLES権限がないため、データの完全なエクスポートが失敗します。このエラーは通常、マネージド MySQL サービス (Amazon RDS、 Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL、Google Cloud SQL など) から移行する場合に発生します。これらのサービスでは、クラウドプロバイダーによってFLUSH TABLES WITH READ LOCK (FTWRL) が許可されていません。このシナリオでは、DM はデフォルトのconsistency=autoモードを使用し、完全なエクスポート中にデータの一貫性を確保するためにLOCK TABLESにフォールバックします。この操作にはLOCK TABLES権限が必要です。

この問題を解決するには、移行元のMySQLデータベースで、移行ユーザーにLOCK TABLES権限を付与してください。

GRANT LOCK TABLES ON *.* TO 'dm_source_user'@'%';

その後、 Restartをクリックしてタスクを再開してください。

アラート

TiDB Cloudのアラートメールを購読すると、アラートが発生した際にタイムリーに通知を受け取ることができます。

データ移行に関するアラートは以下のとおりです。

  • データ移行ジョブで、データエクスポート中にエラーが発生しました。

    推奨されるアクション: データ移行ページでエラーメッセージを確認し、移行エラーとその解決策でヘルプを参照してください。

  • データ移行ジョブのデータインポート中にエラーが発生しました

    推奨されるアクション: データ移行ページでエラーメッセージを確認し、移行エラーとその解決策でヘルプを参照してください。

  • 「増分データ移行中にデータ移行ジョブでエラーが発生しました」

    推奨されるアクション: データ移行ページでエラーメッセージを確認し、移行エラーとその解決策でヘルプを参照してください。

  • 「増分移行中にデータ移行ジョブが6時間以上一時停止されました」

    推奨される対処法：データ移行ジョブを再開するか、このアラートを無視してください。

  • 「レプリケーション遅延が10分を超え、20分以上経過してもなお増加し続けている」

これらのアラートへの対応についてサポートが必要な場合は、 TiDB Cloudサポートにお問い合わせください。

アラート電子メールを購読する方法の詳細については、 TiDB Cloudの組み込みアラート機能を参照してください。

関連項目

このページは役に立ちましたか？