トポロジ ラベルごとにレプリカをスケジュールする
ノート:
TiDB v5.3.0 ではSQL の配置規則が導入されています。これにより、テーブルとパーティションの配置を構成するためのより便利な方法が提供されます。 SQL の配置ルールは、将来のリリースで配置構成を PD に置き換える可能性があります。
TiDB クラスターの高可用性と災害復旧機能を向上させるには、TiKV ノードを物理的にできるだけ分散させることをお勧めします。たとえば、TiKV ノードは、異なるラックや異なるデータ センターに分散することもできます。 TiKV のトポロジー情報に従って、PD スケジューラーはバックグラウンドで自動的にスケジューリングを実行して、リージョンの各レプリカを可能な限り分離し、災害復旧の機能を最大化します。
このメカニズムを有効にするには、デプロイ時にクラスターのトポロジー情報、特に TiKV の位置情報が PD に報告されるように、TiKV と PD を適切に構成する必要があります。始める前に、まずTiUP を使用して TiDB をデプロイを参照してください。
クラスター トポロジに基づいてlabels
を構成する
TiKV および TiFlash のlabels
を構成する
コマンドライン フラグを使用するか、TiKV または TiFlash 構成ファイルを設定して、キーと値のペアの形式でいくつかの属性をバインドできます。これらの属性はlabels
と呼ばれます。 TiKV と TiFlash が開始されると、ユーザーは TiKV と TiFlash ノードの場所を特定できるように、 labels
を PD に報告します。
トポロジーにゾーン > データセンター (DC) > ラック > ホストの 4 つのレイヤーがあり、これらのラベル (ゾーン、DC、ラック、ホスト) を使用して TiKV および TiFlash の場所を設定できるとします。 TiKV および TiFlash のラベルを設定するには、次のいずれかの方法を使用できます。
コマンドライン フラグを使用して、TiKV インスタンスを開始します。
tikv-server --labels zone=<zone>,dc=<dc>,rack=<rack>,host=<host>TiKV 構成ファイルで構成します。
[server] [server.labels] zone = "<zone>" dc = "<dc>" rack = "<rack>" host = "<host>"
TiFlash のラベルを設定するには、tiflash-proxy の構成ファイルであるtiflash-learner.toml
ファイルを使用できます。
[server]
[server.labels]
zone = "<zone>"
dc = "<dc>"
rack = "<rack>"
host = "<host>"
(オプション) TiDB のlabels
を構成する
フォロワーの読み取りが有効になっている場合、TiDB が同じリージョンからデータを読み取ることを優先する場合は、TiDB ノードにlabels
を構成する必要があります。
構成ファイルを使用して、TiDB にlabels
を設定できます。
[labels]
zone = "<zone>"
dc = "<dc>"
rack = "<rack>"
host = "<host>"
ノート:
現在、TiDB は
zone
のラベルに依存して、同じリージョンにあるレプリカを照合して選択します。この機能を使用するには、 PDlocation-labels
の構成の場合はzone
を含め、TiDB、TiKV、および TiFlash でlabels
を構成する場合はzone
を構成する必要があります。詳細については、 TiKV および TiFlash のlabels
を構成するを参照してください。
PD location-labels
を構成する
上記の説明によると、ラベルは、TiKV 属性を記述するために使用される任意のキーと値のペアにすることができます。しかし、PD は位置関連のラベルとこれらのラベルのレイヤー関係を識別できません。したがって、TiKV ノード トポロジを理解するには、PD に対して次の構成を行う必要があります。
文字列の配列として定義され、 location-labels
は PD の構成です。この構成の各項目は、TiKV labels
のキーに対応しています。さらに、各キーのシーケンスは、異なるラベルのレイヤー関係を表します (分離レベルは左から右に減少します)。
構成にはデフォルト値がないため、 location-labels
の値 ( zone
、 rack
、またはhost
など) をカスタマイズできます。また、この構成では、TiKVサーバーラベルと一致する限り、ラベル レベルの数に制限はありません (3 レベルは必須ではありません)。
ノート:
- 構成を有効にするには、PD 用に
location-labels
を構成し、TiKV 用にlabels
を同時に構成する必要があります。そうしないと、PD はトポロジーに従ってスケジューリングを実行しません。- SQL で配置ルールを使用する場合、TiKV に
labels
を設定するだけで済みます。現在、SQL の配置規則は PD のlocation-labels
構成と互換性がなく、この構成を無視します。 SQL でlocation-labels
と配置規則を同時に使用することはお勧めしません。そうしないと、予期しない結果が生じる可能性があります。
location-labels
を構成するには、クラスターの状況に応じて次のいずれかの方法を選択します。
PD クラスターが初期化されていない場合は、PD 構成ファイルで
location-labels
を構成します。[replication] location-labels = ["zone", "rack", "host"]PD クラスタがすでに初期化されている場合は、pd-ctl ツールを使用してオンラインで変更します。
pd-ctl config set location-labels zone,rack,host
PD isolation-level
を構成する
location-labels
が構成されている場合、PD 構成ファイルでisolation-level
を構成することにより、TiKV クラスターのトポロジ分離要件をさらに強化できます。
上記の手順に従ってlocation-labels
を構成して 3 層のクラスター トポロジを作成したと仮定します。ゾーン -> ラック -> ホスト、次のようにisolation-level
からzone
を構成できます。
[replication]
isolation-level = "zone"
PD クラスタがすでに初期化されている場合は、pd-ctl ツールを使用してオンラインで変更する必要があります。
pd-ctl config set isolation-level zone
location-level
構成は文字列の配列で、キーlocation-labels
に対応する必要があります。このパラメータは、TiKV トポロジ クラスタの最小および必須の分離レベル要件を制限します。
ノート:
isolation-level
はデフォルトで空です。これは、分離レベルに必須の制限がないことを意味します。これを設定するには、PD にlocation-labels
を設定し、値isolation-level
がlocation-labels
つの名前の 1 つであることを確認する必要があります。
TiUP を使用してクラスターを構成する (推奨)
TiUP を使用してクラスターをデプロイする場合、TiKV の場所を初期設定ファイルで構成できます。 TiUP は、展開中に TiKV、PD、および TiFlash に対応する構成ファイルを生成します。
次の例では、 zone/host
の 2 層トポロジーが定義されています。クラスターの TiKV ノードは、z1、z2、および z3 の 3 つのゾーンに分散され、各ゾーンには h1、h2、h3、および h4 の 4 つのホストがあります。 z1 では、4 つの TiKV インスタンスが 2 つのホスト (h1 にtikv-1
とtikv-2
、h2 にtikv-3
とtikv-4
) にデプロイされます。 h3 にtiflash-1
、h4 にtiflash-2
の 2 つの TiFlash インスタンスが他の 2 つのホストにデプロイされます。 z2 と z3 では、2 つの TiKV インスタンスが 2 つのホストにデプロイされ、2 つの TiFlash インスタンスが他の 2 つのホストにデプロイされます。次の例では、 tikv-n
はn
番目の TiKV ノードの IP アドレスを表し、 tiflash-n
はn
番目の TiFlash ノードの IP アドレスを表します。
server_configs:
pd:
replication.location-labels: ["zone", "host"]
tikv_servers:
# z1
- host: tikv-1
config:
server.labels:
zone: z1
host: h1
- host: tikv-2
config:
server.labels:
zone: z1
host: h1
- host: tikv-3
config:
server.labels:
zone: z1
host: h2
- host: tikv-4
config:
server.labels:
zone: z1
host: h2
# z2
- host: tikv-5
config:
server.labels:
zone: z2
host: h1
- host: tikv-6
config:
server.labels:
zone: z2
host: h2
# z3
- host: tikv-7
config:
server.labels:
zone: z3
host: h1
- host: tikv-8
config:
server.labels:
zone: z3
host: h2s
tiflash_servers:
# z1
- host: tiflash-1
learner_config:
server.labels:
zone: z1
host: h3
- host: tiflash-2
learner_config:
server.labels:
zone: z1
host: h4
# z2
- host: tiflash-3
learner_config:
server.labels:
zone: z2
host: h3
- host: tiflash-4
learner_config:
server.labels:
zone: z2
host: h4
# z3
- host: tiflash-5
learner_config:
server.labels:
zone: z3
host: h3
- host: tiflash-6
learner_config:
server.labels:
zone: z3
host: h4
詳細については、 地理的に分散された配置トポロジを参照してください。
ノート:
構成ファイルで
replication.location-labels
を構成していない場合、このトポロジー ファイルを使用してクラスターをデプロイすると、エラーが発生する可能性があります。クラスターをデプロイする前に、構成ファイルでreplication.location-labels
が構成されていることを確認することをお勧めします。
トポロジ ラベルに基づく PD スケジュール
PD は、同じデータの異なるレプリカが可能な限り分散されるように、ラベルレイヤーに従ってレプリカをスケジュールします。
例として、前のセクションのトポロジを取り上げます。
クラスタ レプリカの数が 3 ( max-replicas=3
) であるとします。合計で 3 つのゾーンがあるため、PD は各リージョンの 3 つのレプリカがそれぞれ z1、z2、および z3 に配置されるようにします。このようにして、1 つのデータセンターに障害が発生した場合でも、TiDB クラスターは引き続き使用できます。
次に、クラスタ レプリカの数が 5 ( max-replicas=5
) であるとします。合計で 3 つのゾーンしかないため、PD はゾーン レベルでの各レプリカの分離を保証できません。この状況では、PD スケジューラはホスト レベルでレプリカの分離を保証します。つまり、リージョンの複数のレプリカが同じゾーンに分散されていても、同じホストには分散されていない可能性があります。
5 レプリカ構成の場合、z3 に障害が発生するか、全体として分離され、一定期間 ( max-store-down-time
で制御) が経過しても回復できない場合、PD はスケジューリングによって 5 つのレプリカを構成します。現時点では、4 つのホストのみが利用可能です。これは、ホスト レベルの分離が保証されず、複数のレプリカが同じホストにスケジュールされる可能性があることを意味します。ただし、 isolation-level
の値を空のままにするのではなくzone
に設定すると、リージョンレプリカの物理的な分離の最小要件が指定されます。つまり、PD は、同じリージョンのレプリカが異なるゾーンに分散されるようにします。 PD は、この分離制限に従うことが複数のレプリカに対するmax-replicas
の要件を満たさない場合でも、対応するスケジューリングを実行しません。
たとえば、TiKV クラスターは 3 つのデータ ゾーン z1、z2、および z3 に分散されています。各リージョンには必要に応じて 3 つのレプリカがあり、PD は同じリージョンの 3 つのレプリカをこれら 3 つのデータ ゾーンにそれぞれ配布します。 z1 で停電が発生し、一定期間 (デフォルトではmax-store-down-time
分と 30 分で制御) 後に復旧できない場合、PD は z1 のリージョンレプリカが使用できなくなったと判断します。ただし、 isolation-level
がzone
に設定されているため、PD は、同じリージョンの異なるレプリカが同じデータ ゾーンでスケジュールされないことを厳密に保証する必要があります。 z2 と z3 の両方にすでにレプリカがあるため、現時点でレプリカが 2 つしかない場合でも、PD は最小分離レベルの制限であるisolation-level
の下ではスケジューリングを実行しません。
同様に、 isolation-level
がrack
に設定されている場合、最小分離レベルは同じデータ センター内の異なるラックに適用されます。この構成では、可能であればゾーンレイヤーでのアイソレーションが最初に保証されます。ゾーン レベルでの分離を保証できない場合、PD は、同じゾーン内の同じラックに異なるレプリカをスケジュールすることを回避しようとします。 PD が最初にラックの分離レベルを保証し、次にホストのレベルを保証するisolation-level
がhost
に設定されている場合、スケジューリングは同様に機能します。
要約すると、PD は現在のトポロジに従って、クラスターのディザスター リカバリーを最大化します。したがって、特定のレベルのディザスター リカバリーを達成したい場合は、トポロジーに従って、 max-replicas
の数よりも多くのマシンを異なるサイトにデプロイします。 TiDB は、さまざまなシナリオに従ってデータのトポロジ分離レベルをより柔軟に制御するために、 isolation-level
などの必須構成項目も提供します。