TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

TiDB データ移行に関するよくある質問

このドキュメントでは、TiDB データ移行 (DM) に関するよくある質問 (FAQ) をまとめています。

DM は、Alibaba RDS または他のクラウド データベースからのデータの移行をサポートしていますか?

現在、DM は MySQL または MariaDB binlogの標準バージョンのデコードのみをサポートしています。 Alibaba Cloud RDS またはその他のクラウド データベースではテストされていません。binlogが標準形式であることが確認された場合、サポートされています。

Alibaba Cloud RDS でプライマリ キーを持たないアップストリーム テーブルの場合、binlogには非表示のプライマリ キー列が含まれており、元のテーブル構造と矛盾するという既知の問題があります。

互換性のない既知の問題は次のとおりです。

タスク構成のブロック リストと許可リストの正規表現はnon-capturing (?!)をサポートしていますか?

現在、DM はそれをサポートしておらず、 Golang標準ライブラリの正規表現のみをサポートしています。 re2-syntax経由でGolangがサポートする正規表現を参照してください。

アップストリームで実行されるステートメントに複数の DDL 操作が含まれる場合、DM はそのような移行をサポートしますか?

DM は、複数の DDL 変更操作を含む 1 つのステートメントを、1 つの DDL 操作のみを含む複数のステートメントに分割しようとしますが、すべてのケースをカバーできるわけではありません。アップストリームで実行されるステートメントに DDL 操作を 1 つだけ含めるか、テスト環境で検証することをお勧めします。サポートされていない場合は、DM リポジトリに問題を提出できます。

互換性のない DDL ステートメントを処理する方法は?

TiDB でサポートされていない DDL ステートメントに遭遇した場合は、dmctl を使用して手動で処理する必要があります (DDL ステートメントをスキップするか、DDL ステートメントを指定された DDL ステートメントに置き換えます)。詳細については、 失敗した DDL ステートメントを処理するを参照してください。

ノート：

現在、TiDB は、MySQL がサポートするすべての DDL ステートメントと互換性があるわけではありません。 MySQL の互換性を参照してください。

現在、DM はビュー関連の DDL ステートメントを下流の TiDB クラスターに複製することも、ビュー関連の DML ステートメントを下流の TiDB クラスターに複製することもありません。

データ移行タスクをリセットする方法は?

データ移行中に例外が発生し、データ移行タスクを再開できない場合は、タスクをリセットしてデータを再移行する必要があります。

  1. stop-taskコマンドを実行して、異常なデータ移行タスクを停止します。

  2. ダウンストリームに移行されたデータをパージします。

  3. 次のいずれかの方法を使用して、データ移行タスクを再開します。

    • タスク構成ファイルで新しいタスク名を指定します。次にstart-task {task-config-file}を実行します。
    • start-task --remove-meta {task-config-file}を実行します。
