- TiDBについて
- クイックスタート
- 発展させる
- 概要
- クイックスタート
- TiDB CloudでTiDBクラスターを構築する(DevTier)
- TiDBのCRUDSQL
- TiDBを使用してシンプルなCRUDアプリを構築する
- アプリケーション例
- TiDBに接続する
- データベーススキーマの設計
- データの書き込み
- データの読み取り
- 取引
- 最適化
- トラブルシューティング
- 参照
- デプロイ
- 移行する
- 管理
- 監視と警告
- トラブルシューティング
- TiDBトラブルシューティングマップ
- 遅いクエリを特定する
- 遅いクエリを分析する
- SQL診断
- Top SQLを使用して高価なクエリを特定する
- ログを使用して高価なクエリを特定する
- ステートメント要約表
- ホットスポットの問題のトラブルシューティング
- 読み取りと書き込みの待ち時間の増加のトラブルシューティング
- クラスタのオンサイト情報を保存および復元する
- クラスタセットアップのトラブルシューティング
- 高いディスクI/O使用量のトラブルシューティング
- ロックの競合のトラブルシューティング
- TiFlashのトラブルシューティング
- 楽観的なトランザクションでの書き込みの競合のトラブルシューティング
- データとインデックス間の不整合のトラブルシューティング
- 性能チューニング
- チューニングガイド
- 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コンポーネント
- PingCAPクリニック診断サービス(テクニカルプレビュー)
- TiDB Operator
- Dumpling
- TiDB Lightning
- TiDBデータ移行
- TiDBデータ移行について
- クイックスタート
- DMクラスタをデプロイする
- チュートリアル
- 高度なチュートリアル
- シャーディングされたテーブルからのデータのマージと移行
- GH-ost/PT-oscを使用するMySQLデータベースからの移行
- より多くの列を持つダウンストリームTiDBテーブルにデータを移行する
- 管理
- 参照
- 例
- トラブルシューティング
- リリースノート
- バックアップと復元(BR)
- TiDB Binlog
- 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
BATCH
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_POLICIES
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バージョニング
- v6.1
- v6.0
- v5.4
- v5.3
- v5.2
- v5.1
- v5.0
- v4.0
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- 用語集
配置ルール
ノート:
このドキュメントでは、配置ドライバ(PD)で配置ルールを手動で指定する方法を紹介します。現在、 SQLの配置ルールを使用することをお勧めします。これにより、テーブルとパーティションの配置を構成するためのより便利な方法が提供されます。
v5.0で導入された配置ルールは、PDがさまざまなタイプのデータに対応するスケジュールを生成するようにガイドするレプリカルールシステムです。さまざまなスケジューリングルールを組み合わせることで、レプリカの数、保存場所、ホストタイプ、Raft選挙に参加するかどうか、Raftリーダーとして機能するかどうかなど、任意の連続データ範囲の属性を細かく制御できます。
配置ルール機能は、v5.0以降のバージョンのTiDBではデフォルトで有効になっています。無効にするには、 配置ルールを無効にするを参照してください。
ルールシステム
ルールシステム全体の構成は、複数のルールで構成されています。各ルールは、レプリカの数、ラフトの役割、配置場所、このルールが有効になるキー範囲などの属性を指定できます。 PDがスケジュールを実行しているとき、PDはまず、リージョンのキー範囲に従ってルールシステム内のリージョンに対応するルールを見つけ、次に対応するスケジュールを生成して、リージョンレプリカの配布をルールに準拠させます。
複数のルールのキー範囲は重複する部分を持つ可能性があります。つまり、リージョンは複数のルールに一致する可能性があります。この場合、PDは、ルールの属性に応じて、ルールが相互に上書きするか、同時に有効になるかを決定します。複数のルールが同時に有効になる場合、PDはルールマッチングのルールのスタック順序に従って順番にスケジュールを生成します。
さらに、さまざまなソースからのルールを相互に分離するという要件を満たすために、これらのルールをより柔軟な方法で編成できます。そこで、「グループ」の概念を紹介します。一般に、ユーザーはさまざまなソースに応じてさまざまなグループにルールを配置できます。
ルールフィールド
次の表は、ルールの各フィールドの意味を示しています。
フィールド名 | タイプと制限 | 説明 |
---|---|---|
GroupID | string | ルールのソースをマークするグループID。 |
ID | string | グループ内のルールの一意のID。 |
Index | int | グループ内のルールのスタックシーケンス。 |
Override | true false | ルールを(グループ内の)より小さなインデックスで上書きするかどうか。 |
StartKey | string 進形式 | 範囲の開始キーに適用されます。 |
EndKey | string 進形式 | 範囲の終了キーに適用されます。 |
Role | string | リーダー/フォロワー/学習者を含むレプリカの役割。 |
Count | int 、正の整数 | レプリカの数。 |
LabelConstraint | []Constraint | ラベルに基づくファイラーノード。 |
LocationLabels | []string | 物理的な分離に使用されます。 |
IsolationLevel | string | 最小の物理的分離レベルを設定するために使用されます |
LabelConstraint
は、 in
、およびnotExists
のnotIn
exists
のプリミティブに基づいてラベルをフィルタリングするKubernetesの関数に似ています。これらの4つのプリミティブの意味は次のとおりです。
in
:指定されたキーのラベル値が指定されたリストに含まれます。notIn
:指定されたキーのラベル値は指定されたリストに含まれていません。exists
:指定されたラベルキーを含みます。notExists
:指定されたラベルキーは含まれません。
LocationLabels
の意味と機能は、v4.0より前のものと同じです。たとえば、3層トポロジを定義する[zone,rack,host]
をデプロイした場合、クラスタには複数のゾーン(可用性ゾーン)があり、各ゾーンには複数のラックがあり、各ラックには複数のホストがあります。スケジュールを実行するとき、PDは最初にリージョンのピアを異なるゾーンに配置しようとします。この試行が失敗した場合(レプリカが3つあるが、合計でゾーンが2つしかない場合など)、PDはこれらのレプリカを異なるラックに配置することを保証します。ラックの数が分離を保証するのに十分でない場合、PDはホストレベルの分離を試みます。
IsolationLevel
の意味と機能はクラスタートポロジ構成で詳しく説明されています。たとえば、 LocationLabels
で3層トポロジを定義し、 IsolationLevel
をzone
に設定する[zone,rack,host]
を展開した場合、PDは、スケジューリング中に各リージョンのすべてのピアが異なるゾーンに配置されるようにします。 IsolationLevel
の最小分離レベル制限を満たすことができない場合(たとえば、3つのレプリカが構成されているが、合計で2つのデータゾーンしかない場合)、PDはこの制限を満たすことを試みません。デフォルト値のIsolationLevel
は空の文字列です。これは、無効になっていることを意味します。
ルールグループのフィールド
次の表に、ルールグループの各フィールドの説明を示します。
フィールド名 | タイプと制限 | 説明 |
---|---|---|
ID | string | ルールのソースをマークするグループID。 |
Index | int | 異なるグループのスタックシーケンス。 |
Override | true false | インデックスが小さいグループをオーバーライドするかどうか。 |
ルールを構成する
このセクションの操作はpd-ctlに基づいており、操作に関連するコマンドはHTTPAPIを介した呼び出しもサポートしています。
配置ルールを有効にする
配置ルール機能は、v5.0以降のバージョンのTiDBではデフォルトで有効になっています。無効にするには、 配置ルールを無効にするを参照してください。無効にした後でこの機能を有効にするには、クラスタを初期化する前に、PD構成ファイルを次のように変更できます。
[replication]
enable-placement-rules = true
このように、PDは、クラスタが正常にブートストラップされた後にこの機能を有効にし、 max-replicas
およびlocation-labels
の構成に従って対応するルールを生成します。
{
"group_id": "pd",
"id": "default",
"start_key": "",
"end_key": "",
"role": "voter",
"count": 3,
"location_labels": ["zone", "rack", "host"],
"isolation_level": ""
}
ブートストラップされたクラスタの場合、pd-ctlを使用してオンラインで配置ルールを有効にすることもできます。
pd-ctl config placement-rules enable
PDは、 max-replicas
およびlocation-labels
の構成に基づいてデフォルトのルールも生成します。
ノート:
配置ルールを有効にすると、以前に構成した
max-replicas
とlocation-labels
は有効になりません。レプリカポリシーを調整するには、配置ルールに関連するインターフェイスを使用します。
配置ルールを無効にする
pd-ctlを使用して、配置ルール機能を無効にし、以前のスケジューリング戦略に切り替えることができます。
pd-ctl config placement-rules disable
ノート:
配置ルールを無効にした後、PDは元の
max-replicas
およびlocation-labels
構成を使用します。ルールを変更すると(配置ルールが有効になっている場合)、これら2つの構成はリアルタイムで更新されません。さらに、構成されたすべてのルールはPDに残り、次に配置ルールを有効にしたときに使用されます。
pd-ctlを使用してルールを設定する
ノート:
ルールの変更は、リアルタイムのPDスケジューリングに影響します。ルールの設定が不適切な場合、レプリカが少なくなり、システムの高可用性に影響を与える可能性があります。
pd-ctlは、次のメソッドを使用してシステム内のルールを表示することをサポートしており、出力はJSON形式のルールまたはルールリストです。
すべてのルールのリストを表示するには:
pd-ctl config placement-rules show
PDグループ内のすべてのルールのリストを表示するには:
pd-ctl config placement-rules show --group=pd
グループ内の特定のIDのルールを表示するには:
pd-ctl config placement-rules show --group=pd --id=default
リージョンに一致するルールリストを表示するには:
pd-ctl config placement-rules show --region=2
上記の例では、
2
はリージョンIDです。
ルールの追加とルールの編集は似ています。対応するルールをファイルに書き込んでから、 save
コマンドを使用してルールをPDに保存する必要があります。
cat > rules.json <<EOF
[
{
"group_id": "pd",
"id": "rule1",
"role": "voter",
"count": 3,
"location_labels": ["zone", "rack", "host"]
},
{
"group_id": "pd",
"id": "rule2",
"role": "voter",
"count": 2,
"location_labels": ["zone", "rack", "host"]
}
]
EOF
pd-ctl config placement save --in=rules.json
上記の操作は、 rule1
とrule2
をPDに書き込みます。同じGroupID
+ ID
のルールがシステムにすでに存在する場合、このルールは上書きされます。
ルールを削除するには、ルールのcount
を0
に設定するだけで、同じGroupID
+ ID
のルールが削除されます。次のコマンドは、 pd / rule2
のルールを削除します。
cat > rules.json <<EOF
[
{
"group_id": "pd",
"id": "rule2"
}
]
EOF
pd-ctl config placement save --in=rules.json
pd-ctlを使用してルールグループを構成します
すべてのルールグループのリストを表示するには:
pd-ctl config placement-rules rule-group show
特定のIDのルールグループを表示するには:
pd-ctl config placement-rules rule-group show pd
ルールグループの
index
とoverride
の属性を設定するには:pd-ctl config placement-rules rule-group set pd 100 true
ルールグループの構成を削除するには(グループにルールがある場合は、デフォルトのグループ構成を使用します):
pd-ctl config placement-rules rule-group delete pd
pd-ctlを使用して、グループとグループ内のルールをバッチ更新します
ルールグループとグループ内のすべてのルールを同時に表示および変更するには、 rule-bundle
サブコマンドを実行します。
このサブコマンドでは、 get {group_id}
を使用してグループを照会し、出力結果にルールグループとグループのルールがネストされた形式で表示されます。
pd-ctl config placement-rules rule-bundle get pd
上記のコマンドの出力:
{
"group_id": "pd",
"group_index": 0,
"group_override": false,
"rules": [
{
"group_id": "pd",
"id": "default",
"start_key": "",
"end_key": "",
"role": "voter",
"count": 3
}
]
}
出力をファイルに書き込むには、 rule-bundle get
サブコマンドに-out
引数を追加します。これは、その後の変更と保存に便利です。
pd-ctl config placement-rules rule-bundle get pd -out="group.json"
変更が完了したら、 rule-bundle set
サブコマンドを使用して、ファイル内の構成をPDサーバーに保存できます。 pd-ctlを使用してルールを設定するで説明したsave
コマンドとは異なり、このコマンドはサーバー側でこのグループのすべてのルールを置き換えます。
pd-ctl config placement-rules rule-bundle set pd -in="group.json"
pd-ctlを使用して、すべての構成を表示および変更します
pd-ctlを使用して、すべての構成を表示および変更することもできます。これを行うには、すべての構成をファイルに保存し、構成ファイルを編集してから、ファイルをPDサーバーに保存して、前の構成を上書きします。この操作でもrule-bundle
サブコマンドを使用します。
たとえば、すべての構成をrules.json
のファイルに保存するには、次のコマンドを実行します。
pd-ctl config placement-rules rule-bundle load --out="rules.json"
ファイルを編集した後、次のコマンドを実行して構成をPDサーバーに保存します。
pd-ctl config placement-rules rule-bundle save --in="rules.json"
tidb-ctlを使用して、テーブル関連のキー範囲を照会します
メタデータまたは特定のテーブルの特別な構成が必要な場合は、 tidb-ctlのkeyrange
コマンドを実行して関連するキーを照会できます。コマンドの最後に--encode
を追加することを忘れないでください。
tidb-ctl keyrange --database test --table ttt --encode
global ranges:
meta: (6d00000000000000f8, 6e00000000000000f8)
table: (7400000000000000f8, 7500000000000000f8)
table ttt ranges: (NOTE: key range might be changed after DDL)
table: (7480000000000000ff2d00000000000000f8, 7480000000000000ff2e00000000000000f8)
table indexes: (7480000000000000ff2d5f690000000000fa, 7480000000000000ff2d5f720000000000fa)
index c2: (7480000000000000ff2d5f698000000000ff0000010000000000fa, 7480000000000000ff2d5f698000000000ff0000020000000000fa)
index c3: (7480000000000000ff2d5f698000000000ff0000020000000000fa, 7480000000000000ff2d5f698000000000ff0000030000000000fa)
index c4: (7480000000000000ff2d5f698000000000ff0000030000000000fa, 7480000000000000ff2d5f698000000000ff0000040000000000fa)
table rows: (7480000000000000ff2d5f720000000000fa, 7480000000000000ff2e00000000000000f8)
ノート:
DDLおよびその他の操作により、テーブルIDが変更される可能性があるため、対応するルールを同時に更新する必要があります。
典型的な使用シナリオ
このセクションでは、配置ルールの一般的な使用シナリオを紹介します。
シナリオ1:クラスタの災害耐性を向上させるために、通常のテーブルに3つのレプリカを使用し、メタデータに5つのレプリカを使用する
キーの範囲をメタデータの範囲に制限するルールを追加し、値をcount
に設定するだけ5
。このルールの例を次に示します。
{
"group_id": "pd",
"id": "meta",
"index": 1,
"override": true,
"start_key": "6d00000000000000f8",
"end_key": "6e00000000000000f8",
"role": "voter",
"count": 5,
"location_labels": ["zone", "rack", "host"]
}
シナリオ2:5つのレプリカを2:2:1の比率で3つのデータセンターに配置します。リーダーは3番目のデータセンターに配置しないでください。
3つのルールを作成します。レプリカの数をそれぞれ2
、および2
に設定し1
。レプリカを、各ルールのlabel_constraints
までの対応するデータセンターに制限します。さらに、リーダーを必要としないデータセンターの場合はrole
をfollower
に変更します。
[
{
"group_id": "pd",
"id": "zone1",
"start_key": "",
"end_key": "",
"role": "voter",
"count": 2,
"label_constraints": [
{"key": "zone", "op": "in", "values": ["zone1"]}
],
"location_labels": ["rack", "host"]
},
{
"group_id": "pd",
"id": "zone2",
"start_key": "",
"end_key": "",
"role": "voter",
"count": 2,
"label_constraints": [
{"key": "zone", "op": "in", "values": ["zone2"]}
],
"location_labels": ["rack", "host"]
},
{
"group_id": "pd",
"id": "zone3",
"start_key": "",
"end_key": "",
"role": "follower",
"count": 1,
"label_constraints": [
{"key": "zone", "op": "in", "values": ["zone3"]}
],
"location_labels": ["rack", "host"]
}
]
シナリオ3:テーブルに2つのTiFlashレプリカを追加する
テーブルの行キーに別のルールを追加し、 count
から2
に制限します。 label_constraints
を使用して、レプリカがengine = tiflash
のノードで生成されるようにします。このルールがシステム内の他のソースからのルールと重複または競合しないようにするために、ここでは別のgroup_id
が使用されていることに注意してください。
{
"group_id": "tiflash",
"id": "learner-replica-table-ttt",
"start_key": "7480000000000000ff2d5f720000000000fa",
"end_key": "7480000000000000ff2e00000000000000f8",
"role": "learner",
"count": 2,
"label_constraints": [
{"key": "engine", "op": "in", "values": ["tiflash"]}
],
"location_labels": ["host"]
}
シナリオ4:高性能ディスクを備えた北京ノードのテーブルに2つのフォロワーレプリカを追加する
次の例は、より複雑なlabel_constraints
構成を示しています。このルールでは、レプリカはbj1
またはbj2
のマシンルームに配置する必要があり、ディスクタイプはhdd
であってはなりません。
{
"group_id": "follower-read",
"id": "follower-read-table-ttt",
"start_key": "7480000000000000ff2d00000000000000f8",
"end_key": "7480000000000000ff2e00000000000000f8",
"role": "follower",
"count": 2,
"label_constraints": [
{"key": "zone", "op": "in", "values": ["bj1", "bj2"]},
{"key": "disk", "op": "notIn", "values": ["hdd"]}
],
"location_labels": ["host"]
}
シナリオ5:テーブルをTiFlashクラスタに移行する
シナリオ3とは異なり、このシナリオでは、既存の構成に基づいて新しいレプリカを追加するのではなく、データ範囲の他の構成を強制的にオーバーライドします。したがって、既存のルールを上書きするには、十分な大きさのindex
の値を指定し、ルールグループ構成でoverride
からtrue
を設定する必要があります。
ルール:
{
"group_id": "tiflash-override",
"id": "learner-replica-table-ttt",
"start_key": "7480000000000000ff2d5f720000000000fa",
"end_key": "7480000000000000ff2e00000000000000f8",
"role": "voter",
"count": 3,
"label_constraints": [
{"key": "engine", "op": "in", "values": ["tiflash"]}
],
"location_labels": ["host"]
}
ルールグループ:
{
"id": "tiflash-override",
"index": 1024,
"override": true,
}