重要

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

TiDBクラスタ管理に関する FAQ

このドキュメントでは、TiDB クラスタ管理に関連する FAQ をまとめています。

日常管理

このセクションでは、日常的なクラスター管理中に発生する可能性のある一般的な問題、その原因、および解決策について説明します。

TiDBにログインするにはどうすればいいですか?

MySQL にログインするのと同じように、TiDB にログインできます。例:

mysql -h 127.0.0.1 -uroot -P4000

TiDB のシステム変数を変更するにはどうすればよいですか?

MySQL と同様に、TiDB には静的パラメータとソリッドパラメータが含まれています。 SET GLOBAL xxx = n使用して静的パラメータを直接変更できますが、この場合、パラメータの新しい値はライフサイクル内でのみ有効です。

TiDB (TiKV) のデータディレクトリはどこにあり、何ですか?

TiKV データは--data-dirにあり、その中にはそれぞれバックアップ、データ、 Raftデータ、ミラーデータを保存するために使用される、backup、db、raft、snap の 4 つのディレクトリが含まれています。

TiDB のシステムテーブルとは何ですか?

MySQL と同様に、TiDB にもシステムテーブルが含まれており、サーバーの実行時に必要な情報を保存するために使用されます。1 TiDB システムテーブル参照してください。

TiDB/PD/TiKV ログはどこにありますか?

TiDB/PD/TiKV は、デフォルトではログに標準エラーを出力します。起動時にログファイルを--log-fileで指定すると、指定されたファイルにログが出力され、毎日ローテーションが実行されます。

TiDB を安全に停止するにはどうすればよいですか?

ロードバランサが実行中の場合 (推奨): ロードバランサを停止し、SQL ステートメントSHUTDOWNを実行します。その後、TiDB はgraceful-wait-before-shutdownで指定された期間、すべてのセッションが終了するまで待機します。その後、TiDB は実行を停止します。
ロードバランサが実行されていない場合: SHUTDOWNステートメントを実行します。その後、TiDB コンポーネントは正常に停止されます。

TiDB で`kill`を実行できますか?

DML ステートメントを強制終了します。
まずinformation_schema.cluster_processlist使用して TiDB インスタンスアドレスとセッション ID を見つけ、次に kill コマンドを実行します。
TiDB v6.1.0 では、Global Kill 機能が導入されています ( enable-global-kill構成によって制御され、デフォルトで有効になっています)。Global Kill が有効になっている場合は、 kill session_id実行するだけです。
TiDB バージョンが v6.1.0 より前の場合、または Global Kill 機能が有効になっていない場合、 kill session_idデフォルトでは有効になりません。DML ステートメントを終了するには、DML ステートメントを実行している TiDB インスタンスにクライアントを直接接続してから、 kill tidb session_idステートメントを実行する必要があります。クライアントが別の TiDB インスタンスに接続している場合、またはクライアントと TiDB クラスターの間にプロキシがある場合、 kill tidb session_idステートメントが別の TiDB インスタンスにルーティングされ、別のセッションが誤って終了する可能性があります。詳細については、 KILLを参照してください。
DDL ステートメントを強制終了します。まずadmin show ddl jobs使用して、終了する必要がある DDL ジョブの ID を見つけ、次にadmin cancel ddl jobs 'job_id' [, 'job_id'] ...を実行します。詳細については、 ADMINステートメントを参照してください。

TiDB はセッションタイムアウトをサポートしていますか?

TiDB は現在、 wait_timeout 、 interactive_timeout 、 tidb_idle_transaction_timeoutのタイムアウトをサポートしています。

TiDB バージョン管理戦略とは何ですか?

TiDBのバージョン管理の詳細については、 TiDB のバージョン管理参照してください。

TiDB クラスターの導入と保守にかかる運用コストはどのくらいでしょうか?

TiDB は、低コストで簡単にクラスターを管理できるいくつかの機能とツール提供します。

メンテナンス操作の場合、 TiUPパッケージマネージャーとして機能し、展開、スケーリング、アップグレード、およびその他のメンテナンスタスクを簡素化します。
監視の場合、 TiDB 監視フレームワークプロメテウスを使用して監視およびパフォーマンスメトリックを保存し、グラファナを使用してこれらのメトリックを視覚化します。数百のメトリックを備えた数十の組み込みパネルが利用可能です。
トラブルシューティングのために、 TiDB トラブルシューティングマップ TiDBサーバーとその他のコンポーネントの一般的な問題をまとめています。関連する問題が発生した場合、このマップを使用して問題を診断し、解決することができます。

