移行に関するよくある質問

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

移行関連のツールに関するよくある質問については、以下のリストにある対応するリンクをクリックしてください。

• バックアップと復元FAQ
• TiDB Binlog FAQ
• TiDB LightningFAQ
• TiDBデータ移行（DM）に関するFAQ
• TiCDCのトラブルシューティング

完全なデータのエクスポートとインポート

MySQLで実行されているアプリケーションをTiDBに移行するにはどうすればよいですか？

TiDBはほとんどのMySQL構文をサポートしているため、通常、ほとんどの場合、コードを1行も変更せずにアプリケーションをTiDBに移行できます。

データのインポートとエクスポートは遅く、多くの再試行とEOFエラーが他のエラーなしで各コンポーネントのログに表示されます

他の論理エラーが発生しない場合は、ネットワークの問題が原因で再試行とEOFエラーが発生している可能性があります。最初にツールを使用してネットワーク接続を確認することをお勧めします。次の例では、トラブルシューティングにiperfが使用されています。

• 再試行とEOFエラーが発生するサーバー側ノードで次のコマンドを実行します。

  iperf3 -s
  

• 再試行とEOFエラーが発生するクライアント側ノードで次のコマンドを実行します。

  iperf3 -c <server-IP>
  

次の例は、ネットワーク接続が良好なクライアントノードの出力です。

$ iperf3 -c 192.168.196.58
Connecting to host 192.168.196.58, port 5201
[  5] local 192.168.196.150 port 55397 connected to 192.168.196.58 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  18.0 MBytes   150 Mbits/sec
[  5]   1.00-2.00   sec  20.8 MBytes   175 Mbits/sec
[  5]   2.00-3.00   sec  18.2 MBytes   153 Mbits/sec
[  5]   3.00-4.00   sec  22.5 MBytes   188 Mbits/sec
[  5]   4.00-5.00   sec  22.4 MBytes   188 Mbits/sec
[  5]   5.00-6.00   sec  22.8 MBytes   191 Mbits/sec
[  5]   6.00-7.00   sec  20.8 MBytes   174 Mbits/sec
[  5]   7.00-8.00   sec  20.1 MBytes   168 Mbits/sec
[  5]   8.00-9.00   sec  20.8 MBytes   175 Mbits/sec
[  5]   9.00-10.00  sec  21.8 MBytes   183 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec   208 MBytes   175 Mbits/sec                  sender
[  5]   0.00-10.00  sec   208 MBytes   174 Mbits/sec                  receiver

iperf Done.

出力に低いネットワーク帯域幅と高い帯域幅変動が示されている場合、各コンポーネントログに多数の再試行とEOFエラーが表示される可能性があります。この場合、ネットワーク品質を向上させるためにネットワークサービスプロバイダーに相談する必要があります。

各メトリックの出力が良好に見える場合は、各コンポーネントを更新してみてください。更新後も問題が解決しない場合は、 お問い合わせを実行できます。

誤ってMySQLユーザーテーブルをTiDBにインポートした場合、またはパスワードを忘れてログインできない場合、どのように対処しますか？

TiDBサービスを再起動し、構成ファイルに-skip-grant-table=trueつのパラメーターを追加します。パスワードなしでクラスタにログインしてユーザーを再作成するか、 mysql.userのテーブルを再作成します。特定のテーブルスキーマについては、公式ドキュメントを検索してください。

TiDBにデータをエクスポートする方法は？

次の方法を使用して、TiDBにデータをエクスポートできます。

• 中国語のMySQLはmysqldumpを使用してテーブルデータの一部をエクスポートしますを参照し、mysqldumpとWHERE句を使用してデータをエクスポートします。
• MySQLクライアントを使用して、 selectの結果をファイルにエクスポートします。

DB2またはOracleからTiDBに移行する方法は？

すべてのデータを移行するか、DB2またはOracleからTiDBに段階的に移行するには、次の解決策を参照してください。

• OGG、Gateway、CDC（Change Data Capture）などのOracleの公式移行ツールを使用します。
• データをインポートおよびエクスポートするためのプログラムを開発します。
• スプールをテキストファイルとしてエクスポートし、Loadinfileを使用してデータをインポートします。
• サードパーティのデータ移行ツールを使用します。

現在、OGGの使用をお勧めします。

エラー： java.sql.BatchUpdateExecption:statement count 5001 exceeds the transaction limitation Sqoopを使用してデータをbatchesでTiDBに書き込むときに、トランザクション制限を超えています

Sqoopでは、 --batchは各バッチで100個のstatementをコミットすることを意味しますが、デフォルトでは、各statementに100個のSQLステートメントが含まれています。したがって、100 * 100 = 10000 SQLステートメント。これは、単一のTiDBトランザクションで許可されるステートメントの最大数である5000を超えます。

2つの解決策：

• 次のように-Dsqoop.export.records.per.statement=10のオプションを追加します。

  sqoop export \
      -Dsqoop.export.records.per.statement=10 \
      --connect jdbc:mysql://mysql.example.com/sqoop \
      --username sqoop ${user} \
      --password ${passwd} \
      --table ${tab_name} \
      --export-dir ${dir} \
      --batch
  

• 1つのTiDBトランザクションで制限された数のステートメントを増やすこともできますが、これにより多くのメモリが消費されます。

Dumpling The local disk space is insufficientはなぜですか、またはテーブルをエクスポートするときにアップストリームデータベースのメモリが不足する原因になりますか？

この問題には、次の原因が考えられます。

• データベースの主キーが均等に分散されていません（たとえば、 SHARD_ROW_ID_BITSを有効にした場合）。
• アップストリームデータベースはTiDBであり、エクスポートされたテーブルはパーティションテーブルです。

