データ移行の事前チェックエラー、移行エラー、アラート
このドキュメントでは、事前チェック エラーを解決し、移行エラーをトラブルシューティングし、 データ移行を使用してデータを移行するの際にアラートをサブスクライブする方法について説明します。
事前チェックのエラーと解決策
このセクションでは、データ移行中の事前チェック エラーと対応する解決策について説明します。これらのエラーは、 データ移行を使用してデータを移行する実行すると事前チェックページに表示されます。
解決策は、アップストリーム データベースによって異なります。
エラーメッセージ: 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 マスター データベースのポイントインタイム リカバリによるバイナリ ログ記録を有効にします。1 ポイントインタイムリカバリを有効にする参照してください。
- MySQL: レプリケーションソースコンフィグレーションの設定参照してください。
エラーメッセージ: mysql binlog_format が ROW であるかどうかを確認してください
- Amazon Aurora MySQL: Amazon Aurora MySQL互換クラスターのバイナリログを有効にする方法を参照してください。完全データ移行と増分データ移行の両方をサポートするために、Amazon Aurora MySQL ライターインスタンスを使用していることを確認します。
- Amazon RDS: MySQL バイナリログの設定参照してください。
- MySQL:
set global binlog_format=ROW;
を実行します。3 バイナリログ形式の設定参照してください。
エラーメッセージ: mysql binlog_row_image が FULL かどうかを確認してください
- Amazon Aurora MySQL:
binlog_row_image
は設定できません。この事前チェック項目は、これに対しては失敗しません。完全データ移行と増分データ移行の両方をサポートするために、Amazon Aurora MySQL ライターインスタンスを使用していることを確認してください。 - Amazon RDS: プロセスは
binlog_format
パラメータの設定と似ています。唯一の違いは、変更する必要があるパラメータがbinlog_format
ではなくbinlog_row_image
であることです。7 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=データベース名参照してください。 - メッセージが
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
であることです。7 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が不足しています。1 TiKVノードstorageを増やす実行してから、 [再起動]をクリックしてタスクを再開することをお勧めします。
エラー メッセージ:「ソース データベースへの接続に失敗しました。データベースが使用可能かどうか、または最大接続数に達しているかどうかを確認してください。」
ソース データベースへの接続に失敗しました。ソース データベースが起動されているか、データベース接続数が上限に達していないか、ジョブで指定されたパラメータを使用して接続できるかどうかを確認することをお勧めします。ソース データベースが使用可能であることを確認した後、 [再起動] をクリックしてジョブの再開を試みることができます。
エラー メッセージ: 「エラー 1273: 新しい照合順序が有効になっているときにサポートされていない照合順序: 'utf8mb4_0900_ai_ci'」
ダウンストリーム TiDB クラスターでスキーマを作成できませんでした。このエラーは、アップストリーム MySQL で使用される照合順序がTiDB クラスターでサポートされていないことを意味します。
この問題を解決するには、 サポートされている照合順序に基づいて TiDB クラスターにスキーマを作成し、 「再起動」をクリックしてタスクを再開します。
アラート
アラートが発生したときに通知を受け取るために、 TiDB Cloudアラート メールを購読することができます。
以下はデータ移行に関するアラートです。
「データ移行ジョブでデータのエクスポート中にエラーが発生しました」
推奨されるアクション: データ移行ページのエラー メッセージを確認し、ヘルプについては移行エラーと解決策参照してください。
「データ移行ジョブでデータのインポート中にエラーが発生しました」
推奨されるアクション: データ移行ページのエラー メッセージを確認し、ヘルプについては移行エラーと解決策参照してください。
「増分データ移行中にデータ移行ジョブでエラーが発生しました」
推奨されるアクション: データ移行ページのエラー メッセージを確認し、ヘルプについては移行エラーと解決策参照してください。
「増分移行中にデータ移行ジョブが 6 時間以上一時停止されました」
推奨されるアクション: データ移行ジョブを再開するか、このアラートを無視します。
「レプリケーション ラグは 10 分を超えており、20 分以上増加し続けています」
- 推奨されるアクション: TiDB Cloudサポートに連絡してサポートを受けてください。
これらのアラートに対処するためにサポートが必要な場合は、 TiDB Cloudサポート連絡してご相談ください。
アラートメールの購読方法の詳細については、 TiDB Cloud組み込みアラート参照してください。