[unit=Sync] ["error information"="{\"msg\":\"[code=36046:class=sync-unit:scope=internal:level=high] online ddls on ghost table `xxx`.`_xxxx_gho`\\ngithub.com/pingcap/dm/pkg/terror.(*Error).Generate ......

上記のエラーは、次の理由で発生する可能性があります。

最後のrename ghost_table to origin tableステップで、DM はメモリ内の DDL 情報を読み取り、元のテーブルの DDL に復元します。

ただし、メモリ内の DDL 情報は、次の 2 つの方法のいずれかで取得されます。

したがって、増分レプリケーションのプロセスで、指定された Pos がalter ghost_table DDL をスキップしたが、Pos がまだ gh-ost の online-ddl プロセスにある場合、ghost_table はメモリまたはdm_meta.{task_name}_onlineddlに正しく書き込まれません。このような場合、上記のエラーが返されます。

このエラーは、次の手順で回避できます。

  1. タスクのonline-ddl-scheme構成を削除します。

  2. block-allow-list.ignore-tablesで_{table_name}_gho 、および_{table_name}_delを設定_{table_name}_ghcます。

  3. ダウンストリーム TiDB でアップストリーム DDL を手動で実行します。

  4. Pos が gh-ost プロセス後の位置に複製されたら、 online-ddl-schemeを再度有効にしてblock-allow-list.ignore-tablesコメントアウトします。

既存のデータ移行タスクにテーブルを追加する方法は?

実行中のデータ移行タスクにテーブルを追加する必要がある場合は、タスクの段階に応じて次の方法で対処できます。

ノート：

既存のデータ移行タスクへのテーブルの追加は複雑であるため、この操作は必要な場合にのみ実行することをお勧めします。

Dump段階で

MySQL はエクスポート用のスナップショットを指定できないため、エクスポート中にデータ移行タスクを更新し、チェックポイントを介してエクスポートを再開するために再起動することはサポートされていません。したがって、 Dump段階で移行する必要があるテーブルを動的に追加することはできません。

移行のためにテーブルを追加する必要がある場合は、新しい構成ファイルを使用して直接タスクを再開することをお勧めします。

Load段階で

エクスポート中、複数のデータ移行タスクは通常、binlogの位置が異なります。 Load段階でタスクをマージすると、binlogの位置について合意に達することができない場合があります。したがって、第Load段階でテーブルをデータ移行タスクに追加することはお勧めしません。

Sync段階で

データ移行タスクがSync段階の場合、構成ファイルにテーブルを追加してタスクを再開すると、DM は新しく追加されたテーブルに対して完全なエクスポートとインポートを再実行しません。代わりに、DM は前のチェックポイントから増分レプリケーションを続行します。

したがって、新しく追加されたテーブルの完全なデータがダウンストリームにインポートされていない場合は、別のデータ移行タスクを使用して、完全なデータをエクスポートしてダウンストリームにインポートする必要があります。

既存の移行タスクに対応するグローバル チェックポイント ( is_global=1 ) の位置情報をcheckpoint-T (mysql-bin.000100, 1234)など) に記録します。 (mysql-bin.000099, 5678)のようにcheckpoint-Sとして移行タスクに追加するテーブルのフル エクスポートmetedata (またはSync段階の別のデータ移行タスクのチェックポイント) の位置情報を記録します。次の手順でテーブルを移行タスクに追加できます。

  1. stop-taskを使用して、既存の移行タスクを停止します。追加するテーブルが実行中の別の移行タスクに属している場合は、そのタスクも停止します。

  2. MySQL クライアントを使用してダウンストリームの TiDB データベースに接続し、既存の移行タスクに対応するチェックポイント テーブルの情報をcheckpoint-T ～ checkpoint-Sの小さい値に手動で更新します。この例では、 (mysql- bin.000099, 5678)です。

    • 更新するチェックポイント テーブルは、スキーマ{dm_meta}の{task-name}_syncer_checkpointです。

    • 更新されるチェックポイント行はid=(source-id)とis_global=1に一致します。

    • 更新するチェックポイント列はbinlog_nameとbinlog_posです。

  3. タスクのsyncersにsafe-mode: trueを設定して、再入可能実行を保証します。

  4. start-taskを使用してタスクを開始します。

  5. query-statusからタスクのステータスを観察します。 syncerBinlogがcheckpoint-Tとcheckpoint-Sの大きい方の値を超えたら、 safe-mode元の値に戻してタスクを再開します。この例では、 (mysql-bin.000100, 1234)です。

packet for query is too large. Try adjusting the 'max_allowed_packet' variableフル インポート中に発生するpacket for query is too large. Try adjusting the 'max_allowed_packet' variable 。

以下のパラメーターをデフォルトの 67108864 (64M) より大きい値に設定します。

DM 1.0 クラスターの既存の DM 移行タスクが DM 2.0 以降のクラスターで実行されているときに発生するエラーError 1054: Unknown column 'binlog_gtid' in 'field list'処理方法を教えてください。