さまざまな TiDB マスターバージョンの違いは何ですか?

TiDB コミュニティは非常に活発です。エンジニアは機能の最適化とバグの修正を続けています。そのため、TiDB バージョンは非常に速く更新されます。最新バージョンの情報を常に把握したい場合は、 TiDB リリースタイムラインを参照してください。

TiDB TiUPを使用するまたはTiDB Operatorの使用導入することをお勧めします。TiDB ではバージョン番号が一元管理されています。次のいずれかの方法でバージョン番号を確認できます。

select tidb_version()
tidb-server -V

TiDB 用のグラフィカルデプロイメントツールはありますか?

現在はいいえ。

TiDB クラスターをスケールアウトするにはどうすればよいですか?

オンラインサービスを中断することなく、TiDB クラスターをスケールアウトできます。

クラスターがTiUP使用してデプロイされている場合は、 TiUPを使用して TiDBクラスタを拡張するを参照してください。
クラスターが Kubernetes 上でTiDB Operator使用してデプロイされている場合は、 Kubernetes で TiDB を手動でスケールするを参照してください。

TiDB を水平方向にスケーリングするにはどうすればよいですか?

ビジネスが成長するにつれて、データベースは次の 3 つのボトルネックに直面する可能性があります。

ストレージリソースが不足しているため、storage領域が十分ではありません。
CPU 占有率が高いなどのコンピューティングリソースの不足。
書き込みおよび読み取り容量が不十分です。

ビジネスの成長に合わせて TiDB を拡張できます。

ディスク容量が足りない場合は、TiKV ノードを追加するだけで容量を増やすことができます。新しいノードが起動すると、PD は他のノードから新しいノードにデータを自動的に移行します。
コンピューティングリソースが十分でない場合は、TiDB ノードまたは TiKV ノードを追加する前に、まず CPU の消費状況を確認してください。TiDB ノードを追加する場合は、ロードバランサーで設定できます。
容量が足りない場合は、TiDB ノードと TiKV ノードの両方を追加できます。

Percolator が分散ロックを使用し、クラッシュクライアントがロックを保持する場合、ロックは解放されませんか?

詳細は中国語版パーコレータと TiDBトランザクションアルゴリズムご覧ください。

TiDB が Thrift ではなく gRPC を使用するのはなぜですか? Google が使用しているからでしょうか?

そうではありません。フロー制御、暗号化、ストリーミングなど、gRPC の優れた機能が必要です。

`like(bindo.customers.name, jason%, 92)`の 92 は何を示していますか?

92 はエスケープ文字を示し、デフォルトでは ASCII 92 です。

`information_schema.tables.data_length`で表示されるデータ長が TiKV 監視パネルのストアサイズと異なるのはなぜですか?

理由は2つあります。

2 つの結果は異なる方法で計算されます。1 information_schema.tables.data_length各行の平均長を計算して推定した値ですが、TiKV 監視パネルのストアサイズは、単一の TiKV インスタンス内のデータファイル (RocksDB の SST ファイル) の長さを合計したものです。
information_schema.tables.data_lengthは論理値ですが、ストアサイズは物理値です。トランザクションの複数のバージョンによって生成された冗長データは論理値には含まれませんが、冗長データは物理値で TiKV によって圧縮されます。

トランザクションが非同期コミットまたは 1 フェーズコミット機能を使用しないのはなぜですか?

次の状況では、システム変数を使用して機能非同期コミットと機能1フェーズコミットを有効にしても、TiDB はこれらの機能を使用しません。

TiDB Binlogを有効にしている場合、TiDB Binlogの実装によって制限され、TiDB は非同期コミットまたは 1 フェーズコミット機能を使用しません。
TiDB は、トランザクションで書き込まれるキーと値のペアが 256 個以下で、キーの合計サイズが 4 KB 以下の場合にのみ、非同期コミットまたは 1 フェーズコミット機能を使用します。これは、書き込むデータ量が多いトランザクションの場合、非同期コミットを使用してもパフォーマンスが大幅に向上しないためです。

PD管理

このセクションでは、PD 管理中に発生する可能性のある一般的な問題、その原因、および解決策について説明します。

