TiUPを使用した TiDB デプロイメントのトポロジコンフィグレーションファイル

TiUPを使用して TiDB をデプロイまたは拡張するには、クラスタートポロジを記述するトポロジファイル ( サンプル ) を用意する必要があります。

同様に、クラスタトポロジを変更するには、トポロジファイルに変更を加える必要があります。違いは、クラスタのデプロイ後は、トポロジファイル内のフィールドの一部しか変更できないことです。このドキュメントでは、トポロジファイルの各セクションと、各セクション内の各フィールドについて説明します。

TiUPを使用して TiDB クラスターをデプロイすると、Prometheus、Grafana、Alertmanager などの監視サーバーもデプロイされます。また、このクラスターをスケールアウトすると、 TiUP は新しいノードを監視範囲に追加します。上記の監視サーバーの設定をカスタマイズするには、 監視サーバーの構成をカスタマイズするの手順に従ってください。

ファイル構造

TiUPを使用した TiDB デプロイメントのトポロジ構成ファイルには、次のセクションが含まれる場合があります。

• グローバル : クラスターのグローバル設定。一部の設定項目はデフォルト値を使用しますが、インスタンスごとに個別に設定できます。
• 監視 : 監視サービス（blackbox_exporterとnode_exporterのコンフィグレーション。各マシンにnode_exporterとblackbox_exporterデプロイされています。
• サーバー構成 : コンポーネントのグローバル設定。各コンポーネントを個別に設定できます。インスタンスに同じ名前の設定項目が存在する場合、インスタンスの設定項目が有効になります。
• コンポーネントバージョン : コンポーネントバージョン。コンポーネントがクラスタバージョンを使用しない場合に設定できます。このセクションはtiup-cluster v1.14.0で導入されました。
• pd_servers : PDインスタンスの構成。この構成では、PDコンポーネントがデプロイされるマシンを指定します。
• tidb_servers : TiDBインスタンスの構成。この構成では、TiDBコンポーネントがデプロイされるマシンを指定します。
• tikv_servers : TiKVインスタンスの構成。この構成では、TiKVコンポーネントがデプロイされるマシンを指定します。
• tiflash_servers : TiFlashインスタンスの構成。この構成では、 TiFlashコンポーネントがデプロイされるマシンを指定します。
• tiproxy_servers : TiProxyインスタンスの構成。この構成は、TiProxyコンポーネントがデプロイされるマシンを指定します。
• ポンプサーバー : Pumpインスタンスの構成。この構成では、 Pumpコンポーネントがデプロイされるマシンを指定します。
• ドレイナーサーバー : Drainerインスタンスの構成。この構成では、 Drainerコンポーネントがデプロイされるマシンを指定します。
• kvcdc_servers : インスタンスTiKV-CDCの構成。この構成では、TiKV-CDCコンポーネントがデプロイされるマシンを指定します。
• cdc_servers : TiCDCインスタンスの構成。この構成では、TiCDCコンポーネントがデプロイされるマシンを指定します。
• tispark_masters : TiSpark マスターインスタンスの構成。この構成では、TiSpark マスターコンポーネントがデプロイされるマシンを指定します。TiSpark マスターのノードは 1 つだけデプロイできます。
• tispark_workers : TiSparkワーカーインスタンスの構成。この構成では、TiSparkワーカーコンポーネントがデプロイされるマシンを指定します。
• 監視サーバー : PrometheusとNGMonitoringがデプロイされるマシンを指定します。TiUPは複数のPrometheusインスタンスのデプロイをサポートしていますが、最初のインスタンスのみが使用されます。
• grafana_servers : Grafanaインスタンスの設定。この設定では、Grafanaがデプロイされるマシンを指定します。
• アラートマネージャーサーバー : Alertmanagerインスタンスの設定。この設定では、Alertmanagerがデプロイされるマシンを指定します。

global

globalセクションはクラスターのグローバル構成に対応し、次のフィールドがあります。

• user : デプロイされたクラスターを起動するために使用するユーザー。デフォルト値は"tidb"です。4 <user>に指定されたユーザーがターゲットマシン上に存在しない場合、このユーザーは自動的に作成されます。

• group : ユーザーが所属するユーザーグループ。ユーザー作成時に指定されます。デフォルト値は<user>のフィールドの値です。指定されたグループが存在しない場合は、自動的に作成されます。

• systemd_mode : クラスタのデプロイメント時にターゲットマシンで使用されるsystemdモードを指定します。デフォルト値はsystemです。 userに設定すると、ターゲットマシンでsudo権限は不要になり、 TiUP no-sudo モード使用されます。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。デフォルト値は22です。

