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

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

ダウンストリーム特権要件

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

	特徴	範囲	必要な特権	備考
必須	基本関数	ターゲットテーブル	CREATE、SELECT、INSERT、UPDATE、DELETE、DROP、ALTER	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用に構成されたスキーマ	SELECT、INSERT、UPDATE、DELETE、CREATE、DROP	不要な場合は、値を「」に設定する必要があります
オプション	並列インポート	lightning.meta-schema-name用に構成されたスキーマ	SELECT、INSERT、UPDATE、DELETE、CREATE、DROP	不要な場合は、値を「」に設定する必要があります
オプション	checkpoint.driver = "mysql"	checkpoint.schema設定	SELECT、INSERT、UPDATE、DELETE、CREATE、DROP	チェックポイント情報がファイルではなくデータベースに保存されている場合に必要

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

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

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

MySQLからDumplingによってエクスポートされた正確なデータ量を計算することは困難です。ただし、次の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;

リソース要件

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

メモリとCPU ：

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

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

注：
インポートするデータが大きい場合、1回の並列インポートで約2GiBのメモリを消費する可能性があります。この場合、合計メモリ使用量はregion-concurrency x2GiBになります。 region-concurrencyは論理CPUの数と同じです。メモリサイズ（GiB）がCPUの2倍未満であるか、インポート中にOOMが発生した場合は、 region-concurrencyを減らしてOOMをアドレス指定できます。

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

記憶域スペース： sorted-kv-dir構成項目は、ソートされたKey-Valueファイルの一時記憶域ディレクトリーを指定します。ディレクトリは空である必要があり、ストレージスペースはインポートするデータセットのサイズよりも大きい必要があります。インポートのパフォーマンスを向上させるには、 data-source-dirとは異なるディレクトリを使用し、そのディレクトリにフラッシュストレージと排他的I/Oを使用することをお勧めします。

このページの内容

ダウンストリーム特権要件
ダウンストリームストレージスペースの要件
リソース要件