重要

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

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

このドキュメントは、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にあり、そこには backup、db、raft、snap の 4 つのディレクトリがあり、それぞれバックアップ、データ、 Raftデータ、およびミラーデータを格納するために使用されます。

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

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

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

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

TiDB を安全に停止するには?

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

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

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の 2 つのタイムアウトをサポートしています。

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 用のグラフィカルな展開ツールはありますか?

現在No.

TiDB クラスターをスケールアウトするには?

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

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

TiDB を水平方向にスケーリングするには?

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

ディスク容量が不足していることを意味するストレージリソースの不足。
CPU 占有率が高いなどのコンピューティングリソースの不足。
十分な書き込みおよび読み取り容量がありません。

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

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

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

詳細については、中国語の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 監視パネルのストアサイズは、1 つの TiKV インスタンス内のデータファイル (RocksDB の SST ファイル) の長さを合計したものです。
information_schema.tables.data_lengthは論理値で、ストアサイズは物理値です。複数のバージョンのトランザクションによって生成された冗長データは論理値には含まれませんが、物理値では冗長データが TiKV によって圧縮されます。

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

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

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

PD管理

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

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

PD のほとんどの API は、TiKV クラスターが初期化されている場合にのみ使用できます。 PD 起動時に PD にアクセスし、新規クラスタ配備時に TiKV を起動していない場合、このメッセージが表示されます。このメッセージが表示された場合は、TiKV クラスタを起動してください。 TiKV が初期化されると、PD がアクセス可能になります。

PD の起動時に`etcd cluster ID mismatch`メッセージが表示される

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

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- `leader-schedule-limit`と`region-schedule-limit`スケジューリングパラメーターの違いは何ですか?

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

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

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

TiKV インスタンスの総数が常に、設定したレプリカの数以上であることを確認してください。たとえば、3 つのレプリカには少なくとも 3 つの TiKV インスタンスが必要です。レプリカの数を増やす前に、追加のストレージ要件を見積もる必要があります。 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 ステートメントの処理時間は、次の条件を満たしている場合、通常の場合よりも大幅に長くなります。 ); 2) TiDB がkill -9コマンドで停止されるため、TiDB は PD からの登録データのクリーンアップに間に合いません。この期間中に DDL ステートメントを実行すると、各 DDL の状態が変化するために、2 * リース (リース = 45 秒) 待つ必要があります。
クラスター内の TiDBサーバーと PDサーバーの間で通信の問題が発生した場合、TiDBサーバーは PDサーバーからバージョン情報を取得または更新することができません。この場合、各 DDL の状態処理のために 2 * リースを待つ必要があります。

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

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

Information_schema はより現実的な`Information_schema`をサポートできますか?

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

TiDB Backoff タイプのシナリオの説明は?

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サーバーごとの最大接続数に制限はありません。同時実行数が多すぎると応答時間が長くなる場合は、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 - statistics balanceパネルで各ノードのサイズ増幅メトリックを確認することもできます。クラスター圧縮率の平均は、すべてのノードのサイズ増幅の平均です。
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 の実装によって異なります。データサイズが時々変動するのは正常です。基盤となるストレージエンジンは、必要に応じてデータを調整します。

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 がリージョンリーダーを頻繁に切り替えるのはなぜですか?

ネットワークの問題により、ノード間で通信が停止します。レポート障害監視を確認できます。
元のメインリーダーのノードがスタックしているため、時間内にフォロワーに到達できません。
Raftstore スレッドがスタックしました。

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

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

高い I/O、メモリ、CPU を使用し、パラメータ構成を超える TiKV シナリオは何ですか?

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

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

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

KeyデータテーブルのRangeはデータアクセス前に分割されていますか?

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

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

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

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

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

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

WAL は順序付けられた書き込みに属し、現在、独自の構成を適用していません。推奨構成は次のとおりです。

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

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

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

Raft + TiKVアーキテクチャの複数のレプリカは絶対的なデータの安全性を達成できますか?最も厳密なモード ( `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 には、KV インターフェイスを直接使用でき、独立したキャッシュを必要としない MySQL のような InnoDB memcached プラグインがありますか?

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

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

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

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

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

TiKVでOOM(Out of Memory)エラーが多発するのはなぜですか?

TiKV のメモリ使用量は主に RocksDB のブロックキャッシュによるもので、デフォルトではシステムメモリサイズの 40% です。 TiKV で OOM エラーが多発する場合は、 block-cache-sizeの値を大きくしすぎていないか確認してください。さらに、複数の TiKV インスタンスが 1 台のマシンにデプロイされている場合は、複数のインスタンスがシステムメモリを使いすぎて 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 書き込み容量 (Insert TPS) とノード数の関係は約 40% 直線的に増加します。 MySQL は単一ノードの書き込みを使用するため、その書き込み容量はスケーリングできません。
MySQL では、セカンダリデータベースを追加することで読み取り容量を増やすことができますが、書き込み容量はシャーディングを使用しない限り増やすことができず、多くの問題があります。
TiDB では、ノードを追加することで、読み取り容量と書き込み容量の両方を簡単に増やすことができます。

DBA による MySQL と TiDB のパフォーマンステストでは、スタンドアロンの TiDB のパフォーマンスは MySQL ほど良くないことが示されています。

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

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

バックアップと復元

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

TiDB でデータをバックアップするには?

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

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

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

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