• enable_tls : クラスタでTLSを有効にするかどうかを指定します。TLSを有効にすると、生成されたTLS証明書はコンポーネント間またはクライアントとコンポーネント間の接続に使用する必要があります。デフォルト値はfalseです。

• listen_host : デフォルトのリスニングIPアドレスを指定します。空の場合、各インスタンスは、 hostフィールドに:含まれているかどうかに基づいて、自動的に::または0.0.0.0に設​​定します。このフィールドはtiup-cluster v1.14.0で導入されました。

• deploy_dir : 各コンポーネントの配置ディレクトリ。デフォルト値は"deployed"です。適用ルールは以下のとおりです。

  • インスタンス レベルで絶対パスdeploy_dirが設定されている場合、実際のデプロイメント ディレクトリはインスタンスに対してdeploy_dir設定されます。

  • 各インスタンスに対してdeploy_dir設定しない場合、デフォルト値は相対パス<component-name>-<component-port>になります。

  • global.deploy_dirが絶対パスの場合、コンポーネントは<global.deploy_dir>/<instance.deploy_dir>ディレクトリにデプロイされます。

  • global.deploy_dirが相対パスの場合、コンポーネントは/home/<global.user>/<global.deploy_dir>/<instance.deploy_dir>ディレクトリにデプロイされます。

• data_dir : データディレクトリ。デフォルト値: "data" 。適用ルールは以下のとおりです。

  • インスタンス レベルで絶対パスdata_dirが設定されている場合、実際のデプロイメント ディレクトリはインスタンスに対してdata_dir設定されます。

  • 各インスタンスに対してdata_dir設定しない場合、デフォルト値は<global.data_dir>なります。

  • data_dirが相対パスの場合、コンポーネントデータは<deploy_dir>/<data_dir>に配置されます。 <deploy_dir>の計算規則については、 deploy_dirフィールドの適用規則を参照してください。

• log_dir : ログディレクトリ。デフォルト値: "log" 。適用ルールは以下のとおりです。

  • 絶対パスlog_dirインスタンス レベルで構成されている場合、実際のログ ディレクトリはインスタンスに構成されているlog_dirなります。

  • 各インスタンスに対してlog_dir設定しない場合、デフォルト値は<global.log_dir>なります。

  • log_dir相対パスの場合、コンポーネントログは<deploy_dir>/<log_dir>に配置されます。 <deploy_dir>の計算規則については、 deploy_dirフィールドの適用規則を参照してください。

• os : ターゲットマシンのオペレーティングシステム。このフィールドは、ターゲットマシンにプッシュされるコンポーネントをどのオペレーティングシステムに適応させるかを制御します。デフォルト値は「linux」です。

• arch : ターゲットマシンのCPUアーキテクチャ。このフィールドは、ターゲットマシンにプッシュされるバイナリパッケージをどのプラットフォームに適合させるかを制御します。サポートされている値は「amd64」と「arm64」です。デフォルト値は「amd64」です。

• resource_control : ランタイムリソース制御。このフィールドのすべての設定は、systemd のサービスファイルに書き込まれます。デフォルトでは制限はありません。制御可能なリソースは以下のとおりです。

  • memory_limit : 最大ランタイムメモリを制限します。たとえば、「2G」は最大2GBのメモリが使用できることを意味します。

  • cpu_quota : 実行時のCPU使用率の上限を制限します。例：200%

  • io_read_bandwidth_max : ディスク読み取りの最大I/O帯域幅を制限します。例： "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 100M" 。

  • io_write_bandwidth_max : ディスク書き込みの最大I/O帯域幅を制限します。例： /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 100M 。

  • limit_core : コアダンプのサイズを制御します。

global構成の例は次のとおりです。

global:
  user: "tidb"
  resource_control:
    memory_limit: "2G"

上記の構成では、 tidbユーザーを使用してクラスターを起動します。同時に、各コンポーネントの実行中のメモリは最大2GBに制限されます。

monitored

monitoredターゲットマシンの監視サービスを設定するために使用されます: node_exporterおよびblackbox_exporter 。以下のフィールドが含まれます:

• node_exporter_port : サービスポートnode_exporterデフォルト値は9100です。

• blackbox_exporter_port : サービスポートblackbox_exporterデフォルト値は9115です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• data_dir : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに従ってディレクトリが生成されます。

• log_dir : ログディレクトリを指定します。指定しない場合、または相対ディレクトリで指定した場合は、 globalで設定したlog_dirディレクトリに従ってログが生成されます。

monitored構成の例は次のとおりです。

monitored:
  node_exporter_port: 9100
  blackbox_exporter_port: 9115

上記の構成では、 node_exporter 9100ポートを使用し、 blackbox_exporter 9115ポートを使用するように指定しています。

server_configs

