- TiDBについて
- クイックスタート
- デプロイ
- 移行する
- 管理
- アップグレード
- 規模
- バックアップと復元
- BRツールを使用する(推奨)
- タイムゾーンの構成
- 毎日のチェックリスト
- TiFlashを管理する
- TiUPを使用してTiDBを管理する
- オンラインでConfiguration / コンフィグレーションを変更する
- オンラインの安全でない回復
- 監視と警告
- トラブルシューティング
- 性能チューニング
- システムチューニング
- ソフトウェアのチューニング
- Configuration / コンフィグレーション
- コプロセッサーキャッシュ
- SQLチューニング
- チュートリアル
- TiDBツール
- 概要
- ユースケース
- ダウンロード
- TiUP
- ドキュメントマップ
- 概要
- 用語と概念
- TiUPコンポーネントを管理する
- FAQ
- トラブルシューティングガイド
- コマンドリファレンス
- 概要
- TiUPコマンド
- TiUPクラスターコマンド
- 概要
- tiup cluster audit
- tiup cluster check
- tiup cluster clean
- tiup cluster deploy
- tiup cluster destroy
- tiup cluster disable
- tiup cluster display
- tiup cluster edit-config
- tiup cluster enable
- tiup cluster help
- tiup cluster import
- tiup cluster list
- tiup cluster patch
- tiup cluster prune
- tiup cluster reload
- tiup cluster rename
- tiup cluster replay
- tiup cluster restart
- tiup cluster scale-in
- tiup cluster scale-out
- tiup cluster start
- tiup cluster stop
- tiup cluster template
- tiup cluster upgrade
- TiUPDMコマンド
- 概要
- tiup dm audit
- tiup dm deploy
- tiup dm destroy
- tiup dm disable
- tiup dm display
- tiup dm edit-config
- tiup dm enable
- tiup dm help
- tiup dm import
- tiup dm list
- tiup dm patch
- tiup dm prune
- tiup dm reload
- tiup dm replay
- tiup dm restart
- tiup dm scale-in
- tiup dm scale-out
- tiup dm start
- tiup dm stop
- tiup dm template
- tiup dm upgrade
- TiDBクラスタートポロジリファレンス
- DMクラスタートポロジリファレンス
- ミラーリファレンスガイド
- TiUPコンポーネント
- TiDB Operator
- バックアップと復元(BR)
- TiDB Binlog
- TiDB Lightning
- TiDBデータ移行
- TiDBデータ移行について
- DMの概要
- 基本的な機能
- 高度な機能
- シャーディングされたテーブルからのデータのマージと移行
- GH-ost/PT-oscを使用するMySQLデータベースからの移行
- SQL式を使用してDMLをフィルタリングする
- DMアーキテクチャ
- ベンチマーク
- クイックスタート
- データ移行シナリオ
- デプロイ
- 管理
- ツール
- クラスターのアップグレード
- データソースを作成する
- データソースの管理
- データ移行タスクの管理
- シャーディングDDLロックを手動で処理する
- 移行するMySQLインスタンスを切り替える
- 移行するテーブルのスキーマを管理する
- アラートを処理する
- デイリーチェック
- トラブルシューティング
- 性能チューニング
- 参照
- セキュリティ
- モニタリング指標
- アラートルール
- エラーコード
- FAQ
- 用語集
- 例
- リリースノート
- TiCDC
- Dumpling
- sync-diff-inspector
- TiSpark
- 参照
- クラスターアーキテクチャ
- 主要な監視指標
- セキュリティ
- 権限
- SQL
- SQL言語の構造と構文
- SQLステートメント
ADD COLUMN
ADD INDEX
ADMIN
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
ADMIN SHOW TELEMETRY
ALTER DATABASE
ALTER INDEX
ALTER INSTANCE
ALTER PLACEMENT POLICY
ALTER TABLE
ALTER USER
ANALYZE TABLE
BACKUP
BEGIN
CHANGE COLUMN
COMMIT
CHANGE DRAINER
CHANGE PUMP
CREATE [GLOBAL|SESSION] BINDING
CREATE DATABASE
CREATE INDEX
CREATE PLACEMENT POLICY
CREATE ROLE
CREATE SEQUENCE
CREATE TABLE LIKE
CREATE TABLE
CREATE USER
CREATE VIEW
DEALLOCATE
DELETE
DESC
DESCRIBE
DO
DROP [GLOBAL|SESSION] BINDING
DROP COLUMN
DROP DATABASE
DROP INDEX
DROP PLACEMENT POLICY
DROP ROLE
DROP SEQUENCE
DROP STATS
DROP TABLE
DROP USER
DROP VIEW
EXECUTE
EXPLAIN ANALYZE
EXPLAIN
FLASHBACK TABLE
FLUSH PRIVILEGES
FLUSH STATUS
FLUSH TABLES
GRANT <privileges>
GRANT <role>
INSERT
KILL [TIDB]
LOAD DATA
LOAD STATS
MODIFY COLUMN
PREPARE
RECOVER TABLE
RENAME INDEX
RENAME TABLE
REPLACE
RESTORE
REVOKE <privileges>
REVOKE <role>
ROLLBACK
SELECT
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET PASSWORD
SET ROLE
SET TRANSACTION
SET [GLOBAL|SESSION] <variable>
SHOW ANALYZE STATUS
SHOW [BACKUPS|RESTORES]
SHOW [GLOBAL|SESSION] BINDINGS
SHOW BUILTINS
SHOW CHARACTER SET
SHOW COLLATION
SHOW [FULL] COLUMNS FROM
SHOW CONFIG
SHOW CREATE PLACEMENT POLICY
SHOW CREATE SEQUENCE
SHOW CREATE TABLE
SHOW CREATE USER
SHOW DATABASES
SHOW DRAINER STATUS
SHOW ENGINES
SHOW ERRORS
SHOW [FULL] FIELDS FROM
SHOW GRANTS
SHOW INDEX [FROM|IN]
SHOW INDEXES [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW MASTER STATUS
SHOW PLACEMENT
SHOW PLACEMENT FOR
SHOW PLACEMENT LABELS
SHOW PLUGINS
SHOW PRIVILEGES
SHOW [FULL] PROCESSSLIST
SHOW PROFILES
SHOW PUMP STATUS
SHOW SCHEMAS
SHOW STATS_HEALTHY
SHOW STATS_HISTOGRAMS
SHOW STATS_META
SHOW STATUS
SHOW TABLE NEXT_ROW_ID
SHOW TABLE REGIONS
SHOW TABLE STATUS
SHOW [FULL] TABLES
SHOW [GLOBAL|SESSION] VARIABLES
SHOW WARNINGS
SHUTDOWN
SPLIT REGION
START TRANSACTION
TABLE
TRACE
TRUNCATE
UPDATE
USE
WITH
- データ型
- 関数と演算子
- クラスター化インデックス
- 制約
- 生成された列
- SQLモード
- テーブル属性
- トランザクション
- ガベージコレクション(GC)
- ビュー
- パーティショニング
- 一時的なテーブル
- 文字セットと照合
- SQLの配置ルール
- システムテーブル
mysql
- INFORMATION_SCHEMA
- 概要
ANALYZE_STATUS
CLIENT_ERRORS_SUMMARY_BY_HOST
CLIENT_ERRORS_SUMMARY_BY_USER
CLIENT_ERRORS_SUMMARY_GLOBAL
CHARACTER_SETS
CLUSTER_CONFIG
CLUSTER_HARDWARE
CLUSTER_INFO
CLUSTER_LOAD
CLUSTER_LOG
CLUSTER_SYSTEMINFO
COLLATIONS
COLLATION_CHARACTER_SET_APPLICABILITY
COLUMNS
DATA_LOCK_WAITS
DDL_JOBS
DEADLOCKS
ENGINES
INSPECTION_RESULT
INSPECTION_RULES
INSPECTION_SUMMARY
KEY_COLUMN_USAGE
METRICS_SUMMARY
METRICS_TABLES
PARTITIONS
PLACEMENT_RULES
PROCESSLIST
REFERENTIAL_CONSTRAINTS
SCHEMATA
SEQUENCES
SESSION_VARIABLES
SLOW_QUERY
STATISTICS
TABLES
TABLE_CONSTRAINTS
TABLE_STORAGE_STATS
TIDB_HOT_REGIONS
TIDB_HOT_REGIONS_HISTORY
TIDB_INDEXES
TIDB_SERVERS_INFO
TIDB_TRX
TIFLASH_REPLICA
TIKV_REGION_PEERS
TIKV_REGION_STATUS
TIKV_STORE_STATUS
USER_PRIVILEGES
VIEWS
METRICS_SCHEMA
- UI
- TiDBダッシュボード
- 概要
- 管理
- アクセス
- 概要ページ
- クラスター情報ページ
- Top SQL
- キービジュアライザーページ
- メトリクス関係グラフ
- SQLステートメント分析
- 遅いクエリページ
- クラスター診断
- 検索ログページ
- インスタンスプロファイリング
- セッションの管理とConfiguration / コンフィグレーション
- FAQ
- CLI
- コマンドラインフラグ
- Configuration / コンフィグレーションファイルのパラメーター
- システム変数
- ストレージエンジン
- テレメトリー
- エラーコード
- テーブルフィルター
- トポロジラベルによるレプリカのスケジュール
- よくある質問
- リリースノート
- すべてのリリース
- リリースタイムライン
- TiDBバージョニング
- v5.4
- v5.3
- v5.2
- v5.1
- v5.0
- v4.0
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- 用語集
古いバージョンの TiDB データベース (TiDB {{ curdocVersion }}) のドキュメントを表示しています。
PDスケジューリングのベストプラクティス
このドキュメントでは、アプリケーションを容易にするための一般的なシナリオを通じて、PDスケジューリングの原則と戦略について詳しく説明します。このドキュメントは、次のコアコンセプトを使用してTiDB、TiKV、およびPDの基本を理解していることを前提としています。
ノート:
このドキュメントは当初、TiDB3.0を対象としています。一部の機能は以前のバージョン(2.x)ではサポートされていませんが、基盤となるメカニズムは類似しており、このドキュメントは引き続き参照として使用できます。
PDスケジューリングポリシー
このセクションでは、スケジューリングシステムに関連する原則とプロセスを紹介します。
スケジューリングプロセス
スケジューリングプロセスには通常、次の3つのステップがあります。
情報を収集する
各TiKVノードは、定期的に2種類のハートビートをPDに報告します。
StoreHeartbeat
:ディスク容量、使用可能なストレージ、読み取り/書き込みトラフィックなど、ストアの全体的な情報が含まれますRegionHeartbeat
:各リージョンの範囲、ピアディストリビューション、ピアステータス、データボリューム、読み取り/書き込みトラフィックなど、リージョンの全体的な情報が含まれます
PDは、スケジュール決定のためにこの情報を収集して復元します。
演算子を生成する
さまざまなスケジューラーが、以下の考慮事項を考慮して、独自のロジックと要件に基づいて演算子を生成します。
- 異常な状態(切断、ダウン、ビジー、スペース不足)のストアにピアを追加しないでください
- 異常な状態の領域のバランスをとらないでください
- リーダーを保留中のピアに転送しないでください
- リーダーを直接削除しないでください
- さまざまなリージョンピアの物理的な分離を壊さないでください
- ラベルプロパティなどの制約に違反しないでください
演算子を実行する
演算子を実行するための一般的な手順は次のとおりです。
生成されたオペレーターは、最初に
OperatorController
によって管理されるキューに参加します。OperatorController
は、オペレーターをキューから取り出し、構成に基づいて一定量の並行性で実行します。このステップでは、各オペレーターステップを対応するリージョンリーダーに割り当てます。オペレーターは「終了」または「タイムアウト」としてマークされ、キューから削除されます。
負荷分散
リージョンは、負荷分散を実現するために主にbalance-leader
およびbalance-region
のスケジューラーに依存しています。両方のスケジューラーは、クラスタのすべてのストアに均等にリージョンを分散することを目標としていますが、焦点は別々ですbalance-leader
はリージョンリーダーと連携して着信クライアント要求のバランスを取り、 balance-region
は各リージョンピアと連携してストレージのプレッシャーを再分散し、ストレージスペースの不足などの例外を回避します。 。
balance-leader
とbalance-region
は、同様のスケジューリングプロセスを共有します。
- リソースの可用性に応じてストアを評価します。
balance-leader
またはbalance-region
は、リーダーまたはピアをスコアの高いストアからスコアの低いストアに絶えず転送します。
ただし、評価方法は異なります。 balance-leader
は店舗のリーダーに対応するすべての地域サイズの合計を使用しますが、 balance-region
の方法は比較的複雑です。各ノードの特定のストレージ容量に応じて、 balance-region
の評価方法は次のようになります。
- (ノード間のデータ分散のバランスをとるために)十分なストレージがある場合のデータ量に基づきます。
- ストレージが不十分な場合に使用可能なストレージに基づきます(異なるノードでのストレージの可用性のバランスを取るため)。
- どちらの状況も当てはまらない場合は、上記の2つの要素の加重和に基づきます。
ノードによってパフォーマンスが異なる可能性があるため、ストアごとに負荷分散の重みを設定することもできます。 leader-weight
とregion-weight
は、それぞれリーダーの重みと領域の重みを制御するために使用されます(両方のデフォルトで「1」)。たとえば、ストアのleader-weight
が「2」に設定されている場合、スケジューリングが安定した後、ノード上のリーダーの数は他のノードの数の約2倍になります。同様に、ストアのleader-weight
が「0.5」に設定されている場合、ノード上のリーダーの数は他のノードの約半分になります。
ホットリージョンのスケジューリング
ホットリージョンのスケジューリングには、 hot-region-scheduler
を使用します。 TiDB v3.0以降、プロセスは次のように実行されます。
ストアから報告された情報に基づいて、特定の期間に特定のしきい値を超える読み取り/書き込みトラフィックを判別することにより、ホットリージョンをカウントします。
負荷分散と同様の方法で、これらのリージョンを再分散します。
ホット書き込みリージョンの場合、 hot-region-scheduler
はリージョンピアとリーダーの両方を再配布しようとします。ホットリードリージョンの場合、 hot-region-scheduler
はリージョンリーダーのみを再配布します。
クラスタートポロジの認識
クラスタトポロジの認識により、PDはリージョンのレプリカを可能な限り配布できます。これが、TiKVが高可用性とディザスタリカバリ機能を保証する方法です。 PDは、バックグラウンドのすべての領域を継続的にスキャンします。 PDは、リージョンの分散が最適でないことを検出すると、ピアを置き換えてリージョンを再分散する演算子を生成します。
領域分布をチェックするコンポーネントはreplicaChecker
です。これは、無効にできないことを除いてスケジューラーに似ています。 location-labels
の構成に基づくreplicaChecker
のスケジュール。たとえば、 [zone,rack,host]
はクラスタの3層トポロジーを定義します。 PDは、最初に異なるゾーンに、またはゾーンが不十分な場合は異なるラックに(たとえば、3つのレプリカに対して2つのゾーン)、ラックが不十分な場合は異なるホストに、リージョンピアをスケジュールしようとします。
スケールダウンと障害回復
スケールダウンとは、ストアをオフラインにし、コマンドを使用して「オフライン」としてマークするプロセスを指します。 PDは、スケジューリングによってオフラインノード上のリージョンを他のノードに複製します。障害回復は、ストアに障害が発生して回復できない場合に適用されます。この場合、対応するストアにピアが分散されているリージョンはレプリカを失う可能性があり、PDが他のノードに補充する必要があります。
スケールダウンと障害回復のプロセスは基本的に同じです。 replicaChecker
は、異常な状態にあるリージョンピアを検出し、正常なストアで異常なピアを新しいピアと交換するためのオペレーターを生成します。
リージョンマージ
リージョンマージとは、隣接する小さなリージョンをマージするプロセスを指します。これは、データ削除後の多数の小さな領域または空の領域による不要なリソース消費を回避するのに役立ちます。領域のマージはmergeChecker
によって実行されます。これはreplicaChecker
と同様の方法で処理されます。PDはバックグラウンドですべての領域を継続的にスキャンし、隣接する小さな領域が見つかったときに演算子を生成します。
具体的には、新しく分割されたリージョンがsplit-merge-interval
(デフォルトでは1h
)の値を超えて存在する場合、次の条件のいずれかが発生すると、このリージョンはリージョンマージスケジューリングをトリガーします。
この領域のサイズは、
max-merge-region-size
の値(デフォルトでは20 MiB)よりも小さいです。このリージョンのキーの数は、値
max-merge-region-keys
(デフォルトでは200,000)よりも少なくなっています。
スケジュールステータスのクエリ
メトリック、pd-ctl、およびログを介して、スケジューリングシステムのステータスを確認できます。このセクションでは、メトリックとpd-ctlのメソッドを簡単に紹介します。詳細については、 PDモニタリングメトリクスとPD制御を参照してください。
オペレーターのステータス
Grafana PD / Operatorページには、オペレーターに関するメトリックが表示されます。その中には、次のものがあります。
- オペレーター作成のスケジュール:オペレーター作成情報
- オペレーターの終了時間:各オペレーターが消費する実行時間
- オペレーターステップ期間:オペレーターステップによって消費された実行時間
次のコマンドでpd-ctlを使用して、演算子を照会できます。
operator show
:現在のスケジューリングタスクで生成されたすべての演算子を照会しますoperator show [admin | leader | region]
:タイプ別に演算子を照会します
バランス状態
Grafana PD / 統計 -Balanceページには、負荷分散に関するメトリックが表示されます。その中には、次のものがあります。
- ストアリーダー/地域スコア:各ストアのスコア
- ストアリーダー/リージョン数:各ストアのリーダー/リージョンの数
- 利用可能なストア:各ストアで利用可能なストレージ
pd-ctlのstoreコマンドを使用して、各ストアの残高ステータスを照会できます。
ホットリージョンのステータス
Grafana PD / 統計ホットスポットページには、ホットリージョンに関するメトリックが表示されます。
- ホットライトリージョンのリーダー/ピアディストリビューション:ホットライトリージョンのリーダー/ピアディストリビューション
- ホットリードリージョンのリーダー分布:ホットリードリージョンのリーダー分布
次のコマンドでpd-ctlを使用して、ホットリージョンのステータスを照会することもできます。
hot read
:ホットリード領域を照会しますhot write
:ホット書き込み領域を照会しますhot store
:店舗ごとの暑い地域の分布を照会しますregion topread [limit]
:上位の読み取りトラフィックがあるリージョンを照会しますregion topwrite [limit]
:書き込みトラフィックが最も多いリージョンを照会します
地域の健康
Grafana PD / Cluster / Region healthパネルには、異常状態のリージョンに関するメトリックが表示されます。
pd-ctlとリージョンチェックコマンドを使用して、異常状態のリージョンのリストを照会できます。
region check miss-peer
:十分なピアがないリージョンを照会しますregion check extra-peer
:追加のピアがあるリージョンを照会しますregion check down-peer
:ダウンピアのあるリージョンを照会しますregion check pending-peer
:保留中のピアがあるリージョンを照会します
スケジューリング戦略を制御する
pd-ctlを使用して、次の3つの側面からスケジューリング戦略を調整できます。詳細については、 PD制御を参照してください。
スケジューラを手動で追加/削除
PDは、pd-ctlを介して直接スケジューラーを動的に追加および削除することをサポートします。例えば:
scheduler show
:システムで現在実行中のスケジューラーを表示しますscheduler remove balance-leader-scheduler
:balance-leader-schedulerを削除(無効化)しますscheduler add evict-leader-scheduler 1
:ストア1のすべてのリーダーを削除するスケジューラーを追加します
演算子を手動で追加/削除
PDは、pd-ctlを介して直接演算子を追加または削除することもサポートしています。例えば:
operator add add-peer 2 5
:ストア5のリージョン2にピアを追加しますoperator add transfer-leader 2 5
:リージョン2のリーダーをストア5に移行しますoperator add split-region 2
:リージョン2を2つのリージョンに均等に分割しますoperator remove 2
:リージョン2で現在保留中のオペレーターを削除します
スケジューリングパラメータを調整します
pd-ctlのconfig show
コマンドを使用してスケジューリング構成を確認し、 config set {key} {value}
を使用して値を調整できます。一般的な調整は次のとおりです。
leader-schedule-limit
:リーダースケジューリングの転送の同時実行性を制御しますregion-schedule-limit
:ピアスケジューリングの追加/削除の同時実行性を制御しますenable-replace-offline-replica
:ノードをオフラインにするスケジューリングを有効にするかどうかを決定しますenable-location-replacement
:リージョンの分離レベルを処理するスケジューリングを有効にするかどうかを決定しますmax-snapshot-count
:各ストアのスナップショットの送受信の最大同時実行性を制御します
一般的なシナリオでのPDスケジューリング
このセクションでは、いくつかの一般的なシナリオを通じて、PDスケジューリング戦略のベストプラクティスを示します。
リーダー/地域は均等に分散されていません
PDの評価メカニズムは、異なるストアのリーダー数とリージョン数が負荷分散ステータスを完全に反映できないことを決定します。したがって、TiKVの実際の負荷またはストレージ使用量から負荷の不均衡があるかどうかを確認する必要があります。
リーダー/地域が均等に分散されていないことを確認したら、さまざまな店舗の評価を確認する必要があります。
異なる店舗のスコアが近い場合、PDはリーダー/地域が均等に分散していると誤って信じていることを意味します。考えられる理由は次のとおりです。
- 負荷の不均衡を引き起こす高温領域があります。この場合、 ホットリージョンのスケジューリングに基づいてさらに分析する必要があります。
- 空のリージョンや小さなリージョンが多数あるため、さまざまな店舗のリーダーの数に大きな違いがあり、Raftストアに高いプレッシャーがかかります。これは、 リージョンマージのスケジューリングの時間です。
- ハードウェアとソフトウェアの環境は店舗によって異なります。それに応じて
leader-weight
とregion-weight
の値を調整して、リーダー/地域の分布を制御できます。 - その他の不明な理由。それでも、
leader-weight
とregion-weight
の値を調整して、リーダー/地域の分布を制御できます。
店舗ごとに評価に大きな違いがある場合は、オペレーターの生成と実行に特に重点を置いて、オペレーター関連の指標を調べる必要があります。主な状況は2つあります。
演算子は正常に生成されますが、スケジューリングプロセスが遅い場合は、次の可能性があります。
- スケジューリング速度は、負荷分散の目的でデフォルトで制限されています。通常のサービスに大きな影響を与えることなく、
leader-schedule-limit
またはregion-schedule-limit
をより大きな値に調整できます。さらに、max-pending-peer-count
とmax-snapshot-count
で指定された制限を適切に緩和することもできます。 - 他のスケジューリングタスクが同時に実行されているため、バランシングが遅くなります。この場合、バランシングが他のスケジューリングタスクよりも優先される場合は、他のタスクを停止するか、それらの速度を制限することができます。たとえば、バランシングの進行中に一部のノードをオフラインにすると、両方の操作で
region-schedule-limit
のクォータが消費されます。この場合、スケジューラーの速度を制限してノードを削除するか、単にenable-replace-offline-replica = false
に設定して一時的に無効にすることができます。 - スケジューリングプロセスが遅すぎます。オペレーターステップ期間メトリックをチェックして、原因を確認できます。通常、スナップショットの送受信を伴わないステップ(
TransferLeader
など)はミリ秒単位で完了する必要がありRemovePeer
が、スナップショットを含むステップ(PromoteLearner
やAddLearner
AddPeer
)は数十秒で完了すると予想されます。明らかに持続時間が長すぎる場合は、TiKVへの高圧やネットワークのボトルネックなどが原因である可能性があり、特定の分析が必要です。
- スケジューリング速度は、負荷分散の目的でデフォルトで制限されています。通常のサービスに大きな影響を与えることなく、
PDは、対応するバランシングスケジューラの生成に失敗します。考えられる理由は次のとおりです。
- スケジューラーがアクティブ化されていません。たとえば、対応するスケジューラが削除されるか、その制限が「0」に設定されます。
- その他の制約。たとえば、システムの
evict-leader-scheduler
は、リーダーが対応するストアに移行するのを防ぎます。または、labelプロパティが設定されているため、一部のストアはリーダーを拒否します。 - クラスタトポロジからの制限。たとえば、3つのデータセンターにまたがる3つのレプリカのクラスタでは、レプリカが分離されているため、各リージョンの3つのレプリカが異なるデータセンターに分散されます。これらのデータセンター間でストアの数が異なる場合、スケジューリングは各データセンター内でのみバランスの取れた状態に到達できますが、グローバルにバランスが取れているわけではありません。
ノードをオフラインにするのは遅い
このシナリオでは、関連するメトリックを介して演算子の生成と実行を調べる必要があります。
演算子が正常に生成されたが、スケジューリングプロセスが遅い場合、考えられる理由は次のとおりです。
- スケジューリング速度はデフォルトで制限されています。
leader-schedule-limit
またはreplica-schedule-limit
をより大きな値に調整できます。同様に、max-pending-peer-count
およびmax-snapshot-count
の制限を緩めることを検討できます。 - 他のスケジューリングタスクが同時に実行され、システム内のリソースを求めて競争しています。 リーダー/地域は均等に分散されていませんで解決策を参照できます。
- 単一のノードをオフラインにすると、処理される多数のリージョンリーダー(3つのレプリカの構成では約1/3)がノードに分散され、削除されます。したがって、速度は、この単一ノードによってスナップショットが生成される速度によって制限されます。リーダーを移行するために手動で
evict-leader-scheduler
を追加することにより、速度を上げることができます。
対応する演算子が生成に失敗した場合、考えられる理由は次のとおりです。
- オペレータが停止するか、
replica-schedule-limit
が「0」に設定されます。 - リージョンの移行に適切なノードはありません。たとえば、(同じラベルの)置換ノードの使用可能な容量サイズが20%未満の場合、PDは、そのノードのストレージが不足しないようにスケジューリングを停止します。このような場合、スペースを解放するには、ノードを追加するか、一部のデータを削除する必要があります。
ノードをオンラインにするのは遅い
現在、ノードのオンライン化は、バランスリージョンメカニズムによってスケジュールされています。トラブルシューティングについては、 リーダー/地域は均等に分散されていませんを参照してください。
暑い地域は均等に分散されていません
ホットリージョンのスケジューリングの問題は、通常、次のカテゴリに分類されます。
ホットリージョンはPDメトリックを介して監視できますが、スケジューリング速度はホットリージョンを時間内に再配布するのに追いつくことができません。
解決策:
hot-region-schedule-limit
をより大きな値に調整し、他のスケジューラーの制限クォータを減らして、ホットリージョンのスケジューリングを高速化します。または、hot-region-cache-hits-threshold
を小さい値に調整して、PDがトラフィックの変化に対してより敏感になるようにすることもできます。単一の領域に形成されたホットスポット。たとえば、小さなテーブルは大量のリクエストによって集中的にスキャンされます。これは、PDメトリックからも検出できます。実際に単一のホットスポットを分散することはできないため、このような領域を分割するには、手動で
split-region
演算子を追加する必要があります。一部のノードの負荷は、システム全体のボトルネックとなるTiKV関連のメトリックからの他のノードの負荷よりも大幅に高くなります。現在、PDはトラフィック分析のみを介してホットスポットをカウントするため、特定のシナリオではPDがホットスポットを識別できない可能性があります。たとえば、一部の地域で集中的なポイントルックアップ要求がある場合、トラフィックで検出することは明らかではないかもしれませんが、それでも高いQPSはキーモジュールのボトルネックにつながる可能性があります。
解決策:まず、特定のビジネスに基づいてホットリージョンが形成されるテーブルを見つけます。次に、
scatter-range-scheduler
のスケジューラーを追加して、このテーブルのすべての領域を均等に分散させます。 TiDBは、この操作を簡素化するためにHTTPAPIにインターフェイスも提供します。詳細については、 TiDB HTTP APIを参照してください。
リージョンのマージが遅い
低速スケジューリングと同様に、リージョンマージの速度は、 merge-schedule-limit
とregion-schedule-limit
の構成によって制限される可能性が高いか、リージョンマージスケジューラが他のスケジューラと競合しています。具体的には、ソリューションは次のとおりです。
システムに多数の空の領域があることがメトリックからわかっている場合は、
max-merge-region-size
とmax-merge-region-keys
を小さい値に調整して、マージを高速化できます。これは、マージプロセスにレプリカの移行が含まれるため、マージする領域が小さいほど、マージが高速になるためです。マージ演算子がすでに迅速に生成されている場合は、プロセスをさらに高速化するために、patrol-region-interval
から10ms
に設定できます(この構成項目のデフォルト値は、v5.3.0以降のバージョンのTiDBでは10ms
です)。これにより、CPU消費量が増える代わりに、領域スキャンが高速になります。多くのテーブルが作成されてから空になりました(切り捨てられたテーブルを含む)。分割テーブル属性が有効になっている場合、これらの空のリージョンをマージすることはできません。次のパラメータを調整することにより、この属性を無効にできます。
TiKV:
split-region-on-table
をfalse
に設定します。パラメータを動的に変更することはできません。PD:PD制御を使用して、クラスタの状況に必要なパラメーターを設定します。
- クラスタにTiDBインスタンスがなく、値
key-type
がraw
またはtxn
に設定されているとします。この場合、PDは、enable-cross-table-merge setting
の値に関係なく、テーブル間でリージョンをマージできます。key-type
パラメータは動的に変更できます。
config set key-type txn
- クラスタにTiDBインスタンスがあり、値
key-type
がtable
に設定されているとします。この場合、PDは、値enable-cross-table-merge
がtrue
に設定されている場合にのみ、テーブル間でリージョンをマージできます。key-type
パラメータは動的に変更できます。
config set enable-cross-table-merge true
変更が有効にならない場合は、 FAQ -TiKV / PDの変更された
toml
構成が有効にならないのはなぜですか?を参照してください。ノート:
配置ルールを有効にした後、デコードの失敗を回避するために値
key-type
を適切に切り替えます。- クラスタにTiDBインスタンスがなく、値
v3.0.4およびv2.1.16以前の場合、リージョンのapproximate_keys
は特定の状況で不正確であり(ほとんどはテーブルを削除した後に発生します)、キーの数がmax-merge-region-keys
の制約を破ります。この問題を回避するには、 max-merge-region-keys
をより大きな値に調整します。
TiKVノードのトラブルシューティング
TiKVノードに障害が発生した場合、PDはデフォルトで、対応するノードを30分後にダウン状態に設定し(構成項目max-store-down-time
でカスタマイズ可能)、関連するリージョンのレプリカのバランスを取り直します。
実際には、ノードの障害が回復不能と見なされた場合は、すぐにオフラインにすることができます。これにより、PDは別のノードですぐにレプリカを補充し、データ損失のリスクを軽減します。対照的に、ノードが回復可能であると見なされても、30分以内に回復を実行できない場合は、タイムアウト後にレプリカとリソースの無駄が不要に補充されないように、一時的にmax-store-down-time
をより大きな値に調整できます。
TiDB v5.2.0では、TiKVは低速TiKVノード検出のメカニズムを導入しています。このメカニズムは、TiKVで要求をサンプリングすることにより、1から100の範囲のスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。 evict-slow-store-scheduler
を追加して、低速ノードを検出およびスケジュールできます。 1つのTiKVのみが低速として検出され、低速スコアが上限(デフォルトでは100)に達すると、このノードのリーダーが削除されます( evict-leader-scheduler
の効果と同様)。