PDにアクセスすると、 `TiKV cluster is not bootstrapped`メッセージが表示されます

PD の API のほとんどは、TiKV クラスターが初期化されている場合にのみ使用できます。新しいクラスターがデプロイされたときに TiKV が起動されていない状態で PD が起動されているときに PD にアクセスすると、このメッセージが表示されます。このメッセージが表示された場合は、TiKV クラスターを起動してください。TiKV が初期化されると、PD にアクセスできるようになります。

PD を起動すると、 `etcd cluster ID mismatch`メッセージが表示されます。

これは、PD 起動パラメータの--initial-clusterに、このクラスターに属していないメンバーが含まれているためです。この問題を解決するには、各メンバーの対応するクラスターを確認し、間違ったメンバーを削除してから、PD を再起動します。

PD の保存時の暗号化を有効にすると`[PD:encryption:ErrEncryptionNewMasterKey]fail to get encryption key from file /root/path/file%!(EXTRA string=open /root/path/file: permission denied)`メッセージが表示されます。

保存時の暗号化では、キーファイルをrootディレクトリまたはそのサブディレクトリに保存することはできません。読み取り権限を付与しても、同じエラーが発生します。この問題を解決するには、キーファイルをrootディレクトリ以外の場所に保存します。

PD の時間同期エラーの最大許容範囲はどれくらいですか?

PD はあらゆる同期エラーを許容できますが、エラー値が大きいほど、PD によって割り当てられたタイムスタンプと物理時間の間のギャップが大きくなり、履歴バージョンの読み取りなどの関数に影響します。

クライアント接続はどのようにして PD を見つけるのでしょうか?

クライアント接続は TiDB を介してのみクラスターにアクセスできます。TiDB は PD と TiKV を接続します。PD と TiKV はクライアントに対して透過的です。TiDB がいずれかの PD に接続すると、PD は現在のリーダーが誰であるかを TiDB に伝えます。この PD がリーダーでない場合、TiDB はリーダー PD に再接続します。

TiKV ストアの各ステータス (Up、Disconnect、Offline、Down、Tombstone) の関係は何ですか?

各ステータスの関係についてはTiKVストアの各ステータスの関係を参照してください。

PD Controlを使用して、TiKV ストアのステータス情報を確認できます。

PD の`leader-schedule-limit`と`region-schedule-limit`スケジューリングパラメータの違いは何ですか?

leader-schedule-limitスケジューリングパラメータは、異なる TiKV サーバーのLeader数のバランスをとるために使用され、クエリ処理の負荷に影響します。
region-schedule-limitスケジューリングパラメータは、異なる TiKV サーバーのレプリカ数のバランスをとるために使用され、異なるノードのデータ量に影響します。

各リージョンのレプリカの数は設定可能ですか? 設定可能な場合、どのように設定しますか?

はい。現在、レプリカのグローバル数のみを更新できます。初めて起動すると、PD は構成ファイル (conf/pd.yml) を読み取り、その中の max-replicas 構成を使用します。後で数を更新する場合は、pd-ctl 構成コマンドconfig set max-replicas $numを使用し、 config show all使用して有効な構成を表示します。更新はアプリケーションに影響せず、バックグラウンドで構成されます。

TiKV インスタンスの合計数が、設定したレプリカの数以上であることを確認してください。たとえば、レプリカが 3 つある場合は、少なくとも 3 つの TiKV インスタンスが必要です。レプリカの数を増やす前に、追加のstorage要件を見積もる必要があります。pd-ctl の詳細については、 PD Controlユーザーガイドを参照してください。

コマンドラインのクラスター管理ツールがない場合に、クラスター全体のヘルス状態を確認するにはどうすればよいでしょうか?

pd-ctl ツールを使用して、クラスターの一般的なステータスを確認できます。詳細なクラスターステータスを確認するには、モニターを使用して確認する必要があります。

オフラインのクラスターノードの監視データを削除するにはどうすればよいですか?

オフラインノードは通常、TiKV ノードを示します。オフラインプロセスが終了したかどうかは、pd-ctl またはモニターによって判断できます。ノードがオフラインになったら、次の手順を実行します。

オフラインノード上の関連サービスを手動で停止します。
Prometheus 構成ファイルから対応するノードのnode_exporterデータを削除します。

TiDBサーバー管理

このセクションでは、TiDBサーバーの管理中に発生する可能性のある一般的な問題、その原因、および解決策について説明します。