DM v2.0 以降、DM 1.0 クラスターのタスク構成ファイルでstart-taskコマンドを直接実行して増分データ レプリケーションを続行すると、エラーError 1054: Unknown column 'binlog_gtid' in 'field list'が発生します。

このエラーはDM 1.0 クラスターの DM 移行タスクを DM 2.0 クラスターに手動でインポートするで処理できます。

TiUP がDM の一部のバージョン (v2.0.0-hotfix など) の展開に失敗するのはなぜですか?

tiup list dm-masterコマンドを使用して、 TiUPがデプロイをサポートしている DM のバージョンを表示できます。 TiUP は、このコマンドで表示されない DM バージョンを管理しません。

エラーparse mydumper metadata error: EOF ?

このエラーをさらに分析するには、エラー メッセージとログ ファイルを確認する必要があります。原因として、権限がないためにダンプ ユニットが正しいメタデータ ファイルを生成しないことが考えられます。

シャードされたスキーマとテーブルをレプリケートするときに DM が致命的なエラーを報告しないのに、ダウンストリーム データが失われるのはなぜですか?

構成項目block-allow-listとtable-routeを確認します。

  • アップストリームのデータベースとテーブルの名前をblock-allow-listの下に構成する必要があります。 do-tablesの前に「~」を追加すると、正規表現を使用して名前を一致させることができます。
  • table-route正規表現の代わりにワイルドカード文字を使用してテーブル名を照合します。たとえば、 table_parttern_[0-63] table_parttern_0からtable_pattern_6までの 7 つのテーブルにのみ一致します。

DM がアップストリームからレプリケートしていない場合、 replicate lagモニター メトリックにデータが表示されないのはなぜですか?

DM 1.0 では、モニター データを生成するにはenable-heartbeatを有効にする必要があります。 DM 2.0 以降のバージョンでは、この機能がサポートされていないため、モニター メトリックreplicate lagにデータがないと予想されます。

DM がタスクを開始しているときにfail to initial unit Sync of subtask 、エラー メッセージのRawCauseがcontext deadline exceeded示すエラーを処理する方法は?

これは DM 2.0.0 バージョンの既知の問題であり、DM 2.0.1 バージョンで修正される予定です。レプリケーション タスクで処理するテーブルが多数ある場合にトリガーされる可能性があります。 TiUP を使用して DM をデプロイする場合は、DM をナイトリー バージョンにアップグレードして、この問題を解決できます。または、GitHub のDMのリリースページから 2.0.0-hotfix バージョンをダウンロードして、実行可能ファイルを手動で置き換えることができます。

DM がデータをレプリケートしているときにエラーduplicate entryを処理する方法は?

まず、次のことを確認して確認する必要があります。

  • disable-detectはレプリケーション タスクで構成されていません (v2.0.7 以前のバージョン)。
  • データは、手動または他の複製プログラムによって挿入されません。
  • このテーブルに関連付けられた DML フィルタは構成されていません。

トラブルシューティングを容易にするために、まず下流の TiDB インスタンスの一般的なログ ファイルを収集してから、 TiDB コミュニティ slack チャンネルでテクニカル サポートを依頼できます。次の例は、一般的なログ ファイルを収集する方法を示しています。

# Enable general log collection
curl -X POST -d "tidb_general_log=1" http://{TiDBIP}:10080/settings
# Disable general log collection
curl -X POST -d "tidb_general_log=0" http://{TiDBIP}:10080/settings

duplicate entryのエラーが発生した場合は、競合データを含むレコードのログ ファイルを確認する必要があります。

一部の監視パネルにNo data pointが表示されるのはなぜですか?

一部のパネルにデータがないのは正常です。たとえば、エラーが報告されていない場合、DDL ロックがない場合、またはリレー ログ機能が有効になっていない場合、対応するパネルにはNo data pointが表示されます。各パネルの詳細な説明については、 DM モニタリング指標を参照してください。

DM v1.0 で、タスクにエラーがある場合、コマンドsql-skip一部のステートメントをスキップできないのはなぜですか?

