データ移行の事前チェック エラー、移行エラー、およびアラート
このドキュメントでは、 データ移行を使用してデータを移行する場合に事前チェック エラーを解決し、移行エラーをトラブルシューティングし、アラートを購読する方法について説明します。
事前チェックエラーと解決策
このセクションでは、データ移行時の事前チェック エラーと対応する解決策について説明します。これらのエラーは、 データ移行を使用してデータを移行するを実行すると[事前チェック]ページに表示されます。
解決策は上流のデータベースによって異なります。
エラー メッセージ: mysql server_id が 0 より大きいかどうかを確認してください
- Amazon Aurora MySQL または Amazon RDS:
server_id
がデフォルトで設定されています。設定する必要はありません。完全データ移行と増分データ移行の両方をサポートするには、Amazon Aurora MySQL ライター インスタンスを使用していることを確認してください。 - MySQL: MySQL に
server_id
設定するには、 レプリケーションソースコンフィグレーションの設定を参照してください。
エラー メッセージ: mysql binlogが有効かどうかを確認してください
- Amazon Aurora MySQL: Amazon Aurora MySQL 互換クラスターのバイナリログを有効にするにはどうすればよいですか?を参照してください。完全データ移行と増分データ移行の両方をサポートするには、Amazon Aurora MySQL ライター インスタンスを使用していることを確認してください。
- Amazon RDS: MySQL バイナリ ロギングの構成を参照してください。
- Google Cloud SQL for MySQL: Google は、MySQL マスター データベースのポイントインタイム リカバリを通じてバイナリ ロギングを可能にします。 ポイントインタイムリカバリを有効にするを参照してください。
- MySQL: レプリケーションソースコンフィグレーションの設定を参照してください。
エラー メッセージ: mysql binlog_format が ROW であるかどうかを確認してください
- Amazon Aurora MySQL: Amazon Aurora MySQL 互換クラスターのバイナリログを有効にするにはどうすればよいですか?を参照してください。完全データ移行と増分データ移行の両方をサポートするには、Amazon Aurora MySQL ライター インスタンスを使用していることを確認してください。
- Amazon RDS: MySQL バイナリ ロギングの構成を参照してください。
- MySQL:
set global binlog_format=ROW;
を実行します。 バイナリログ形式の設定を参照してください。
エラー メッセージ: mysql binlog_row_image が FULL かどうかを確認してください
- 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
を設定します。
- Amazon Aurora MySQL: プロセスは
binlog_format
の設定と似ています。唯一の違いは、変更するパラメーターがbinlog_format
ではなくmax_connections
であることです。 Amazon Aurora MySQL 互換クラスターのバイナリログを有効にするにはどうすればよいですか?を参照してください。 - Amazon RDS: プロセスは
binlog_format
の設定と似ています。唯一の違いは、変更するパラメーターがbinlog_format
ではなくmax_connections
であることです。 MySQL バイナリ ロギングの構成を参照してください。 - MySQL: ドキュメント最大接続数に従って
max_connections
を設定します。
TiDB Cloudクラスターでエラーが発生した場合は、ドキュメント最大接続数に従ってmax_connections
を設定します。
移行エラーと解決策
このセクションでは、移行中に発生する可能性のある問題と解決策について説明します。これらのエラー メッセージは、 [移行ジョブの詳細]ページに表示されます。
エラー メッセージ: 「移行に必要なバイナリ ログは、ソース データベースに存在しません。移行が成功するために、バイナリ ログ ファイルが十分な期間保持されていることを確認してください。」
このエラーは、移行するバイナリログがクリーンアップされており、新しいタスクを作成することによってのみ復元できることを意味します。
増分移行に必要なバイナリログが存在することを確認してください。バイナリログの期間を延長するには、 expire_logs_days
を設定することをお勧めします。移行ジョブで必要な場合は、バイナリログのクリーンアップにpurge binary log
を使用しないでください。
エラー メッセージ:「指定されたパラメーターを使用してソース データベースに接続できませんでした。ソース データベースが起動しており、指定されたパラメーターを使用して接続できることを確認してください。」
このエラーは、ソース データベースへの接続が失敗したことを意味します。ソース データベースが起動されており、指定されたパラメータを使用して接続できるかどうかを確認します。ソース データベースが使用可能であることを確認した後、 [再起動]をクリックしてタスクの回復を試みることができます。
移行タスクが中断され、「ドライバー: 接続が正しくありません」または「接続が無効です」というエラーが発生します。
このエラーは、ダウンストリーム TiDB クラスターへの接続が失敗したことを意味します。ダウンストリーム TiDB クラスターが正常な状態 ( Available
とModifying
を含む) であり、ジョブで指定されたユーザー名とパスワードで接続できるかどうかを確認します。ダウンストリーム TiDB クラスターが使用可能であることを確認したら、 [再起動]をクリックしてタスクの再開を試みることができます。
エラー メッセージ: 「指定されたユーザーとパスワードを使用して TiDB クラスターに接続できませんでした。TiDBクラスタが起動しており、指定されたユーザーとパスワードを使用して接続できることを確認してください。」
TiDB クラスターへの接続に失敗しました。 TiDB クラスターが正常な状態 ( Available
とModifying
を含む) であるかどうかを確認することをお勧めします。ジョブで指定されたユーザー名とパスワードを使用して接続できます。 TiDB クラスターが使用可能であることを確認したら、 「再起動」をクリックしてタスクの再開を試みることができます。
エラー メッセージ:「TiDB クラスターstorageが十分ではありません。TiKV のノードstorageを増やしてください。」
TiDB クラスターのstorageが不足しています。 TiKV ノードのstorageを増やすし、 [再起動]をクリックしてタスクを再開することをお勧めします。
エラー メッセージ:「ソース データベースに接続できませんでした。データベースが利用可能か、または最大接続数に達しているかを確認してください。」
ソースデータベースへの接続に失敗しました。ソースデータベースが起動しているか、データベース接続数が上限に達していないか、ジョブで指定したパラメータを使用して接続できるかを確認することをお勧めします。ソース データベースが使用可能であることを確認したら、 [再起動]をクリックしてジョブを再開できます。
アラート
TiDB Cloudアラート電子メールを購読すると、アラートが発生したときにすぐに通知を受けることができます。
データ移行に関するアラートは次のとおりです。
「データのエクスポート中にデータ移行ジョブでエラーが発生しました」
推奨されるアクション: データ移行ページのエラー メッセージを確認し、ヘルプについては移行エラーと解決策を参照してください。
「データのインポート中にデータ移行ジョブでエラーが発生しました」
推奨されるアクション: データ移行ページのエラー メッセージを確認し、ヘルプについては移行エラーと解決策を参照してください。
「増分データ移行中にデータ移行ジョブでエラーが発生しました」
推奨されるアクション: データ移行ページのエラー メッセージを確認し、ヘルプについては移行エラーと解決策を参照してください。
「増分移行中にデータ移行ジョブが 6 時間以上一時停止されました」
推奨されるアクション: データ移行ジョブを再開するか、このアラートを無視してください。
「レプリケーションの遅延が 10 分を超えており、20 分以上増加し続けています」
- 推奨される処置: TiDB Cloudのサポートに連絡して助けを求めてください。
これらのアラートに対処するためにサポートが必要な場合は、 TiDB Cloudのサポートにお問い合わせください。
アラート電子メールを購読する方法の詳細については、 TiDB Cloud組み込みアラートを参照してください。