📣
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ページに表示されます。

エラーメッセージ："The required binary log for migration no longer exists on the source database. Please make sure binary log files are kept for long enough time for migration to succeed."

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

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

エラーメッセージ："Failed to connect to the source database using given parameters. Please make sure the source database is up and can be connected using the given parameters."

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

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

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

エラーメッセージ："Failed to connect to the TiDB cluster using the given user and password. Please make sure TiDB Cluster is up and can be connected to using the given user and password."

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

エラーメッセージ："TiDB cluster storage is not enough. Please increase the node storage of TiKV."

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

エラーメッセージ："Failed to connect to the source database. Please check whether the database is available or the maximum connections have been reached."

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

エラーメッセージ："Error 1273: Unsupported collation when new collation is enabled: 'utf8mb4_0900_ai_ci'"

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

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

エラーメッセージ："LOCK TABLES ... Access denied"

ソースデータベースユーザーに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の組み込みアラート機能を参照してください。

関連項目

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