📣

TiDB Cloud Premium はパブリックプレビュー中です。エンタープライズワークロード向けの無制限のスケーリング、即時の弾力性、高度なセキュリティを提供します。このページは自動翻訳されたものです。原文はこちらからご覧ください。

TiDBクラスタ管理に関するよくある質問

このドキュメントは、TiDBクラスタ管理に関するよくある質問（FAQ）をまとめたものです。

日常管理

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

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

TiDBへのログインは、MySQLへのログインと同様の方法で行えます。例えば：

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 では、グローバルキル機能が導入されました (デフォルトで有効になっているenable-global-kill設定によって制御されます)。グローバルキルが有効になっている場合は、 kill session_idを実行するだけです。
TiDB のバージョンが v6.1.0 より前、またはグローバルキル機能が有効になっていない場合、 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つの結果は異なる方法で計算されます。 information_schema.tables.data_lengthは各行の平均長を計算して推定した値ですが、TiKV監視パネルのストアサイズは単一のTiKVインスタンス内のデータファイル（RocksDBのSSTファイル）の長さを合計したものです。
information_schema.tables.data_lengthは論理値であり、ストアサイズは物理値です。トランザクションの複数のバージョンによって生成された冗長データは論理値には含まれませんが、物理値ではTiKVによって圧縮されます。

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

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

PD管理

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

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

PD の API のほとんどは、TiKV クラスタが初期化されたときにのみ利用可能です。このメッセージは、新しいクラスタがデプロイされた際に TiKV が起動していない状態で 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ストアの各ステータス（稼働中、切断、オフライン、停止、削除済み）間の関係は何ですか？

各ステータスの関係については、 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 設定を使用します。後でレプリカ数を更新する場合は、設定コマンドconfig set max-replicas $numを使用して pd-ctl を実行し、 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サーバーインスタンスと同じ場合、上記の1番目と3番目のシナリオでは、数十ミリ秒から数百ミリ秒しかかからない可能性があります。

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

考えられる理由：

複数のDDLステートメントを同時に実行する場合、最後の数個のDDLステートメントの実行速度が遅くなる可能性があります。これは、TiDBクラスタではDDLステートメントが直列に実行されるためです。
クラスターが正常に起動した後、最初のDDL操作の実行には通常30秒程度かかる場合があります。これは、TiDBクラスターがDDLステートメントを処理するリーダーを選出しているためです。
TiDB の起動後最初の 10 分間の DDL ステートメントの処理時間は、以下の条件を満たす場合、通常よりもはるかに長くなります。1) TiDB を停止する際に、TiDB が通常のように PD と通信できない場合 (停電の場合を含む)。2) TiDB がkill -9コマンドで停止されたため、TiDB が 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サーバーあたりの最大接続数に制限はありません。必要に応じて、 instance.max_connectionsファイルでconfig.toml }を設定するか、システム変数max_connectionsの値を変更することで、最大接続数を制限できます。同時接続数が多すぎると応答時間が長くなる場合は、TiDBノードを追加して容量を増やすことをお勧めします。

テーブルの作成時間を確認するにはどうすればよいですか？

create_time内のテーブルのinformation_schemaは作成時刻です。

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 を取得し、ローカルに保存します。次に 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プロトコルに基づき、ノードのダウンにより単一のリーダーが故障した場合、別のノードのフォロワーがリース時間（10秒）の2倍の時間が経過すると、リージョンのリーダーとして選出されます。

TiKVにおいて、I/O、メモリ、CPUを大量に消費し、パラメータ設定を超えるシナリオとはどのようなものですか？

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ログに基づいて自動的に復旧されます。

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

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の値が高すぎないか確認してください。また、1台のマシンに複数のTiKVインスタンスをデプロイする場合は、複数のインスタンスがシステムメモリを過剰に使用して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の利点の1つは、並列処理を実行するためにコンピューティング処理をstorageノードにプッシュダウンできることです。

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

バックアップと復元

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

TiDBでデータをバックアップする方法は？

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

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

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

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