TiDB で`lease`パラメータを設定するにはどうすればよいでしょうか?

リースパラメータ（ --lease=60 ）は、TiDBサーバーの起動時にコマンドラインから設定されます。リースパラメータの値は、現在のセッションのデータベーススキーマ変更（DDL）速度に影響します。テスト環境では、値を 1 秒に設定してテストサイクルを高速化できます。ただし、本番環境では、DDL の安全性を確保するために、値を分（たとえば 60）に設定することをお勧めします。

DDL 操作の処理時間はどれくらいですか?

処理時間はシナリオによって異なります。一般的には、次の 3 つのシナリオが考えられます。

対応するデータテーブル内の行数が比較的少ないAdd Indexの操作: 約3秒
対応するデータテーブル内の行数が比較的多いAdd Index操作: 処理時間は、特定の行数とその時点の QPS によって異なります ( Add Index操作は通常の SQL 操作よりも優先度が低くなります)
その他のDDL操作: 約1秒

DDL 要求を受信する TiDBサーバーインスタンスが、DDL 所有者が存在する TiDBサーバーインスタンスと同じである場合、上記の最初のシナリオと 3 番目のシナリオにかかる時間は、数十から数百ミリ秒に過ぎない可能性があります。

DDL ステートメントの実行が非常に遅くなるのはなぜですか?

考えられる理由:

複数の DDL ステートメントを同時に実行すると、最後のいくつかの DDL ステートメントの実行速度が遅くなる可能性があります。これは、DDL ステートメントが TiDB クラスター内で順番に実行されるためです。
クラスターを正常に起動した後、最初の DDL 操作の実行に通常 30 秒ほどかかることがあります。これは、TiDB クラスターが DDL ステートメントを処理するリーダーを選出しているためです。
以下の条件に該当する場合、TiDB 起動後の最初の 10 分間の DDL ステートメントの処理時間は通常の場合よりも大幅に長くなります。1) TiDB を停止しているとき (停電の場合を含む)、TiDB は通常どおり PD と通信できません。2) TiDB はkill -9コマンドによって停止されるため、PD から登録データを時間内にクリーンアップできません。この期間中に DDL ステートメントを実行すると、各 DDL の状態変更のために、2 * リース (リース = 45 秒) 待機する必要があります。
クラスター内の TiDBサーバーと PDサーバーの間で通信の問題が発生した場合、TiDBサーバーはPDサーバーからバージョン情報を時間内に取得または更新できません。この場合、各 DDL の状態処理に 2 * リースを待つ必要があります。

TiDB のバックエンドstorageエンジンとして S3 を使用できますか?

いいえ。現在、TiDB は分散storageエンジンと Goleveldb/RocksDB/BoltDB エンジンのみをサポートしています。

`Information_schema`より実際の情報をサポートできますか?

MySQL 互換性の一環として、TiDB は多数のINFORMATION_SCHEMAテーブルをサポートしています。これらのテーブルの多くには、対応する SHOW コマンドもあります。詳細については、情報スキーマを参照してください。

TiDB バックオフタイプのシナリオの説明は何ですか?

TiDBサーバーと TiKVサーバー間の通信プロセスで、大量のデータを処理しているときに、 Server is busyまたはbackoff.maxsleep 20000msログメッセージが表示されます。これは、TiKVサーバーがデータを処理している間、システムがビジー状態になっているためです。このとき、通常、TiKV ホストのリソース使用率が高いことがわかります。このような場合は、リソースの使用状況に応じてサーバーの容量を増やすことができます。

TiDB TiClient タイプの主な理由は何ですか?

TiClientリージョンエラーインジケータは、TiDBサーバーがクライアントとして KV インターフェイスを介して TiKVサーバーにアクセスしてデータ操作を実行するときに表示されるエラーの種類とメトリックを示します。エラーの種類にはnot_leaderとstale_epoch含まれます。これらのエラーは、TiDBサーバーが独自のキャッシュ情報に従ってリージョンリーダーデータを操作した場合、リージョンリーダーが移行した場合、または現在の TiKVリージョン情報と TiDB キャッシュのルーティング情報が一致しない場合に発生します。通常、この場合、TiDBサーバーはPD から最新のルーティングデータを自動的に取得し、以前の操作をやり直します。

TiDB がサポートする同時接続の最大数はいくつですか?