server_configs 、サービスの設定とglobalコンポーネントの設定ファイルの生成に使用されます。2 セクションと同様に、このセクションの設定は、インスタンス内の同名の設定によって上書きできます。4 server_configsは主に以下のフィールドが含まれます。

• tidb : TiDBサービス関連の設定。詳細な設定についてはTiDB構成ファイル参照してください。

• tikv : TiKVサービス関連の設定。詳細な設定についてはTiKV設定ファイル参照してください。

• pd ：PDサービス関連の設定。詳細な設定についてはPD設定ファイル参照してください。

• tiflash : TiFlashサービス関連の設定。詳細な設定についてはTiFlash設定ファイル参照してください。

• tiflash_learner ：各TiFlashノードには特別なTiKVが組み込まれています。この設定項目は、この特別なTiKVを設定するために使用されます。通常、この設定項目の内容を変更することは推奨されません。

• tiproxy : TiProxyサービス関連の設定。詳細な設定についてはTiProxy設定ファイル参照してください。

• pump ：Pumpサービス関連の設定。詳細な設定については、 TiDBBinlog構成ファイル参照してください。

• drainer :Drainerサービス関連の設定。詳細な設定については、 TiDBBinlog構成ファイル参照してください。

• cdc : TiCDCサービス関連の設定。詳細な設定についてはTiCDCをデプロイ参照してください。

server_configs構成の例は次のとおりです。

server_configs:
  tidb:
    lease: "45s"
    split-table: true
    token-limit: 1000
    instance.tidb_enable_ddl: true
  tikv:
    log-level: "info"
    readpool.unified.min-thread-count: 1

上記の構成は、TiDB と TiKV のグローバル構成を指定します。

component_versions

注記：

TiDB、TiKV、PD、TiCDC など、バージョン番号を共有するコンポーネントについては、混在バージョンのデプロイメントシナリオで正常に動作することを保証するための完全なテストは用意されていません。このセクションはテスト環境でのみ使用するか、 テクニカルサポートの支援を受けて使用してください。

component_versions 、特定のコンポーネントのバージョン番号を指定するために使用されます。

• component_versions設定されていない場合、各コンポーネントは TiDB クラスターと同じバージョン番号 (PD や TiKV など) を使用するか、最新バージョン (Alertmanager など) を使用します。
• component_versions設定されている場合、対応するコンポーネントは指定されたバージョンを使用し、このバージョンは後続のクラスターのスケーリングおよびアップグレード操作で使用されます。

特定のバージョンのコンポーネントを使用する必要がある場合にのみ構成するようにしてください。

component_versionsには次のフィールドが含まれます。

• tikv : TiKVコンポーネントのバージョン
• tiflash : TiFlashコンポーネントのバージョン
• pd : PDコンポーネントのバージョン
• tidb_dashboard : スタンドアロンの TiDB ダッシュボードコンポーネントのバージョン
• pump :Pumpコンポーネントのバージョン
• drainer : Drainerコンポーネントのバージョン
• cdc : CDCコンポーネントのバージョン
• kvcdc : TiKV-CDCコンポーネントのバージョン
• tiproxy : TiProxyコンポーネントのバージョン
• prometheus : Prometheusコンポーネントのバージョン
• grafana : Grafanaコンポーネントのバージョン
• alertmanager : Alertmanagerコンポーネントのバージョン

以下はcomponent_versionsの構成例です。

component_versions:
  kvcdc: "v1.1.1"

上記の構成では、TiKV-CDC のバージョン番号をv1.1.1に指定しています。

pd_servers

pd_servers PDサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定しますpd_serversは配列であり、配列の各要素には以下のフィールドが含まれます。

• host : PDサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。

• listen_host : マシンに複数のIPアドレスがある場合、 listen_hostサービスのリスニングIPアドレスを指定します。デフォルト値は0.0.0.0です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• name : PDインスタンスの名前を指定します。異なるインスタンスにはそれぞれ一意の名前を付ける必要があります。そうでない場合、インスタンスをデプロイできません。

• client_port : PDがクライアントへの接続に使用するポートを指定します。デフォルト値は2379です。

• peer_port : PD間の通信ポートを指定します。デフォルト値は2380です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• data_dir : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに従ってディレクトリが生成されます。

• log_dir : ログディレクトリを指定します。指定しない場合、または相対ディレクトリで指定した場合は、 globalで設定したlog_dirディレクトリに従ってログが生成されます。

• numa_node : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンにヌマクトルインストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーはヌマクトル使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。

• config : このフィールドの設定ルールは、 server_configsのpd設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容はserver_configsのpd内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 hostで指定されたマシンに送信されます。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はglobalのresource_control内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd 設定ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの設定ルールは、 globalのresource_control内容と同じです。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• listen_host
• name
• client_port
• peer_port
• deploy_dir
• data_dir
• log_dir
• arch
• os

