TiDB Cloud
TiDB
Playground
お問い合わせ

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

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

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

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

Alibaba Cloud RDS の主キーのない上流テーブルの場合、そのbinlogに非表示の主キー列が依然として含まれており、元のテーブル構造と矛盾していることが既知の問題です。

互換性のない既知の問題をいくつか次に示します。

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

現在、DM はこれをサポートしておらず、 Golang標準ライブラリの正規表現のみをサポートしています。 Golangでサポートされている正規表現については、 re2 構文参照してください。

上流で実行されるステートメントに複数の 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}_ghc 、および_{table_name}_delを構成します。

  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)として記録します。移行タスクに追加するテーブルの完全エクスポートmetedata (またはSync段階の別のデータ移行タスクのチェックポイント) の位置情報をcheckpoint-S 、たとえば(mysql-bin.000099, 5678)として記録します。次の手順でテーブルを移行タスクに追加できます。

  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 バージョンを管理しません。

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 コミュニティのスラック チャンネルでテクニカル サポートを依頼できます。次の例は、一般的なログ ファイルを収集する方法を示しています。

# 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 以降、 sql-skipとhandle-errorはbinlogに置き換えられます。この問題を回避するには、代わりにbinlogコマンドを使用します。

DM の複製中にREPLACEステートメントがダウンストリームに出現し続けるのはなぜですか?

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

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

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

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

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

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

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

    新しいタスクの開始後は、冗長な DM ワーカー ノードがないことを確認し、完全インポート中に DM クラスターの再起動やアップグレードを避けることをお勧めします。

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

    1. ダウンストリーム データベース内のインポートされたデータをクリーンアップします。
    2. データを処理する DM ワーカー ノードに TiDB-Lightningをデプロイ。
    3. TiDB-Lightning のローカル バックエンド モードを使用して、DM ダンプ ユニットがエクスポートするデータをインポートします。
    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. 完全な移行タスクが完了する前に、必要なbinlogファイルが誤ってパージされるのを避けるために、アップストリームの MySQL データベースの値expire_logs_days増やします。データ量が大きい場合は、ダンプリングと 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. grafana-v4.0.3-**.tar.gzのフォルダーdeploy/grafana-$port/bin/public publicフォルダーに置き換えます。
    5. tiup dm restart $cluster_name -R grafanaを実行して Grafana サービスを再起動します。

DM v2.0 では、タスクでenable-relayとenable-gtidが同時に有効になっている場合、 query-statusコマンドのクエリ結果で 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. タスクを再度再開します。
  • アップストリームの binlog がパージされても、ローカル リレー ログが残っている場合は、次の手順を実行できます。
    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 では、ハートビート機能が有効になっている仮想 IP 環境で DM ワーカーと MySQL インスタンスの間の接続を切り替えるときに、「ハートビートheartbeatが以前使用されていたものと異なります: サーバー ID が等しくない」というエラーをどのように処理すればよいですか?

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

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

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

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

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

dmctl 実行コマンドを使用すると、(コマンドでパラメータ値--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 がサポートする文字セット使用してダウンストリームにテーブル スキーマを事前に作成します。

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

Playground
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Dedicated
TiDB Serverless
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
リソース
よくあるご質問
開発者ガイド
ニュース&ブログ
Education
導入実績
サポート
Discord
Forum
Slack
Support Portal
会社関連
会社概要
キャリア
規約類
お問い合わせ
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.