デフォルトでは、TiDBサーバーあたりの最大接続数に制限はありません。必要に応じて、 config.tomlファイルにinstance.max_connections設定するか、システム変数max_connectionsの値を変更して、最大接続数を制限できます。同時接続数が多すぎると応答時間が長くなる場合は、TiDB ノードを追加して容量を増やすことをお勧めします。

テーブルの作成時間を表示するにはどうすればいいですか?

information_schemaの表のうちcreate_time作成時刻です。

TiDB ログの`EXPENSIVE_QUERY`の意味は何ですか?

TiDB が SQL ステートメントを実行しているときに、各演算子が 10,000 行以上を処理すると推定される場合、クエリはEXPENSIVE_QUERYなります。 tidb-server構成パラメータを変更してしきい値を調整し、 tidb-serverを再起動できます。

TiDB のテーブルのサイズを見積もるにはどうすればよいでしょうか?

TiDB 内のテーブルのサイズを見積もるには、次のクエリステートメントを使用できます。

SELECT
  db_name,
  table_name,
  ROUND(SUM(total_size / cnt), 2) Approximate_Size,
  ROUND(
    SUM(
      total_size / cnt / (
        SELECT
          ROUND(AVG(value), 2)
        FROM
          METRICS_SCHEMA.store_size_amplification
        WHERE
          value > 0
      )
    ),
    2
  ) Disk_Size
FROM
  (
    SELECT
      db_name,
      table_name,
      region_id,
      SUM(Approximate_Size) total_size,
      COUNT(*) cnt
    FROM
      information_schema.TIKV_REGION_STATUS
    WHERE
      db_name = @dbname
      AND table_name IN (@table_name)
    GROUP BY
      db_name,
      table_name,
      region_id
  ) tabinfo
GROUP BY
  db_name,
  table_name;

上記のステートメントを使用する場合は、ステートメント内の次のフィールドを必要に応じて入力して置き換える必要があります。

@dbname : データベースの名前。
@table_name : ターゲットテーブルの名前。

さらに、上記の声明では、

store_size_amplificationクラスター圧縮率の平均を示します。この情報を照会するためにSELECT * FROM METRICS_SCHEMA.store_size_amplification;使用するだけでなく、 Grafana Monitoring PD - 統計バランスパネルで各ノードのサイズ増幅メトリックを確認することもできます。クラスター圧縮率の平均は、すべてのノードのサイズ増幅の平均です。
Approximate_Size 、圧縮前のレプリカ内のテーブルのサイズを示します。これはおおよその値であり、正確な値ではないことに注意してください。
Disk_Size圧縮後のテーブルのサイズを示します。これはおおよその値であり、 Approximate_Sizeとstore_size_amplificationに従って計算できます。

TiKVサーバー管理

このセクションでは、TiKVサーバーの管理中に発生する可能性のある一般的な問題、その原因、および解決策について説明します。

コンプライアンスまたはマルチテナントアプリケーションのデータの場所を指定するにはどうすればよいでしょうか?

配置ルール使用して、コンプライアンスまたはマルチテナントアプリケーションのデータの場所を指定できます。

SQL の配置ルールは、レプリカの数、 Raftロール、配置場所、ルールが適用されるキー範囲など、連続したデータ範囲の属性を制御するように設計されています。

TiKV クラスターのレプリカの推奨数はいくつですか? 高可用性のためには最小数を維持する方が良いですか?

テスト環境では、リージョンごとに 3 つのレプリカがあれば十分です。ただし、実本番シナリオでは、3 ノード未満の TiKV クラスターを運用しないでください。インフラストラクチャ、ワークロード、および回復力のニーズに応じて、この数を増やす必要がある場合があります。コピー数が多いほどパフォーマンスは低下しますが、セキュリティは高くなることに注意してください。

TiKVを起動すると、 `cluster ID mismatch`メッセージが表示されます。

これは、ローカル TiKV に保存されているクラスター ID が PD で指定されたクラスター ID と異なるためです。新しい PD クラスターがデプロイされると、PD はランダムなクラスター ID を生成します。TiKV は PD からクラスター ID を取得し、初期化時にクラスター ID をローカルに保存します。次に TiKV を起動すると、ローカルクラスター ID と PD のクラスター ID が照合されます。クラスター ID が一致しない場合は、 cluster ID mismatchメッセージが表示され、TiKV は終了します。