sql-skipを実行した後、binlogの位置がまだ進んでいるかどうかを最初に確認する必要があります。もしそうなら、それはsql-skip発効したことを意味します。このエラーが発生し続ける理由は、アップストリームが複数のサポートされていない DDL ステートメントを送信するためです。 sql-skip -s <sql-pattern>を使用して、これらのステートメントに一致するパターンを設定できます。

場合によっては、エラー メッセージに次のようなparse statement情報が含まれることがあります。

if the DDL is not needed, you can use a filter rule with \"*\" schema-pattern to ignore it.\n\t : parse statement: line 1 column 11 near \"EVENT `event_del_big_table` \r\nDISABLE\" %!!(MISSING)(EXTRA string=ALTER EVENT `event_del_big_table` \r\nDISABLE

このタイプのエラーの理由は、TiDB パーサーがアップストリームから送信された DDL ステートメント ( ALTER EVENTなど) を解析できないため、 sql-skip期待どおりに機能しないためです。構成ファイルにbinlogイベント フィルタを追加して、これらのステートメントをフィルタリングし、 schema-pattern: "*"を設定できます。 DM v2.0.1 以降、DM はEVENTに関連するステートメントを事前にフィルター処理します。

DM v6.0 以降、 binlog sql-skipとhandle-errorを置き換えます。この問題を回避するには、代わりにbinlogコマンドを使用できます。

DM がレプリケートしているときに、 REPLACEステートメントがダウンストリームに表示され続けるのはなぜですか?

タスクに対してセーフモードが自動的に有効になっているかどうかを確認する必要があります。エラー後にタスクが自動的に再開される場合、または高可用性スケジュールが設定されている場合は、タスクの開始または再開後 1 分以内であるため、セーフ モードが有効になります。

DM-worker ログ ファイルを確認して、 change countを含む行を検索できます。行のnew countゼロでない場合、セーフ モードが有効になっています。有効になっている理由を確認するには、いつ発生するか、以前にエラーが報告されていないかどうかを確認してください。

DM v2.0 で、タスク中に DM が再起動すると、完全インポート タスクが失敗するのはなぜですか?

DM v2.0.1 以前のバージョンでは、フル インポートが完了する前に DM が再起動すると、アップストリーム データ ソースと DM-worker ノード間のバインディングが変更される可能性があります。たとえば、ダンプ ユニットの中間データは DM-worker ノード A にありますが、ロード ユニットは DM-worker ノード B によって実行され、操作が失敗する可能性があります。

この問題の解決策は次の 2 つです。

  • データ ボリュームが小さい (1 TB 未満) か、タスクがシャード テーブルをマージする場合は、次の手順を実行します。

    1. ダウンストリーム データベースでインポートされたデータをクリーンアップします。
    2. エクスポートされたデータのディレクトリ内のすべてのファイルを削除します。
    3. dmctl を使用してタスクを削除し、コマンドstart-task --remove-metaを実行して新しいタスクを作成します。

    新しいタスクが開始されたら、冗長な DM ワーカー ノードがないことを確認し、フル インポート中に DM クラスターを再起動またはアップグレードしないようにすることをお勧めします。

  • データ ボリュームが大きい (1 TB を超える) 場合は、次の手順を実行します。

    1. ダウンストリーム データベースでインポートされたデータをクリーンアップします。
    2. データを処理する DM ワーカー ノードに TiDB-Lightningをデプロイ。
    3. DM ダンプ ユニットがエクスポートするデータをインポートするには、TiDB-Lightning のローカル バックエンド モードを使用します。
    4. フル インポートが完了したら、次の方法でタスク構成ファイルを編集し、タスクを再起動します。
      • task-modeをincrementalに変更します。
      • ダンプ ユニットが出力するメタデータ ファイルに記録されている位置に値mysql-instance.meta.posを設定します。

DM ERROR 1236 (HY000): 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.増分タスク中に再起動する場合は?