pd_servers構成の例は次のとおりです。

pd_servers:
  - host: 10.0.1.11
    config:
      schedule.max-merge-region-size: 20
      schedule.max-merge-region-keys: 200000
  - host: 10.0.1.12

上記の設定では、 PD が10.0.1.11と10.0.1.12にデプロイされることを指定し、 10.0.1.11の PD に対して特定の設定を行います。

tidb_servers

tidb_servers TiDB サービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定しますtidb_serversは配列であり、配列の各要素には以下のフィールドが含まれます。

• host : TiDBサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。

• listen_host : マシンに複数のIPアドレスがある場合、 listen_hostサービスのリスニングIPアドレスを指定します。デフォルト値は0.0.0.0です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• port : TiDBサービスのリスニングポート。MySQLクライアントへの接続に使用されます。デフォルト値は4000です。

• status_port : TiDBステータスサービスのリスニングポート。HTTPリクエストを介して外部からTiDBサービスのステータスを確認するために使用されます。デフォルト値は10080です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• log_dir : ログディレクトリを指定します。指定しない場合、または相対ディレクトリで指定した場合は、 globalで設定したlog_dirディレクトリに従ってログが生成されます。

• numa_node : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンにヌマクトルインストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーはヌマクトル使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。

• config : このフィールドの設定ルールは、 server_configsのtidb設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容はserver_configsのtidb内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 hostで指定されたマシンに送信されます。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はglobalのresource_control内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd 設定ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの設定ルールは、 globalのresource_control内容と同じです。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• listen_host
• port
• status_port
• deploy_dir
• log_dir
• arch
• os

tidb_servers構成の例は次のとおりです。

tidb_servers:
  - host: 10.0.1.14
    config:
      log.level: warn
      log.slow-query-file: tidb-slow-overwrited.log
  - host: 10.0.1.15

tikv_servers

tikv_servers TiKV サービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定しますtikv_serversは配列であり、配列の各要素には以下のフィールドが含まれます。

• host : TiKVサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。

• listen_host : マシンに複数のIPアドレスがある場合、 listen_hostサービスのリスニングIPアドレスを指定します。デフォルト値は0.0.0.0です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• port : TiKVサービスのリスニングポート。デフォルト値は20160です。

• status_port : TiKVステータスサービスのリスニングポート。デフォルト値は20180です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• data_dir : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに従ってディレクトリが生成されます。

• log_dir : ログディレクトリを指定します。指定しない場合、または相対ディレクトリで指定した場合は、 globalで設定したlog_dirディレクトリに従ってログが生成されます。

• numa_node : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンにヌマクトルインストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーはヌマクトル使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。

• config : このフィールドの設定ルールは、 server_configsのtikv設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容はserver_configsのtikv内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 hostで指定されたマシンに送信されます。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はglobalのresource_control内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd 設定ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの設定ルールは、 globalのresource_control内容と同じです。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• listen_host
• port
• status_port
• deploy_dir
• data_dir
• log_dir
• arch
• os

tikv_servers構成の例は次のとおりです。

tikv_servers:
  - host: 10.0.1.14
    config:
      server.labels: { zone: "zone1", host: "host1" }
  - host: 10.0.1.15
    config:
      server.labels: { zone: "zone1", host: "host2" }

tiflash_servers

tiflash_servers 、 TiFlashサービスが展開されるマシンを指定します。また、各マシンにおけるサービス構成も指定します。このセクションは配列であり、配列の各要素には以下のフィールドが含まれます。

• host : TiFlashサービスが展開されるマシンを指定します。このフィールド値は IP アドレスで、必須です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• tcp_port : 内部テスト用のTiFlash TCPサービスのポート。デフォルト値は9000です。TiUP v1.12.5以降、この設定項目はv7.1.0以降のクラスターでは有効になりません。

• flash_service_port : TiFlashがサービスを提供するポート。TiDBはこのポートを介してTiFlashからデータを読み取ります。デフォルト値は3930です。

• metrics_port : TiFlashのステータスポート。メトリックデータの出力に使用されます。デフォルト値は8234です。

• flash_proxy_port : 内蔵TiKVのポート。デフォルト値は20170です。

• flash_proxy_status_port : 内蔵TiKVのステータスポート。デフォルト値は20292です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• data_dir : データディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに従ってディレクトリが生成されます。TiFlashは、カンマで区切られた複数のdata_dirディレクトリをサポートしています。

• log_dir : ログディレクトリを指定します。指定しない場合、または相対ディレクトリで指定した場合は、 globalで設定したlog_dirディレクトリに従ってログが生成されます。

• tmp_path : TiFlash一時ファイルのstorageパス。デフォルト値は[ pathまたはstorage.latest.dirの最初のディレクトリ] + "/tmp"です。

