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にもシステムテーブルが含まれており、サーバーの実行時に必要な情報を格納するために使用されます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 フェーズコミット機能を使用しないのはなぜですか?

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

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

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

これは、ローカルTiKVに保存されているクラスタIDがPDで指定されたクラスタIDと異なるためです。新しいPDクラスタがデプロイされると、PDはランダムなクラスタIDを生成します。TiKVはPDからクラスタ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ます。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`パラメータがありますか?

TiKVには同様のパラメータはありませんが、TiKVの各コミットはRaftログに強制的にフラッシュされます（TiKVはRaft Engine使用してRaftログを保存し、コミット時に強制的にフラッシュします）。TiKVがクラッシュした場合、KVデータはRaftログに基づいて自動的に復元されます。

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

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

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

TiKVアーキテクチャのRaft + 複数のレプリカは絶対的なデータ安全性を実現できますか?

データは、ノード障害発生時の復旧可能性を確保するため、 Raftコンセンサスアルゴリズム使用してTiKVノード間で冗長的に複製されます。データがレプリカの50%以上に書き込まれた場合にのみ、アプリケーションはACKを返します（3ノード中2ノード）。

理論上、2つのノードがクラッシュする可能性があるため、v5.0以降ではTiKVに書き込まれたデータはデフォルトでディスクに書き込まれます。つまり、各コミットはRaftログに強制的にフラッシュされることになります。TiKVがクラッシュした場合、KVデータはRaftログに基づいて自動的に回復されます。

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

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の設定が高すぎないか確認する必要があります。また、複数のTiKVインスタンスを1台のマシンにデプロイしている場合は、複数のインスタンスがシステムメモリを過剰に使用してOOMエラーが発生しないように、パラメータを明示的に設定する必要があります。

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

これはTiDBのバージョンとTiKV API V2が有効になっているかどうかによって異なります（ storage.api-version = 2 ）。

TiDB バージョンが v6.1.0 以降で、TiKV API V2 が有効になっている場合は、TiDB データと RawKV データを同じ TiKV クラスターに保存できます。
それ以外の場合、TiDB データ (またはトランザクション API を使用して作成されたデータ) のキー形式は RawKV API (または他の RawKV ベースのサービスからのデータ) を使用して作成されたデータと互換性がないため、答えは「いいえ」です。

TiDBテスト

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

TiDB の Sysbench ベンチマークテストを実行するにはどうすればよいでしょうか?

Sysbenchを使用してTiDBをテストする方法参照。

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

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

したがって、これらのベンチマークテストに過度に重点を置く必要はありません。むしろ、TiDB を使用したシナリオの違いに注目することをお勧めします。

TiDB v8.5.0 のパフォーマンスについて詳しくは、 TiDB Cloud Dedicated クラスターのパフォーマンステストレポートを参照してください。

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

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

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

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

TiDBは、小規模なテーブル（1000万件未満など）には適していません。これは、データサイズが小さく、リージョンが限られている場合、その並列処理の強みを発揮できないためです。典型的な例としては、数行のレコードが頻繁に更新されるカウンターテーブルが挙げられます。TiDBでは、これらの行はstorageエンジン内で複数のキーと値のペアに変換され、単一ノード上のリージョンに格納されます。強力な一貫性を保証するためのバックグラウンドレプリケーションや、TiDBからTiKVへの操作のオーバーヘッドにより、MySQLスタンドアロンよりもパフォーマンスが低下します。

バックアップと復元

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

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

現在、大容量データ（1TB以上）のバックアップには、バックアップと復元 (BR)使用するのが推奨されます。それ以外の場合は、 Dumplingツールが推奨されます。TiDBでは、MySQL公式ツールmysqldumpもデータのバックアップと復元にサポートされていますが、そのパフォーマンスはBRに劣り、大容量データのバックアップと復元にはBRよりも多くの時間がかかります。

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

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

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