このエラーは、ダンプ ユニットによって出力されたメタデータ ファイルに記録された上流のbinlogの位置が、完全な移行中に削除されたことを示します。

この問題が発生した場合は、タスクを一時停止し、ダウンストリーム データベース内のすべての移行済みデータを削除して、オプション--remove-metaで新しいタスクを開始する必要があります。

次の方法で構成することにより、この問題を事前に回避できます。

  1. アップストリームの MySQL データベースの値をexpire_logs_days増やして、完全な移行タスクが完了する前に必要なbinlogファイルを誤って削除しないようにします。データ量が多い場合は、dumpling と TiDB-Lightning を同時に使用してタスクを高速化することをお勧めします。
  2. このタスクのリレー ログ機能を有効にして、 binlog の位置が削除されても DM がリレー ログからデータを読み取れるようにします。

クラスターがTiUP v1.3.0 または v1.3.1 を使用してデプロイされている場合、DM クラスター表示の Grafana ダッシュボードfailed to fetch dashboardなぜですか?

これはTiUPの既知のバグで、 TiUP v1.3.2 で修正されています。この問題の解決策は次の 2 つです。

  • 解決策 1:
    1. コマンドtiup update --self && tiup update dmを使用して、 TiUP を新しいバージョンにアップグレードします。
    2. クラスター内の Grafana ノードをスケールインからスケール アウトし、Grafana サービスを再起動します。
  • 解決策 2:
    1. deploy/grafana-$port/bin/publicフォルダをバックアップします。
    2. TiUP DMオフライン パッケージをダウンロードして解凍します。
    3. オフライン パッケージのgrafana-v4.0.3-**.tar.gzを解凍します。
    4. フォルダdeploy/grafana-$port/bin/public grafana-v4.0.3-**.tar.gzのpublicフォルダに置き換えます。
    5. tiup dm restart $cluster_name -R grafanaを実行して Grafana サービスを再起動します。

DM v2.0 で、コマンドquery-statusのクエリ結果が、タスクでenable-relayとenable-gtidが同時に有効になっている場合、Syncer チェックポイント GTID が不連続であることを示すのはなぜですか?

これは DM の既知のバグで、DM v2.0.2 で修正されています。このバグは、次の 2 つの条件が同時に完全に満たされた場合に発生します。

  1. パラメータenable-relayとenable-gtidは、ソース構成ファイルでtrueに設定されています。
  2. アップストリーム データベースはMySQL セカンダリ データベースです。コマンドshow binlog events in '<newest-binlog>' limit 2を実行してデータベースのprevious_gtidsを照会すると、次の例のように結果が不連続になります。
mysql> show binlog events in 'mysql-bin.000005' limit 2;
+------------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name         | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
+------------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| mysql-bin.000005 |    4 | Format_desc    |    123452 |         123 | Server ver: 5.7.32-35-log, Binlog ver: 4                           |
| mysql-bin.000005 |  123 | Previous_gtids |    123452 |         194 | d3618e68-6052-11eb-a68b-0242ac110002:6-7                           |
+------------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+

このバグは、dmctl でquery-status <task>実行してタスク情報を照会し、 subTaskStatus.sync.syncerBinlogGtidは不連続であるがsubTaskStatus.sync.masterBinlogGtidは連続していることが判明した場合に発生します。次の例を参照してください。