• numa_node : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンにヌマクトルインストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーはヌマクトル使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。

• config : このフィールドの設定ルールは、 server_configsのtiflash設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容はserver_configsのtiflash内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 hostで指定されたマシンに送信されます。

• learner_config ：各TiFlashノードには特別なTiKVが組み込まれています。この設定項目は、この特別なTiKVを設定するために使用されます。通常、この設定項目の内容を変更することは推奨されません。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はglobalのresource_control内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd 設定ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの設定ルールは、 globalのresource_control内容と同じです。

デプロイ後は、上記のフィールドについては、ディレクトリをdata_dirにのみ追加できます。以下のフィールドについては、これらのフィールドを変更することはできません。

• host
• tcp_port
• flash_service_port
• flash_proxy_port
• flash_proxy_status_port
• metrics_port
• deploy_dir
• log_dir
• tmp_path
• arch
• os

tiflash_servers構成の例は次のとおりです。

tiflash_servers:
  - host: 10.0.1.21
  - host: 10.0.1.22

tiproxy_servers

tiproxy_servers 、TiProxy サービスが展開されるマシンと、各マシン上のサービスの構成を指定します。2 tiproxy_servers配列であり、配列の各要素には次のフィールドが含まれます。

• host : TiProxyサービスがデプロイされているマシンのIPアドレスを指定します。このフィールドは必須です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• port : TiProxy SQL サービスのリスニングポート。デフォルト値は6000です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに基づいてディレクトリが生成されます。

• data_dir : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに基づいてディレクトリが生成されます。

• numa_node : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、ターゲットマシンにヌマクトルインストールされていることを確認してください。このフィールドを指定した場合、cpubindおよびmembindポリシーはヌマクトルを使用して割り当てられます。このフィールドは文字列型です。値はNUMAノードのID（例： "0,1" ）です。

• config : このフィールドの設定ルールは、 server_configsのtiproxy設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容はserver_configsのtiproxy内容と結合されます。これら 2 つのフィールドが重複している場合、このフィールドの内容が有効になります。その後、設定ファイルが生成され、 hostで指定されたマシンに送信されます。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

上記のフィールドのうち、次の設定済みフィールドは、デプロイメント後に変更できません。

• host
• port
• deploy_dir
• data_dir
• arch
• os

tiproxy_servers構成の例は次のとおりです。

tiproxy_servers:
  - host: 10.0.1.21
  - host: 10.0.1.22

pump_servers

pump_servers 、TiDB BinlogのPumpサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定しますpump_serversは配列であり、配列の各要素には以下のフィールドが含まれます。

• host : Pumpサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• port :Pumpサービスのリスニングポート。デフォルト値は8250です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• data_dir : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに従ってディレクトリが生成されます。

• log_dir : ログディレクトリを指定します。指定しない場合、または相対ディレクトリで指定した場合は、 globalで設定したlog_dirディレクトリに従ってログが生成されます。

• numa_node : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンにヌマクトルインストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーはヌマクトル使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。

• config : このフィールドの設定ルールは、 server_configsのpump設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容はserver_configsのpump内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 hostで指定されたマシンに送信されます。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はglobalのresource_control内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd 設定ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの設定ルールは、 globalのresource_control内容と同じです。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• port
• deploy_dir
• data_dir
• log_dir
• arch
• os

pump_servers構成の例は次のとおりです。

pump_servers:
  - host: 10.0.1.21
    config:
      gc: 7
  - host: 10.0.1.22

drainer_servers

drainer_servers 、TiDB BinlogのDrainerサービスがデプロイされているマシンを指定します。また、各マシンにおけるサービス設定も指定しますdrainer_servers配列です。各配列要素には以下のフィールドが含まれます。

• host : Drainerサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• port : Drainerサービスのリスニングポート。デフォルト値は8249です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• data_dir : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに従ってディレクトリが生成されます。

• log_dir : ログディレクトリを指定します。指定しない場合、または相対ディレクトリで指定した場合は、 globalで設定したlog_dirディレクトリに従ってログが生成されます。

• commit_ts （非推奨）: Drainer は起動時にチェックポイントを読み取ります。Drainerがチェックポイントを取得できない場合、このフィールドを初期起動時のレプリケーション時刻として使用します。このフィールドのデフォルトは-1です（Drainer は常に PD から最新のタイムスタンプを commit_ts として取得します）。

• numa_node : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンにヌマクトルインストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーはヌマクトル使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。

• config : このフィールドの設定ルールは、 server_configsのdrainer設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容はserver_configsのdrainer内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 hostで指定されたマシンに送信されます。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はglobalのresource_control内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd 設定ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの設定ルールは、 globalのresource_control内容と同じです。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• port
• deploy_dir
• data_dir
• log_dir
• arch
• os

