重要

現在表示されているページは、TiDBのアーカイブされたドキュメント (非更新) です。TiDBをご利用の場合、最新のLTS (Long Term Support) バージョンの使用を推奨します。

重要

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

TiDB Lightningを使用するための前提条件

TiDB Lightningを使用する前に、環境が要件を満たしているかどうかを確認する必要があります。これにより、インポート中のエラーを減らし、インポートを確実に成功させることができます。

ダウンストリーム権限の要件

インポートモードと有効な機能に基づいて、ダウンストリームデータベースユーザーに異なる権限を付与する必要があります。次の表に参考情報を示します。

	特徴	範囲	必要な権限	備考
必須	基本関数	対象表	作成、選択、挿入、更新、削除、削除、変更	DROP は、tidb-lightning-ctl が checkpoint-destroy-all コマンドを実行する場合にのみ必要です。
必須	基本関数	対象データベース	作成
必須	tidb バックエンド	information_schema.columns	選択する
	ローカルバックエンド	mysql.tidb	選択する
		-	素晴らしい
		-	RESTRICTED_VARIABLES_ADMIN、RESTRICTED_TABLES_ADMIN	対象の TiDB で SEM が有効になっている場合に必要
おすすめされた	競合検出、最大エラー	lightning.task-info-schema-name 用に設定されたスキーマ	選択、挿入、更新、削除、作成、削除	必要ない場合は、値を "" に設定する必要があります。
オプション	並行輸入	lightning.meta-schema-name 用に構成されたスキーマ	選択、挿入、更新、削除、作成、削除	必要ない場合は、値を "" に設定する必要があります。
オプション	checkpoint.driver = "mysql"	checkpoint.schema 設定	選択、挿入、更新、削除、作成、削除	チェックポイント情報がファイルではなくデータベースに格納されている場合に必要

ダウンストリームのストレージ容量要件

ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。標準のハードウェア要件に加えて、ターゲット TiKV クラスターのストレージ容量は、データソースのサイズ x レプリカの数 x 2より大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲット TiKV クラスターには、データソースのサイズの 6 倍を超えるストレージスペースが必要です。次の理由により、式には x 2 があります。

インデックスは余分なスペースを必要とする場合があります。
RocksDB には空間増幅効果があります。

Dumplingによって MySQL からエクスポートされた正確なデータ量を計算することは困難です。ただし、次の SQL ステートメントを使用して information_schema.tables テーブルのデータ長フィールドを要約することにより、データ量を見積もることができます。

すべてのスキーマのサイズを MiB で計算します。 ${schema_name} をスキーマ名に置き換えます。

SELECT table_schema, SUM(data_length)/1024/1024 AS data_length, SUM(index_length)/1024/1024 AS index_length, SUM(data_length+index_length)/1024/1024 AS sum FROM information_schema.tables WHERE table_schema = "${schema_name}" GROUP BY table_schema;

最大テーブルのサイズを MiB で計算します。 ${schema_name} をスキーマ名に置き換えます。

SELECT table_name, table_schema, SUM(data_length)/1024/1024 AS data_length, SUM(index_length)/1024/1024 AS index_length,sum(data_length+index_length)/1024/1024 AS sum FROM information_schema.tables WHERE table_schema = "${schema_name}" GROUP BY table_name,table_schema ORDER BY sum DESC LIMIT 5;

リソース要件

オペレーティングシステム: このドキュメントの例では、新しい CentOS 7 インスタンスを使用しています。仮想マシンは、ローカルホストまたはクラウドにデプロイできます。 TiDB Lightningはデフォルトで必要なだけ多くの CPU リソースを消費するため、専用サーバーにデプロイすることをお勧めします。これが不可能な場合は、他の TiDB コンポーネント (tikv-server など) と一緒に単一のサーバーにデプロイし、 TiDB Lightningからの CPU 使用を制限するようにregion-concurrencyを構成できます。通常、サイズは論理 CPU の 75% に設定できます。

メモリと CPU :

TiDB Lightningが消費する CPU とメモリは、バックエンドモードによって異なります。使用するバックエンドに基づいて最適なインポートパフォーマンスをサポートする環境でTiDB Lightningを実行します。

ローカルバックエンド: TiDB ライトニングは、このモードで多くの CPU とメモリを消費します。 32 コアを超える CPU と 64 GiB を超えるメモリを割り当てることをお勧めします。

注:
インポートするデータが大きい場合、1 回の並列インポートで 2 GiB 程度のメモリを消費する場合があります。この場合、合計メモリ使用量はregion-concurrency x 2 GiB になる可能性があります。 region-concurrencyは、論理 CPU の数と同じです。メモリサイズ (GiB) が CPU の 2 倍未満であるか、インポート中に OOM が発生した場合は、 region-concurrencyを減らして OOM に対処できます。

TiDB バックエンド: このモードでは、パフォーマンスのボトルネックは TiDB にあります。 TiDB Lightningには 4 コアの CPU と 8 GiB のメモリを割り当てることをお勧めします。インポートで TiDB クラスターが書き込みしきい値に達しない場合は、 region-concurrencyを増やすことができます。
Importer-backend: このモードでは、リソース消費は Local-backend とほぼ同じです。 Importer-backend は推奨されません。特に要件がない場合は、Local-backend を使用することをお勧めします。

ストレージスペース: sorted-kv-dir構成アイテムは、並べ替えられたキー値ファイルの一時ストレージディレクトリを指定します。ディレクトリは空である必要があり、ストレージスペースはインポートするデータセットのサイズより大きくなければなりません。インポートのパフォーマンスを向上させるには、 data-source-dir以外のディレクトリを使用し、そのディレクトリにフラッシュストレージと排他的 I/O を使用することをお勧めします。