query-status test
{
    ...
    "sources": [
        {
            ...
            "sourceStatus": {
                "source": "mysql1",
                ...
                "relayStatus": {
                    "masterBinlog": "(mysql-bin.000006, 744)",
                    "masterBinlogGtid": "f8004e25-6067-11eb-9fa3-0242ac110003:1-50",
                    ...
                }
            },
            "subTaskStatus": [
                {
                    ...
                    "sync": {
                        ...
                        "masterBinlog": "(mysql-bin.000006, 744)",
                        "masterBinlogGtid": "f8004e25-6067-11eb-9fa3-0242ac110003:1-50",
                        "syncerBinlog": "(mysql-bin|000001.000006, 738)",
                        "syncerBinlogGtid": "f8004e25-6067-11eb-9fa3-0242ac110003:1-20:40-49",
                        ...
                        "synced": false,
                        "binlogType": "local"
                    }
                }
            ]
        },
        {
            ...
            "sourceStatus": {
                "source": "mysql2",
                ...
                "relayStatus": {
                    "masterBinlog": "(mysql-bin.000007, 1979)",
                    "masterBinlogGtid": "ddb8974e-6064-11eb-8357-0242ac110002:1-25",
                    ...
                }
            },
            "subTaskStatus": [
                {
                    ...
                    "sync": {
                        "masterBinlog": "(mysql-bin.000007, 1979)",
                        "masterBinlogGtid": "ddb8974e-6064-11eb-8357-0242ac110002:1-25",
                        "syncerBinlog": "(mysql-bin|000001.000008, 1979)",
                        "syncerBinlogGtid": "ddb8974e-6064-11eb-8357-0242ac110002:1-25",
                        ...
                        "synced": true,
                        "binlogType": "local"
                    }
                }
            ]
        }
    ]
}

この例では、データ ソースmysql1のsyncerBinlogGtid連続していません。この場合、次のいずれかを実行してデータ損失を処理できます。

  • 現時点からフル エクスポート タスクのメタデータに記録された位置までのアップストリーム バイナリログがパージされていない場合は、次の手順を実行できます。
    1. 現在のタスクを停止し、連続していない GTID を持つすべてのデータ ソースを削除します。
    2. すべてのソース構成ファイルでenable-relay ～ falseを設定します。
    3. 連続していない GTID (上記の例のmysql1など) を持つデータ ソースの場合、タスクを増分タスクに変更し、関連するmysql-instances.metaを、 binlog-name 、 binlog-pos 、およびbinlog-gtidの情報を含む各フル エクスポート タスクのメタデータ情報で構成します。
    4. 増分タスクのtask.yamlでsyncers.safe-mode ～ trueを設定し、タスクを再起動します。
    5. 増分タスクが不足しているすべてのデータをダウンストリームに複製したら、タスクを停止し、 task.yamlのsafe-modeをfalseに変更します。
    6. タスクを再始動してください。
  • アップストリーム バイナリログが削除されたが、ローカル リレー ログが残っている場合は、次の手順を実行できます。
    1. 現在のタスクを停止します。
    2. 連続していない GTID (上記の例のmysql1など) を持つデータ ソースの場合、タスクを増分タスクに変更し、関連するmysql-instances.metaを、 binlog-name 、 binlog-pos 、およびbinlog-gtidの情報を含む各フル エクスポート タスクのメタデータ情報で構成します。
    3. 増分タスクのtask.yamlで、前の値binlog-gtidを前の値previous_gtidsに変更します。上記の例では、 1-yを6-yに変更します。
    4. task.yamlにsyncers.safe-mode ～ trueを設定し、タスクを再起動します。
    5. 増分タスクが不足しているすべてのデータをダウンストリームに複製したら、タスクを停止し、 task.yamlのsafe-modeをfalseに変更します。
    6. タスクを再始動してください。
    7. データ ソースを再起動し、ソース構成ファイルでenable-relayまたはenable-gtid ～ falseを設定します。
  • 上記の条件のいずれも満たされていない場合、またはタスクのデータ量が少ない場合は、次の手順を実行できます。
    1. ダウンストリーム データベースでインポートされたデータをクリーンアップします。
    2. データ ソースを再起動し、ソース構成ファイルでenable-relayまたはenable-gtid ～ falseを設定します。
    3. 新しいタスクを作成し、コマンドstart-task task.yaml --remove-metaを実行して、最初からデータを移行します。

上記の 1 番目と 2 番目のソリューションで正常に複製できるデータ ソース (上記の例のmysql2など) については、増分タスクを設定するときに、関連するmysql-instances.meta subTaskStatus.syncのsyncerBinlogとsyncerBinlogGtid情報で構成します。