commit_tsフィールドはTiUP v1.9.2 以降非推奨となり、 Drainerの起動スクリプトには記録されません。このフィールドを引き続き使用する必要がある場合は、次の例を参照してconfigのinitial-commit-tsフィールドを設定してください。

drainer_servers構成の例は次のとおりです。

drainer_servers:
  - host: 10.0.1.21
    config:
      initial-commit-ts: -1
      syncer.db-type: "mysql"
      syncer.to.host: "127.0.0.1"
      syncer.to.user: "root"
      syncer.to.password: ""
      syncer.to.port: 3306
      syncer.ignore-table:
        - db-name: test
          tbl-name: log
        - db-name: test
          tbl-name: audit

kvcdc_servers

kvcdc_servers 、 TiKV-CDCサービスがデプロイされるマシンを指定します。また、各マシンにおけるサービス構成も指定しますkvcdc_serversは配列です。各配列要素には以下のフィールドが含まれます。

• host : TiKV-CDC サービスがデプロイされるマシンを指定します。このフィールド値は IP アドレスで、必須です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• port : TiKV-CDCサービスのリスニングポート。デフォルト値は8600です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• data-dir : TiKV-CDC が主にソート用の一時ファイルを保存するディレクトリを指定します（オプション）。このディレクトリの空きディスク容量は 500 GiB 以上が推奨されます。

• log_dir : ログディレクトリを指定します。指定しない場合、または相対ディレクトリで指定した場合は、 globalで設定したlog_dirディレクトリに従ってログが生成されます。

• gc-ttl : TiKV-CDC（オプション）によってPDに設定されるサービスレベルGCセーフポイントのTTL（Time to Live、秒単位）。これはレプリケーションタスクを一時停止できる期間で、デフォルトは86400 （24時間）です。レプリケーションタスクの一時停止は、TiKVガベージコレクションセーフポイントの進行状況に影響することに注意してください。 gc-ttl長いほど、変更フィードを一時停止できる時間は長くなりますが、同時に、より多くの古いデータが保持され、より多くのスペースを占有することになります。逆もまた同様です。

• tz : TiKV-CDCサービスが使用するタイムゾーン。TiKV-CDCは、タイムスタンプなどの時間データ型を内部的に変換する際、および下流にデータを複製する際にこのタイムゾーンを使用します。デフォルト値は、プロセスが実行されるローカルタイムゾーンです。

• numa_node : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンにヌマクトルインストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーはヌマクトル使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。

• config : TiKV-CDC が使用する構成ファイルのアドレス (オプション)。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はglobalのresource_control内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd 設定ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの設定ルールは、 globalのresource_control内容と同じです。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• port
• deploy_dir
• data_dir
• log_dir
• arch
• os

kvcdc_servers構成の例は次のとおりです。

kvcdc_servers:
  - host: 10.0.1.21
  - host: 10.0.1.22

cdc_servers

cdc_servers TiCDCサービスがデプロイされるマシンを指定します。また、各マシンにおけるサービス構成も指定しますcdc_serversは配列です。各配列要素には以下のフィールドが含まれます。

• host : TiCDC サービスがデプロイされるマシンを指定します。このフィールド値は IP アドレスで、必須です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• port : TiCDCサービスのリスニングポート。デフォルト値は8300です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• data_dir : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに従ってディレクトリが生成されます。

• log_dir : ログディレクトリを指定します。指定しない場合、または相対ディレクトリで指定した場合は、 globalで設定したlog_dirディレクトリに従ってログが生成されます。

• gc-ttl : TiCDCによってPDに設定されるサービスレベルGCセーフポイントのTime To Live（TTL）期間（秒）。デフォルト値は86400 （24時間）です。

• tz : TiCDCサービスが使用するタイムゾーン。TiCDCは、タイムスタンプなどの時間データ型を内部的に変換する際、および下流にデータを複製する際にこのタイムゾーンを使用します。デフォルト値は、プロセスが実行されるローカルタイムゾーンです。

• numa_node : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンにヌマクトルインストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーはヌマクトル使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。

• config : フィールドの内容はserver_configsのcdc内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 hostで指定されたマシンに送信されます。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はglobalのresource_control内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd 設定ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの設定ルールは、 globalのresource_control内容と同じです。

• ticdc_cluster_id : サービスに対応するTiCDCクラスタIDを指定します。このフィールドが指定されていない場合、サービスはデフォルトのTiCDCクラスタに参加します。このフィールドはTiDB v6.3.0以降のバージョンでのみ有効です。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• port
• deploy_dir
• data_dir
• log_dir
• arch
• os
• ticdc_cluster_id

