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

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を使用することをお勧めします。