重要

古いバージョンの TiDB データベース (TiDB {{ curdocVersion }}) のドキュメントを表示しています。TiDBデータベースの最新の安定バージョンを使用することをお勧めします。

重要

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

TiDBデータ移行FAQ

このドキュメントは、TiDBデータ移行（DM）に関するよくある質問（FAQ）を集めたものです。

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

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

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

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

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

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

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

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

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

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

TiDBでサポートされていないDDLステートメントに遭遇した場合は、dmctlを使用して手動で処理する必要があります（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つの方法のいずれかで取得されます。

alter ghost_table操作中にgh-ostテーブルを処理しますおよびghost_tableのDDL情報を記録します。
DM-workerを再起動してタスクを開始すると、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の構成を削除します。
_{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`段階で

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

`Sync`段階

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

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

既存の移行タスクに対応するグローバルチェックポイント（ is_global=1 ）の位置情報を(mysql-bin.000100, 1234)などのcheckpoint-Tとして記録します。移行タスクに追加するテーブルの完全エクスポート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`完全なインポート中に発生`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 / コンフィグレーションファイルをご覧ください。

エラー1054の処理方法：DM1.0クラスタの既存のDM移行タスクがDM2.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'が発生します。

このエラーはDM1.0クラスタのDM移行タスクをDM2.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`たことを示していますか？

これはDM2.0.0バージョンの既知の問題であり、DM2.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パーサーがALTER EVENTなどのアップストリームによって送信されたDDLステートメントを解析できないため、 sql-skipが期待どおりに有効にならないためです。構成ファイルにbinlogイベントフィルターを追加して、これらのステートメントをフィルター処理し、 schema-pattern: "*"を設定できます。 DM v2.0.1以降、DMはEVENTに関連するステートメントを事前にフィルタリングします。

DM v2.0以降、 handle-errorがsql-skipに置き換わります。この問題を回避するには、代わりにhandle-errorを使用できます。

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

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

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

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

DM v2.0.1以前のバージョンでは、完全なインポートが完了する前にDMが再起動すると、アップストリームデータソースとDMワーカーノード間のバインディングが変更される可能性があります。たとえば、ダンプユニットの中間データが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. 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オプションで新しいタスクを開始する必要があります。

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

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

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

これはTiUPの既知のバグであり、TiUPv1.3.2で修正されています。この問題に対する2つの解決策は次のとおりです。

解決策1：
1. コマンドtiup update --self && tiup update dmを使用して、TiUPを新しいバージョンにアップグレードします。
2. クラスタのGrafanaノードをスケールインしてからスケールアウトし、Grafanaサービスを再起動します。
解決策2：
1. deploy/grafana-$port/bin/publicのフォルダをバックアップします。
2. TiUPDMオフラインパッケージをダウンロードして解凍します。
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の既知のバグであり、DMv2.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は連続していません。この場合、データ損失を処理するために次のいずれかを実行できます。

現在の時刻から完全エクスポートタスクのメタデータに記録されている位置までのアップストリームbinlogがパージされていない場合は、次の手順を実行できます。
1. 現在のタスクを停止し、GTIDが連続していないすべてのデータソースを削除します。
2. すべてのソース構成ファイルでenable-relayからfalseに設定します。
3. GTIDが連続していないデータソース（上記の例のmysql1など）の場合、タスクをインクリメンタルタスクに変更し、 binlog-name 、およびbinlog-posの情報を含む各完全エクスポートタスクのメタデータ情報を使用して関連するmysql-instances.metaを構成しbinlog-gtid 。
4. インクリメンタルタスクのtask.yaml分のsyncers.safe-modeをtrueに設定し、タスクを再開します。
5. インクリメンタルタスクが欠落しているすべてのデータをダウンストリームに複製した後、タスクを停止し、 task.yamlのsafe-modeをfalseに変更します。
6. タスクを再開します。
アップストリームbinlogがパージされたが、ローカルリレーログが残っている場合は、次の手順を実行できます。
1. 現在のタスクを停止します。
2. GTIDが連続していないデータソース（上記の例のmysql1など）の場合、タスクをインクリメンタルタスクに変更し、 binlog-name 、およびbinlog-posの情報を含む各完全エクスポートタスクのメタデータ情報を使用して関連するmysql-instances.metaを構成し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ワーカーと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の構成パラメーターが正しいかどうかを確認してください。

2.0.2から2.0.6までのDMバージョンで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以降のバージョンにアップグレードします。

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

Playground

新規

登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。

TiDBデータ移行FAQ

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 。

エラー1054の処理方法：DM1.0クラスタの既存のDM移行タスクがDM2.0以降のクラスタで実行されているときに発生するError 1054: Unknown column 'binlog_gtid' in 'field list' ？