cdc_servers構成の例は次のとおりです。

cdc_servers:
  - host: 10.0.1.20
    gc-ttl: 86400
    data_dir: "/cdc-data"
  - host: 10.0.1.21
    gc-ttl: 86400
    data_dir: "/cdc-data"

tispark_masters

tispark_masters 、TiSpark のマスターノードがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定しますtispark_mastersは配列です。各配列要素には以下のフィールドが含まれます。

• host : TiSparkマスターがデプロイされているマシンを指定します。このフィールド値はIPアドレスで、必須です。

• listen_host : マシンに複数のIPアドレスがある場合、 listen_hostサービスのリスニングIPアドレスを指定します。デフォルト値は0.0.0.0です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• port : Sparkのリスニングポート。ノード前の通信に使用されます。デフォルト値は7077です。

• web_port : SparkのWebポート。Webサービスとタスクステータスを提供します。デフォルト値は8080です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• java_home : 使用するJRE環境のパスを指定します。このパラメータはシステム環境変数JAVA_HOMEに対応します。

• spark_config : TiSparkサービスを構成するための設定を行います。その後、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

• spark_env : Spark の起動時に環境変数を構成します。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• listen_host
• port
• web_port
• deploy_dir
• arch
• os

tispark_masters構成の例は次のとおりです。

tispark_masters:
  - host: 10.0.1.21
    spark_config:
      spark.driver.memory: "2g"
      spark.eventLog.enabled: "False"
      spark.tispark.grpc.framesize: 2147483647
      spark.tispark.grpc.timeout_in_sec: 100
      spark.tispark.meta.reload_period_in_sec: 60
      spark.tispark.request.command.priority: "Low"
      spark.tispark.table.scan_concurrency: 256
    spark_env:
      SPARK_EXECUTOR_CORES: 5
      SPARK_EXECUTOR_MEMORY: "10g"
      SPARK_WORKER_CORES: 5
      SPARK_WORKER_MEMORY: "10g"
  - host: 10.0.1.22

tispark_workers

tispark_workers 、TiSpark のワーカーノードがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定しますtispark_workersは配列です。各配列要素には以下のフィールドが含まれます。

• host : TiSparkワーカーがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。

• listen_host : マシンに複数のIPアドレスがある場合、 listen_hostサービスのリスニングIPアドレスを指定します。デフォルト値は0.0.0.0です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• port : Sparkのリスニングポート。ノード前の通信に使用されます。デフォルト値は7077です。

• web_port : SparkのWebポート。Webサービスとタスクステータスを提供します。デフォルト値は8080です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• java_home : 使用するJRE環境のパスを指定します。このパラメータはシステム環境変数JAVA_HOMEに対応します。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• listen_host
• port
• web_port
• deploy_dir
• arch
• os

tispark_workers構成の例は次のとおりです。

tispark_workers:
  - host: 10.0.1.22
  - host: 10.0.1.23

monitoring_servers

monitoring_servers 、Prometheus サービスがデプロイされるマシンを指定します。また、各マシンにおけるサービス設定も指定しますmonitoring_serversは配列です。各配列要素には以下のフィールドが含まれます。

• host : 監視サービスがデプロイされているマシンを指定します。このフィールド値はIPアドレスで、必須です。

• ng_port : NgMonitoringがリッスンするポートを指定します。TiUP TiUPで導入されたこのフィールドは、 継続的なプロファイリングとTop SQLサポートします。デフォルト値は12020です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• port : Prometheusサービスのリスニングポート。デフォルト値は9090です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• data_dir : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに従ってディレクトリが生成されます。

• log_dir : ログディレクトリを指定します。指定しない場合、または相対ディレクトリで指定した場合は、 globalで設定したlog_dirディレクトリに従ってログが生成されます。

• numa_node : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンにヌマクトルインストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーはヌマクトル使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。

• storage_retention : Prometheus監視データの保持期間。デフォルト値は"30d"です。

• rule_dir : *.rules.ymlのファイルすべてを含むローカルディレクトリを指定します。これらのファイルは、Prometheusのルールとして、クラスター構成の初期化フェーズ中にターゲットマシンに転送されます。

• remote_config : Prometheusデータのリモートへの書き込み、またはリモートからのデータの読み取りをサポートします。このフィールドには2つの設定があります。

  • remote_write : Prometheus ドキュメント<remote_write>を参照してください。
  • remote_read : Prometheus ドキュメント<remote_read>を参照してください。

• external_alertmanagers : フィールドexternal_alertmanagersが設定されている場合、Prometheusはクラスター外のAlertmanagerに構成動作を通知します。このフィールドは配列であり、各要素は外部Alertmanagerであり、フィールドhostとフィールドweb_portで構成されます。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はglobalのresource_control内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd 設定ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの設定ルールは、 globalのresource_control内容と同じです。