上記の場合、 Dumplingはエクスポート用に非常に大きなデータチャンクを分割し、非常に大きな結果を持つクエリを送信します。この問題に対処するには、 お問い合わせナイトリーバージョンのDumplingを入手します。

TiDBにはOracleのフラッシュバッククエリのような機能がありますか？ DDLをサポートしていますか？

はい、そうです。また、DDLもサポートしています。詳細については、 TiDBが履歴バージョンからデータを読み取る方法を参照してください。

データをオンラインで移行する

TiDBからHBaseやElasticsearchなどの他のデータベースにデータを複製するための現在のソリューションはありますか？

いいえ。現在、データレプリケーションはアプリケーション自体に依存しています。

トラフィックを移行する

トラフィックをすばやく移行するにはどうすればよいですか？

TiDBデータ移行のツールを使用してMySQLからTiDBにアプリケーションデータを移行することをお勧めします。必要に応じてネットワーク構成を編集することにより、読み取りおよび書き込みトラフィックをバッチで移行できます。ネットワーク構成を直接編集してシームレスな移行を実装するために、安定したネットワークLB（HAproxy、LVS、F5、DNSなど）を上位層にデプロイします。

TiDBの書き込みと読み取りの合計容量に制限はありますか？

合計読み取り容量に制限はありません。 TiDBサーバーを追加することで、読み取り容量を増やすことができます。通常、書き込み容量にも制限はありません。 TiKVノードを追加することで、書き込み容量を増やすことができます。

transaction too largeというエラーメッセージが表示されます

基盤となるストレージエンジンの制限により、TiDBの各Key-Valueエントリ（1行）は6MB以下にする必要があります。 txn-entry-size-limitの構成値は最大120MBまで調整できます。

分散トランザクションには2フェーズコミットが必要であり、最下層がRaftレプリケーションを実行します。トランザクションが非常に大きい場合、コミットプロセスは非常に遅くなり、書き込みの競合が発生する可能性が高くなります。さらに、失敗したトランザクションのロールバックは、不必要なパフォーマンスの低下につながります。これらの問題を回避するために、デフォルトでは、トランザクションでKey-Valueエントリの合計サイズを100MB以下に制限しています。より大きなトランザクションが必要な場合は、TiDB構成ファイルの値txn-total-size-limitを変更してください。この構成アイテムの最大値は最大10Gです。実際の制限は、マシンの物理メモリにも影響されます。

GoogleCloudSpannerには同様の制限あります。

データをバッチでインポートする方法は？

データをインポートするときは、バッチで挿入し、各バッチの行数を10,000以内に保ちます。

TiDBはデータを削除した直後にスペースを解放しますか？

DELETE 、およびTRUNCATEの操作のいずれも、データをすぐに解放しませDROP 。 TRUNCATEおよびDROPの操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）の後、データが削除され、スペースが解放されます。 DELETE操作の場合、データは削除されますが、TiDBGCに従ってスペースは解放されません。後続のデータがRocksDBに書き込まれ、 COMPACTを実行すると、スペースが再利用されます。

データをロードするときにターゲットテーブルでDDL操作を実行できますか？

いいえ。データをロードするときに、ターゲットテーブルでDDL操作を実行することはできません。実行しないと、データのロードに失敗します。

TiDBは構文へのreplace intoサポートしていますか？

はい。ただし、 load dataはreplace into構文をサポートしていません。

データを削除した後、クエリの速度が遅くなるのはなぜですか？

大量のデータを削除すると、多くの役に立たないキーが残り、クエリの効率に影響します。現在、リージョンマージ機能が開発中であり、この問題の解決が期待されています。詳細については、 TiDBベストプラクティスのデータセクションの削除を参照してください。

データを削除する最も効率的な方法は何ですか？

大量のデータを削除する場合は、 Delete from t where xx limit 5000;を使用することをお勧めします。ループを介して削除し、トランザクションサイズの制限を超えないように、ループを終了する条件としてAffected Rows == 0を使用します。ビジネスフィルタリングロジックを満たすことを前提として、強力なフィルタインデックス列を追加するか、主キーを直接使用してid >= 5000*n+m and id < 5000*(n+1)+mなどの範囲を選択することをお勧めします。

一度に削除する必要のあるデータの量が非常に多い場合、各削除は逆方向にトラバースするため、このループメソッドはますます遅くなります。以前のデータを削除した後、削除されたフラグの多くは短期間残り（その後、すべてがガベージコレクションによって処理されます）、次のDeleteステートメントに影響を与えます。可能であれば、Where条件を調整することをお勧めします。 TiDBのベストプラクティスの詳細を参照してください。

TiDBでのデータ読み込み速度を向上させる方法は？

• TiDB Lightningツールは、分散データのインポート用に開発されています。データインポートプロセスは、パフォーマンス上の理由から完全なトランザクションプロセスを実行しないことに注意してください。したがって、インポートプロセス中にインポートされるデータのACID制約は保証できません。インポートされたデータのACID制約は、インポートプロセス全体が終了した後にのみ保証されます。したがって、適用可能なシナリオには、主に新しいデータ（新しいテーブルや新しいインデックスなど）のインポート、または完全バックアップと復元（元のテーブルを切り捨ててからデータをインポートする）が含まれます。
• TiDBでのデータの読み込みは、ディスクとクラスタ全体のステータスに関連しています。データをロードするときは、ホストのディスク使用率、TiClientエラー、バックオフ、スレッドCPUなどのメトリックに注意してください。これらのメトリックを使用してボトルネックを分析できます。