DM v2.0 で、ハートビートheartbeatが以前に使用されたものと異なります: サーバー ID が等しくありません」というエラーを処理するにはどうすればよいですか?

heartbeat機能は、DM v2.0 以降のバージョンではデフォルトで無効になっています。タスク構成ファイルでこの機能を有効にすると、高可用性機能が妨げられます。この問題を解決するには、タスク構成ファイルでenable-heartbeatからfalseを設定してheartbeat機能を無効にしてから、タスク構成ファイルをリロードします。 DM は、以降のリリースでheartbeat機能を強制的に無効にします。

DM マスターが再起動後にクラスターに参加できず、DM が「埋め込み etcd の開始に失敗しました。RawCause: メンバー xxx は既にブートストラップされています」というエラーを報告するのはなぜですか?

DM-master が起動すると、DM は現在のディレクトリに etcd 情報を記録します。 DM マスターの再始動後にディレクトリーが変更された場合、DM は etcd 情報にアクセスできないため、再始動は失敗します。

この問題を解決するには、 TiUPを使用して DM クラスターを維持することをお勧めします。バイナリ ファイルを使用して展開する必要がある場合は、DM マスターの構成ファイルで絶対パスを使用してdata-dirを構成するか、コマンドを実行する現在のディレクトリに注意する必要があります。

dmctl を使用してコマンドを実行すると、DM マスターに接続できないのはなぜですか?

dmctl execute コマンドを使用すると、(コマンドでパラメーター値--master-addr指定した場合でも) DM マスターへの接続が失敗し、エラー メッセージがRawCause: context deadline exceeded, Workaround: please check your network connection.のようになる場合があります。ただし、 telnet <master-addr>などのコマンドを使用してネットワーク接続を確認した後、例外は見つかりません。

この場合、環境変数https_proxyを確認できます (これはhttpsであることに注意してください)。この変数が構成されている場合、dmctl はhttps_proxyで指定されたホストとポートに自動的に接続します。ホストに対応するproxy転送サービスがない場合、接続は失敗します。

この問題を解決するには、 https_proxyが必須かどうかを確認してください。そうでない場合は、設定をキャンセルしてください。それ以外の場合は、元の dmctl コマンドの前に環境変数設定https_proxy="" ./dmctl --master-addr "x.x.x.x:8261"を追加します。

ノート：

proxyに関連する環境変数には、 http_proxy 、 https_proxy 、およびno_proxyが含まれます。上記の手順を実行しても接続エラーが続く場合は、構成パラメーターhttp_proxyとno_proxyが正しいかどうかを確認してください。

DM バージョン 2.0.2 から 2.0.6 で start-relay コマンドを実行したときに返されたエラーを処理するにはどうすればよいですか?

flush local meta, Rawcause: open relay-dir/xxx.000001/relay.metayyyy: no such file or directory

上記のエラーは、次の場合に発生する可能性があります。

  • DM は v2.0.1 以前から v2.0.2 ～ v2.0.6 にアップグレードされ、リレー ログはアップグレード前に開始され、アップグレード後に再開されます。
  • stop-relay コマンドを実行して、リレー ログを一時停止してから再開します。

このエラーは、次のオプションで回避できます。

  • リレー ログを再開します。

    » stop-relay -s sourceID workerName
» start-relay -s sourceID workerName

  • DM を v2.0.7 以降のバージョンにアップグレードします。

ロード ユニットがUnknown character setエラーを報告するのはなぜですか?

TiDB はすべての MySQL 文字セットをサポートしているわけではありません。したがって、フル インポート中にテーブル スキーマを作成するときに、サポートされていない文字セットが使用されている場合、DM はこのエラーを報告します。このエラーを回避するには、特定のデータに従ってTiDB がサポートする文字セットを使用して、事前にダウンストリームでテーブル スキーマを作成できます。

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