重要

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

TiDB データ移行に関する FAQ

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

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

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

Alibaba Cloud RDS の主キーのないアップストリームテーブルの場合、そのbinlogに非表示の主キー列が含まれたままになり、元のテーブル構造と一致しないという既知の問題があります。

互換性に関する既知の問題は次のとおりです。

Alibaba Cloud RDSでは、主キーのないアップストリームテーブルの場合、そのbinlogには非表示の主キー列がまだ含まれており、元のテーブル構造と一致していません。
HUAWEI Cloud RDSでは、 binlogファイルを直接読み取ることはできません。詳細については、 HUAWEI Cloud RDS はBinlogバックアップファイルを直接読み取ることができますか?を参照してください。

タスク構成のブロックリストと許可リストの正規表現は`non-capturing (?!)` ?

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

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

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

互換性のない DDL ステートメントをどのように処理しますか?

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

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

現在、DM はビュー関連の DDL ステートメントをダウンストリーム TiDB クラスターに複製しません。また、ビュー関連の DML ステートメントをダウンストリーム TiDB クラスターに複製しません。

データ移行タスクをリセットするにはどうすればよいですか?

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

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

`online-ddl: true`を設定した後、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/tiflow/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 ワーカーが再起動されてタスクが開始されると、DM はdm_meta.{task_name}_onlineddlから DDL を読み取ります。

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

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

タスクのonline-ddl-schemeまたはonline-ddl構成を削除します。
block-allow-list.ignore-tablesの_{table_name}_gho _{table_name}_ghc設定し_{table_name}_del 。
ダウンストリーム TiDB でアップストリーム DDL を手動で実行します。
gh-ost プロセス後に Pos が位置に複製されたら、 online-ddl-schemeまたはonline-ddl構成を再度有効にして、 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) ）として記録します。次の手順でテーブルを移行タスクに追加できます。

既存の移行タスクを停止するには、 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` ?

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

TiDBサーバーのグローバル変数: max_allowed_packet 。
タスク設定ファイル内の設定項目： target-database.max-allowed-packet 。詳細についてはDM 高度なタスクコンフィグレーションファイルを参照してください。

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 がタスクを開始しているときに、 `context deadline exceeded`を示すエラーメッセージの`RawCause`で`fail to initial unit Sync of subtask`エラーをどのように処理しますか?

これは 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 パーサーがアップストリームから送信されたALTER EVENTなどの DDL ステートメントを解析できないため、 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が 0 でない場合、セーフモードが有効になっています。セーフモードが有効になっている理由を確認するには、セーフモードがいつ発生するか、以前にエラーが報告されているかどうかを確認します。

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. 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オプションを使用して新しいタスクを開始する必要があります。

次の方法で設定することで、この問題を事前に回避できます。

完全な移行タスクが完了する前に、必要なbinlogファイルが誤って消去されるのを防ぐため、アップストリーム MySQL データベースの値をexpire_logs_days増やします。データ量が多い場合は、タスクを高速化するために 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 では、タスクで`enable-relay`と`enable-gtid`が同時に有効になっている場合、コマンド`query-status`のクエリ結果に、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など) の場合は、タスクを増分タスクに変更し、 binlog-name 、 binlog-pos 、およびbinlog-gtid情報を含む各完全エクスポートタスクのメタデータ情報を使用して関連するmysql-instances.metaを構成します。
4. 増分タスクのtask.yamlにsyncers.safe-mode true設定し、タスクを再起動します。
5. 増分タスクがすべての欠落データをダウンストリームに複製した後、タスクを停止し、 task.yamlのsafe-modeをfalseに変更します。
6. タスクをもう一度再開します。
アップストリームのバイナリログが消去されたが、ローカルリレーログが残っている場合は、次の手順を実行できます。
1. 現在のタスクを停止します。
2. 連続していない GTID を持つデータソース (上記の例のmysql1など) の場合は、タスクを増分タスクに変更し、 binlog-name 、 binlog-pos 、およびbinlog-gtid情報を含む各完全エクスポートタスクのメタデータ情報を使用して関連するmysql-instances.metaを構成します。
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など) の場合は、増分タスクを設定するときに、 subTaskStatus.syncのsyncerBinlogとsyncerBinlogGtid情報を使用して関連するmysql-instances.meta構成します。

DM v2.0 では、 `heartbeat`機能が有効になっている仮想 IP 環境で DM ワーカーと MySQL インスタンス間の接続を切り替えるときに、「ハートビート設定が以前に使用されたものと異なります: serverID が等しくありません」というエラーをどのように処理すればよいですか?

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

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

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

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

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

dmctl 実行コマンドを使用すると、DM マスターへの接続が失敗し (コマンドでパラメータ値--master-addrを指定した場合でも)、エラーメッセージが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 でサポートされている文字セット使用してダウンストリームで事前にテーブルスキーマを作成します。

TiDB データ移行に関する FAQ

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

タスク構成のブロック リストと許可リストの正規表現はnon-capturing (?!) ?

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

互換性のない DDL ステートメントをどのように処理しますか?

DM はビュー関連の DDL ステートメントと DML ステートメントを TiDB に複製しますか?

データ移行タスクをリセットするにはどうすればよいですか?

online-ddl: trueを設定した後、gh-ost テーブルに関連する DDL 操作によって返されたエラーをどのように処理しますか?

既存のデータ移行タスクにテーブルを追加するにはどうすればよいですか?

Dump段階

Loadステージ

Sync段階

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) の展開に失敗するのはなぜですか?

DM がデータを複製しているときに発生するエラーparse mydumper metadata error: EOF 」をどのように処理すればよいですか?

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

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

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

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 では、タスクでenable-relayとenable-gtidが同時に有効になっている場合、コマンドquery-statusのクエリ結果に、Syncer チェックポイント GTID が連続していないと表示されるのはなぜですか?