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

このドキュメントでは、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でサポートされている正規表現については、 re2構文参照してください。

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

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

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

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

注記：
現在、TiDBはMySQLがサポートするすべてのDDL文と互換性がありません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のオンライン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までタスクの状態を観察します。3 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 バージョンを表示できます。このコマンドで表示されない DM バージョンはTiUPでは管理されません。

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

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

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

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

block-allow-list下にある上流のデータベースとテーブルの名前を設定する必要があります。3 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 文を送信しているためです。5 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 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 execute コマンドを使用すると、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データ移行に関するよくある質問

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 が連続していないと表示されるのはなぜですか?