• additional_args : TiUP v1.15.0で導入されたこのフィールドは、Prometheusの実行に必要な追加パラメータを設定します。このフィールドは配列であり、配列の各要素はPrometheusの実行パラメータです。例えば、Prometheusのホットリロード機能を有効にするには、このフィールドを--web.enable-lifecycleに設定します。

• additional_scrape_conf : カスタマイズされたPrometheusスクレイプ設定。TiDBクラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUPはadditional_scrape_confフィールドの内容をPrometheus設定ファイルの対応するパラメータに追加します。詳細については、 Prometheusのスクレイプ設定をカスタマイズする参照してください。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• port
• deploy_dir
• data_dir
• log_dir
• arch
• os

monitoring_servers構成の例は次のとおりです。

monitoring_servers:
  - host: 10.0.1.11
    rule_dir: /local/rule/dir
    additional_args:
    - --web.enable-lifecycle
    remote_config:
      remote_write:
      - queue_config:
          batch_send_deadline: 5m
          capacity: 100000
          max_samples_per_send: 10000
          max_shards: 300
        url: http://127.0.0.1:8003/write
      remote_read:
      - url: http://127.0.0.1:8003/read
      external_alertmanagers:
      - host: 10.1.1.1
        web_port: 9093
      - host: 10.1.1.2
        web_port: 9094

grafana_servers

grafana_servers 、Grafana サービスがデプロイされるマシンを指定します。また、各マシンにおけるサービス設定も指定しますgrafana_serversは配列です。各配列要素には以下のフィールドが含まれます。

• host : Grafanaサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• port : Grafanaサービスのリスニングポート。デフォルト値は3000です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

• username : Grafana ログイン インターフェース上のユーザー名。

• password : Grafanaに対応するパスワード。

• dashboard_dir : dashboard(*.json)ファイルすべてを含むローカルディレクトリを指定します。これらのファイルは、クラスター構成の初期化フェーズ中に、Grafanaのダッシュボードとしてターゲットマシンに転送されます。

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はglobalのresource_control内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd 設定ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの設定ルールは、 globalのresource_control内容と同じです。

• config : このフィールドは、Grafanaにカスタム設定を追加するために使用されます。TiDBクラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUPはconfigフィールドの内容をGrafana設定ファイルgrafana.iniに追加します。詳細については、 その他のGrafana設定をカスタマイズする参照してください。

注記：

dashboard_dirフィールドがgrafana_servers設定されている場合、クラスターの名前を変更するtiup cluster renameコマンドを実行した後、次の操作を実行する必要があります。

1. ローカル ダッシュボード ディレクトリ内の*.jsonファイルについては、 datasourceフィールドの値を新しいクラスター名に更新します ( datasourceクラスター名に基づいて名前が付けられているため)。
2. tiup cluster reload -R grafanaコマンドを実行します。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• port
• deploy_dir
• arch
• os

grafana_servers構成の例は次のとおりです。

grafana_servers:
  - host: 10.0.1.11
    dashboard_dir: /local/dashboard/dir

alertmanager_servers

alertmanager_servers 、Alertmanagerサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定しますalertmanager_serversは配列です。各配列要素には以下のフィールドが含まれます。

• host : Alertmanager サービスがデプロイされているマシンを指定します。このフィールド値は IP アドレスで、必須です。

• ssh_port : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。

• web_port : AlertmanagerがWebサービスを提供するために使用するポートを指定します。デフォルト値は9093です。

• cluster_port : Alertmanager間の通信ポートを指定します。デフォルト値は9094です。

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。

• data_dir : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに従ってディレクトリが生成されます。

• log_dir : ログディレクトリを指定します。指定しない場合、または相対ディレクトリで指定した場合は、 globalで設定したlog_dirディレクトリに従ってログが生成されます。

• numa_node : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンにヌマクトルインストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーはヌマクトル使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。

• config_file : クラスター構成の初期化フェーズ中に、Alertmanager の構成としてターゲット マシンに転送されるローカル ファイルを指定します。

• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。

• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はglobalのresource_control内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd 設定ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの設定ルールは、 globalのresource_control内容と同じです。

• listen_host : Alertmanagerにプロキシ経由でアクセスできるように、リスニングアドレスを指定します。 0.0.0.0に設定することをお勧めします。詳細については、 Alertmanager 設定をカスタマイズする参照してください。

上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。

• host
• web_port
• cluster_port
• deploy_dir
• data_dir
• log_dir
• arch
• os

alertmanager_servers構成の例は次のとおりです。

alertmanager_servers:
  - host: 10.0.1.11
    config_file: /local/config/file
  - host: 10.0.1.12
    config_file: /local/config/file