以前に PD クラスターをデプロイしたが、その後 PD データを削除して新しい PD クラスターをデプロイすると、TiKV が古いデータを使用して新しい PD クラスターに接続するため、このエラーが発生します。

TiKVを起動すると`duplicated store address`メッセージが表示されます

これは、起動パラメータのアドレスが他の TiKV によって PD クラスターに登録されているためです。このエラーが発生する一般的な条件: TiKV --data-dirで指定されたパスにデータフォルダーがありません (削除または移動後に --data-dir を更新していない)。以前のパラメータで TiKV を再起動します。pd-ctl のストア削除機能を試し、以前のストアを削除してから、TiKV を再起動してください。

TiKV プライマリノードとセカンダリノードは同じ圧縮アルゴリズムを使用しますが、結果が異なるのはなぜですか?

現在、TiKV プライマリノードの一部のファイルは圧縮率が高くなっています。これは、基盤となるデータ分布と RocksDB の実装に依存します。データサイズが時々変動するのは正常です。基盤となるstorageエンジンは、必要に応じてデータを調整します。

TiKVブロックキャッシュの機能は何ですか?

TiKV は、RocksDB のカラムファミリ (CF) 機能を実装します。デフォルトでは、KV データは最終的に RocksDB 内の 3 つの CF (デフォルト、書き込み、ロック) に保存されます。

デフォルトの CF には実データが保存され、対応するパラメータは[rocksdb.defaultcf]にあります。
書き込み CF にはデータバージョン情報 (MVCC) とインデックス関連データが格納され、対応するパラメータは[rocksdb.writecf]にあります。
ロック CF はロック情報を保存し、システムはデフォルトのパラメータを使用します。
Raft RocksDB インスタンスはRaftログを保存します。デフォルトの CF は主にRaftログを保存し、対応するパラメータは[raftdb.defaultcf]にあります。
すべての CF には、データブロックをキャッシュして RocksDB の読み取り速度を向上させる共有ブロックキャッシュがあります。ブロックキャッシュのサイズは、 block-cache-sizeパラメータによって制御されます。パラメータの値が大きいほど、より多くのホットデータをキャッシュでき、読み取り操作に有利になります。同時に、システムメモリの消費量も増加します。
各 CF には個別の書き込みバッファがあり、そのサイズはwrite-buffer-sizeパラメータによって制御されます。

TiKV チャンネルが満員なのはなぜですか?

Raftstoreスレッドが遅すぎるか、I/O によってブロックされています。Raftstore の CPU 使用状況を表示できます。
TiKV がビジー状態 (CPU やディスク I/O など) のため、処理できません。

TiKV がリージョンリーダーを頻繁に変更するのはなぜですか?

ネットワークの問題により、ノード間の通信が停止します。レポート障害の監視を確認できます。
元のメインLeaderのノードがスタックし、Followerに時間内に到達できなくなります。
Raftstore のスレッドがスタックしました。

ノードがダウンした場合、サービスは影響を受けますか? 影響を受ける場合、どのくらいの期間ですか?

TiKV はRaftを使用して、複数のレプリカ間でデータを複製します (デフォルトでは、リージョンごとに 3 つのレプリカ)。1 つのレプリカに障害が発生した場合、他のレプリカがデータの安全性を保証します。Raft プロトコルに基づいて、ノードがダウンして単一のリーダーに障害が発生した場合、最大 2 倍のリース時間 (リース時間は 10 秒) 後に、別のノードのフォロワーがすぐにリージョンリーダーとして選出されます。

I/O、メモリ、CPU を大量に消費し、パラメータ構成を超える TiKV シナリオは何ですか?

TiKV で大量のデータを書き込んだり読み取ったりすると、大量の I/O、メモリ、CPU が消費されます。大規模な中間結果セットを生成するシナリオなど、非常に複雑なクエリを実行すると、大量のメモリと CPU リソースが消費されます。

TiKV は SAS/SATA ディスクまたは SSD/SAS ディスクの混合展開をサポートしていますか?

いいえ。OLTP シナリオの場合、TiDB はデータアクセスと操作のために高 I/O ディスクを必要とします。強力な一貫性を備えた分散データベースである TiDB には、レプリカレプリケーションや最レイヤーのstorageコンパクションなどの書き込み増幅機能があります。したがって、TiDB のベストプラクティスでは、storageディスクとして NVMe SSD を使用することをお勧めします。TiKV と PD の混合展開はサポートされていません。

