重要

現在表示されているページは、TiDBのアーカイブされたドキュメント (非更新) です。TiDBをご利用の場合、最新のLTS (Long Term Support) バージョンの使用を推奨します。

重要

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

トポロジラベルごとにレプリカをスケジュールする

ノート：
TiDB v5.3.0 では、 SQL の配置規則の実験的サポートが導入されました。これにより、テーブルとパーティションの配置を構成するためのより便利な方法が提供されます。 SQL の配置ルールは、将来のリリースで配置構成を PD に置き換える可能性があります。

TiDB クラスターの高可用性と災害復旧機能を向上させるには、TiKV ノードを物理的にできるだけ分散させることをお勧めします。たとえば、TiKV ノードは、異なるラックや異なるデータセンターに分散することもできます。 TiKV のトポロジー情報に従って、PD スケジューラーはバックグラウンドで自動的にスケジューリングを実行して、リージョンの各レプリカを可能な限り分離し、災害復旧の機能を最大化します。

このメカニズムを有効にするには、デプロイ時にクラスターのトポロジー情報、特に TiKV の位置情報が PD に報告されるように、TiKV と PD を適切に構成する必要があります。始める前に、まずTiUP を使用して TiDB をデプロイを参照してください。

クラスタートポロジに基づいて`labels`を構成する

TiKV の`labels`を構成する

コマンドラインフラグを使用するか、TiKV 構成ファイルを設定して、キーと値のペアの形式でいくつかの属性をバインドできます。これらの属性はlabelsと呼ばれます。 TiKV が開始されると、そのlabelsが PD に報告されるため、ユーザーは TiKV ノードの場所を特定できます。

トポロジーにゾーン > ラック > ホストの 3 つのレイヤーがあり、これらのラベル (ゾーン、ラック、ホスト) を使用して、次のいずれかの方法で TiKV の場所を設定できるとします。

コマンドラインフラグを使用して、TiKV インスタンスを開始します。
```
tikv-server --labels zone=<zone>,rack=<rack>,host=<host>
```

TiKV 構成ファイルで構成します。

[server]
labels = "zone=<zone>,rack=<rack>,host=<host>"

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 構成ファイルを生成します。

次の例では、 zone/hostの 2 層トポロジーが定義されています。クラスターの TiKV ノードは 3 つのゾーンに分散され、各ゾーンには 2 つのホストがあります。 z1 では、ホストごとに 2 つの TiKV インスタンスがデプロイされます。 z2 および z3 では、ホストごとに 1 つの TiKV インスタンスがデプロイされます。次の例では、 tikv-nはn番目の TiKV ノードの 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

詳細については、地理的に分散された配置トポロジを参照してください。

ノート：
構成ファイルで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などの必須構成項目も提供します。

トポロジ ラベルごとにレプリカをスケジュールする

クラスター トポロジに基づいてlabelsを構成する

TiKV のlabelsを構成する

PD location-labelsを構成する

PD isolation-levelを構成する