移行に関するよくある質問
このドキュメントには、TiDB データ移行に関連するよくある質問 (FAQ) がまとめられています。
移行関連ツールに関するよくある質問については、以下のリスト内の対応するリンクをクリックしてください。
完全なデータのエクスポートとインポート
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 エラーが各コンポーネントログに表示される可能性があります。この場合、ネットワークの品質を改善するには、ネットワーク サービス プロバイダーに相談する必要があります。
各メトリックの出力が良好であると思われる場合は、各コンポーネントを更新してみてください。更新後も問題が解決しない場合は、PingCAP またはコミュニティから支持を得ます 。
誤って MySQL ユーザー テーブルを TiDB にインポートしたり、パスワードを忘れてログインできなくなった場合は、どう対処すればよいですか?
TiDB サービスを再起動し、構成ファイルに-skip-grant-table=trueパラメータを追加します。パスワードを使用せずにクラスターにログインし、ユーザーを再作成するか、 mysql.userを再作成します。特定のテーブル スキーマについては、公式ドキュメントを検索してください。
TiDB のデータをエクスポートするにはどうすればよいですか?
次の方法を使用して、TiDB 内のデータをエクスポートできます。
- mysqldump と
WHERE句を使用してデータをエクスポートします。 - MySQL クライアントを使用して、
selectの結果をファイルにエクスポートします。
DB2 または Oracle から TiDB に移行するにはどうすればよいですか?
すべてのデータを移行するか、DB2 または Oracle から TiDB に段階的に移行するには、次の解決策を参照してください。
- OGG、Gateway、CDC (Change Data Capture) などの Oracle の公式移行ツールを使用します。
- データをインポートおよびエクスポートするためのプログラムを開発します。
- スプールをテキスト ファイルとしてエクスポートし、Load infile を使用してデータをインポートします。
- サードパーティのデータ移行ツールを使用します。
現時点では、OGG を使用することをお勧めします。
エラー: Sqoop を使用して TiDB にデータをbatchesで書き込むときに、 java.sql.BatchUpdateExecption:statement count 5001 exceeds the transaction limitation
Sqoop では、 --batch各バッチで 100 のstatementをコミットすることを意味しますが、デフォルトでは、各statementに 100 の SQL ステートメントが含まれます。したがって、SQL ステートメントは 100 * 100 = 10000 となり、単一の 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単一の 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エラーメッセージが表示される
基礎となるstorageエンジンの制限により、TiDB 内の各キーと値のエントリ (1 行) は 6MB 以下である必要があります。 txn-entry-size-limit設定値は最大 120MB まで調整できます。
分散トランザクションには 2 フェーズ コミットが必要で、最下層でRaftレプリケーションが実行されます。トランザクションが非常に大きい場合、コミット プロセスが非常に遅くなり、書き込み競合が発生する可能性が高くなります。さらに、失敗したトランザクションのロールバックは、不必要なパフォーマンスの低下につながります。これらの問題を回避するために、デフォルトでは、トランザクション内のキーと値のエントリの合計サイズが 100MB 以下に制限されています。より大きなトランザクションが必要な場合は、TiDB 構成ファイルの値txn-total-size-limitを変更します。本設定項目の最大値は10Gまでです。実際の制限は、マシンの物理メモリにも影響されます。
Google Cloud Spanner には同様の制限あります。
データをバッチでインポートするにはどうすればよいですか?
データをインポートするときは、バッチに分けて挿入し、各バッチの行数を 10,000 以内に保ちます。
TiDB はデータを削除した後すぐにスペースを解放しますか?
DELETE 、 TRUNCATE 、およびDROP操作はいずれも、データを直ちに解放しません。 TRUNCATEとDROPの操作では、TiDB GC (ガベージ コレクション) 時間 (デフォルトでは 10 分) が経過すると、データが削除され、スペースが解放されます。 DELETE操作では、データは削除されますが、TiDB GC に従ってスペースは解放されません。後続のデータが RocksDB に書き込まれて実行されるときCOMPACT 、スペースは再利用されます。
データをロードするときにターゲットテーブルに対して DDL 操作を実行できますか?
いいえ。データをロードするときにターゲット テーブルに対して DDL 操作を実行することはできません。実行しないと、データのロードに失敗します。
TiDB は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 などのメトリクスに注意してください。これらのメトリクスを使用してボトルネックを分析できます。