データアクセスの前に、キーデータテーブルの範囲が分割されていますか?

いいえ。MySQL のテーブル分割ルールとは異なります。TiKV では、テーブル Range はリージョンのサイズに基づいて動的に分割されます。

リージョンはどのように分割されますか?

リージョンは事前に分割されませんが、リージョン分割メカニズムに従います。リージョンのサイズがregion-max-sizeまたはregion-max-keysのパラメータの値を超えると、分割がトリガーされます。分割後、その情報は PD に報告されます。

TiKV には、データのセキュリティを保証するために、MySQL のような`innodb_flush_log_trx_commit`パラメータがありますか?

はい。現在、スタンドアロンstorageエンジンは 2 つの RocksDB インスタンスを使用しています。1 つのインスタンスは raft-log の保存に使用されます。TiKV のsync-logパラメータが true に設定されている場合、各コミットは強制的に raft-log にフラッシュされます。クラッシュが発生した場合は、raft-log を使用して KV データを復元できます。

SSD、RAID レベル、RAID カードのキャッシュ戦略、NUMA 構成、ファイルシステム、オペレーティングシステムの I/O スケジューリング戦略など、WALstorageに推奨されるサーバー構成は何ですか?

WAL は順序付き書き込みに属しており、現在、固有の構成は適用されていません。推奨される構成は次のとおりです。

ソリッドステートドライブ
RAID 10を推奨
RAID カードのキャッシュ戦略とオペレーティングシステムの I/O スケジューリング戦略: 現在、特定のベストプラクティスはありません。Linux 7 以降では、デフォルト構成を使用できます。
NUMA: 具体的な提案はありません。メモリ割り当て戦略としては、 interleave = all使用できます。
ファイルシステム: ext4

最も厳密なデータ利用可能モード ( `sync-log = true` ) での書き込みパフォーマンスはどうですか?

通常、 sync-log有効にするとパフォーマンスが約 30% 低下します。 sync-logをfalseに設定した場合の書き込みパフォーマンスについては、 Sysbench を使用した TiDB のパフォーマンステスト結果を参照してください。

TiKVアーキテクチャのRaft + 複数のレプリカは絶対的なデータ安全性を実現できますか? スタンドアロンstorageに最も厳格なモード ( `sync-log = true` ) を適用する必要がありますか?

データは、ノード障害が発生した場合の回復可能性を確保するために、 Raftコンセンサスアルゴリズム使用して TiKV ノード間で冗長的に複製されます。データがレプリカの 50% 以上に書き込まれた場合にのみ、アプリケーションは ACK を返します (3 つのノードのうち 2 つ)。ただし、理論的には 2 つのノードがクラッシュする可能性があります。したがって、データの安全性に対する要件がそれほど厳しくなく、パフォーマンスに対する要件が厳しいシナリオを除き、 sync-logモードを有効にすることを強くお勧めします。

sync-logを使用する代わりに、 Raftグループに 3 つのレプリカではなく 5 つのレプリカを持つことも検討できます。これにより、2 つのレプリカに障害が発生してもデータの安全性が確保されます。

スタンドアロンの TiKV ノードの場合でも、 sync-logモードを有効にすることをお勧めします。そうしないと、ノード障害が発生した場合に最後の書き込みが失われる可能性があります。

TiKV はRaftプロトコルを使用するため、データの書き込み中に複数のネットワークラウンドトリップが発生します。実際の書き込み遅延はどのくらいですか?

理論上、TiDB の書き込み遅延は、スタンドアロンデータベースよりもネットワークラウンドトリップで 4 回多くなります。

TiDB には、MySQL のように、KV インターフェイスを直接使用でき、独立したキャッシュを必要としない InnoDB memcached プラグインがありますか?

TiKV は、インターフェイスを個別に呼び出すことをサポートしています。理論的には、インスタンスをキャッシュとして取得できます。TiDB は分散リレーショナルデータベースであるため、TiKV を個別にサポートしていません。

コプロセッサーコンポーネントは何に使用されますか?

TiDBとTiKV間のデータ転送を削減
TiKV の分散コンピューティングリソースを最大限に活用して、コンピューティングプッシュダウンを実行します。

エラーメッセージ`IO error: No space left on device While appending to file`が表示される

これはディスク容量が不足しているためです。ノードを追加するか、ディスク容量を拡大する必要があります。

