重要

現在表示されているページは、TiDBのアーカイブされたドキュメント (非更新) です。TiDBをご利用の場合、最新のLTS (Long Term Support) バージョンの使用を推奨します。

重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

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

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

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

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

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

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

Alibaba Cloud RDSでは、主キーのないアップストリームテーブルのバイナリログには、元のテーブル構造と矛盾する非表示の主キー列が含まれています。
HUAWEI Cloud RDSでは、binlog ファイルの直接読み取りはサポートされていません。詳細については、 HUAWEI 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 の互換性を参照してください。

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

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

stop-taskコマンドを実行して、異常なデータ移行タスクを停止します。
ダウンストリームに移行されたデータをパージします。
次のいずれかの方法を使用して、データ移行タスクを再開します。
- タスク構成ファイルで新しいタスク名を指定します。次にstart-task {task-config-file}を実行します。
- start-task --remove-meta {task-config-file}を実行します。

`online-ddl-scheme: "gh-ost"`が設定された後、gh-ost テーブルに関連する DDL 操作によって返されるエラーを処理する方法は?

[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 つの方法のいずれかで取得されます。

DM alter ghost_table操作中に gh-ost テーブルを処理しますおよびghost_tableの DDL 情報を記録します。
DM-worker を再起動してタスクを開始すると、DM は DDL をdm_meta.{task_name}_onlineddlから読み取ります。

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

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

タスクのonline-ddl-schemeの構成を削除します。
_{table_name}_del _{table_name}_gho _{table_name}_ghcしblock-allow-list.ignore-tables 。
ダウンストリーム TiDB でアップストリーム DDL を手動で実行します。
Pos が gh-ost プロセス後の位置に複製されたら、 online-ddl-schemeを再度有効にしてblock-allow-list.ignore-tablesをコメントアウトします。

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

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

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

`Dump`段階で

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

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

`Load`段階で

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

`Sync`段階で

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

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

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

stop-taskを使用して、既存の移行タスクを停止します。追加するテーブルが実行中の別の移行タスクに属している場合は、そのタスクも停止します。
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です。
タスクのsyncersにsafe-mode: trueを設定して、再入可能実行を保証します。
start-taskを使用してタスクを開始します。
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) より大きい値に設定します。

TiDBサーバーのグローバル変数: max_allowed_packet 。
タスク構成ファイル内の構成項目: target-database.max-allowed-packet .詳細はDM 拡張タスクConfiguration / コンフィグレーションファイルを参照してください。

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を実行した後、バイナリログの位置がまだ進んでいるかどうかを最初に確認する必要があります。もしそうなら、それは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.`増分タスク中に再起動する場合は?

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

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

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

アップストリームの MySQL データベースの値をexpire_logs_daysに増やして、完全な移行タスクが完了する前に必要な binlog ファイルを誤って削除しないようにします。データ量が多い場合は、dumpling と TiDB-Lightning を同時に使用してタスクを高速化することをお勧めします。
このタスクのリレーログ機能を有効にして、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 つの条件が同時に完全に満たされた場合に発生します。

パラメータenable-relayとenable-gtidは、ソース構成ファイルでtrueに設定されています。
アップストリームデータベースは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`機能が有効になっている仮想 IP 環境で DM-worker と MySQL インスタンス間の接続を切り替えるときに、「ハートビート構成が以前に使用されたものと異なります: サーバー 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 以降のバージョンにアップグレードします。

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

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

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

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

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

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

online-ddl-scheme: "gh-ost"が設定された後、gh-ost テーブルに関連する DDL 操作によって返されるエラーを処理する方法は?

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

Dump段階で

Load段階で

Sync段階で

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 。

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

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

エラーparse mydumper metadata error: EOF ?

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

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

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

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

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

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

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

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

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.増分タスク中に再起動する場合は?

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

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