TiKV で OOM (メモリ不足) エラーが頻繁に発生するのはなぜですか?

TiKV のメモリ使用量は主に RocksDB のブロックキャッシュから発生し、デフォルトではシステムメモリサイズの 40% を占めます。TiKV で OOM エラーが頻繁に発生する場合は、値block-cache-sizeの設定が高すぎないか確認する必要があります。また、1 台のマシンに複数の TiKV インスタンスを展開する場合は、複数のインスタンスがシステムメモリを大量に使用して OOM エラーが発生しないように、パラメータを明示的に構成する必要があります。

TiDB データと RawKV データの両方を同じ TiKV クラスターに保存できますか?

いいえ。TiDB (またはトランザクション API から作成されたデータ) は特定のキー形式に依存します。RawKV API から作成されたデータ (または他の RawKV ベースのサービスから作成されたデータ) とは互換性がありません。

TiDB テスト

このセクションでは、TiDB テスト中に発生する可能性のある一般的な問題、その原因、および解決策について説明します。

Sysbench を使用した TiDB のパフォーマンステスト結果は何ですか?

最初は、多くのユーザーが TiDB と MySQL のベンチマークテストや比較テストを行う傾向があります。私たちも同様の公式テストを実施しましたが、テストデータには多少の偏りはあるものの、テスト結果は概ね一貫していることがわかりました。TiDB のアーキテクチャはMySQL と大きく異なるため、ベンチマークポイントを見つけるのは困難です。提案は次のとおりです。

ベンチマークテストに時間をかけすぎないでください。TiDB を使用するシナリオの違いにもっと注意を払ってください。
Sysbench を使用した TiDB のパフォーマンステスト結果参照。

TiDB クラスターの容量 (QPS) とノード数の関係は何ですか? TiDB と MySQL を比較するとどうなりますか?

10 ノード内では、TiDB 書き込み容量 (挿入 TPS) とノード数の関係は、およそ 40% の線形増加です。MySQL は単一ノード書き込みを使用するため、書き込み容量を拡張することはできません。
MySQL では、セカンダリデータベースを追加することで読み取り容量を増やすことができますが、書き込み容量はシャーディングを使用する以外では増やすことができず、多くの問題があります。
TiDB では、ノードを追加することで読み取り容量と書き込み容量の両方を簡単に増やすことができます。

当社のDBAによるMySQLとTiDBのパフォーマンステストでは、スタンドアロンのTiDBのパフォーマンスはMySQLほど良くないことがわかりました。

TiDB は、MySQL スタンドアロンの容量が限られているためにシャーディングが使用され、強力な一貫性と完全な分散トランザクションが求められるシナリオ向けに設計されています。TiDB の利点の 1 つは、コンピューティングをstorageノードにプッシュダウンして同時コンピューティングを実行することです。

TiDB は、小さなデータサイズと限られたリージョンでは同時実行の強さを発揮できないため、小さいサイズ (1,000 万レベル未満など) のテーブルには適していません。典型的な例は、数行のレコードが頻繁に更新されるカウンターテーブルです。TiDB では、これらの行はstorageエンジンで複数のキーと値のペアになり、単一のノードにあるリージョンに落ち着きます。強力な一貫性を保証するためのバックグラウンドレプリケーションと TiDB から TiKV への操作のオーバーヘッドにより、MySQL スタンドアロンよりもパフォーマンスが低下します。

バックアップと復元

このセクションでは、バックアップおよび復元中に発生する可能性のある一般的な問題、その原因、および解決策について説明します。

TiDB でデータをバックアップするにはどうすればよいですか?

現在、大容量データ (1 TB 以上) のバックアップには、バックアップと復元 (BR)使用する方法が推奨されています。それ以外の場合は、 Dumplingというツールが推奨されます。公式の MySQL ツールmysqldumpも TiDB でデータのバックアップと復元にサポートされていますが、そのパフォーマンスはBRほど優れておらず、大容量データのバックアップと復元にはさらに多くの時間が必要です。

BRに関するその他の FAQ については、 BRよくある質問参照してください。

バックアップと復元の速度はどのくらいですか?

BR使用してバックアップおよび復元タスクを実行すると、バックアップは TiKV インスタンスあたり約 40 MB/秒で処理され、復元は TiKV インスタンスあたり約 100 MB/秒で処理されます。