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

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

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

TiUPを使用して TiDB クラスターをデプロイすると、Prometheus、Grafana、Alertmanager などの監視サーバーTiUPデプロイされます。また、このクラスターをスケールアウトすると、 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コンポーネントがデプロイされるマシンを指定します。
• kvcdc_servers : インスタンスTiKV-CDCの構成。この構成では、TiKV-CDCコンポーネントがデプロイされるマシンを指定します。
• cdc_servers : TiCDCインスタンスの構成。この構成では、TiCDCコンポーネントがデプロイされるマシンを指定します。
• tso_servers : TSOインスタンスの設定。この設定は、 tsoマイクロサービスがデプロイされるマシンを指定します（ PDマイクロサービス番目のマイクロサービスを有効にするには、 globalのマイクロサービスでpd_mode: "ms"マイクロサービスを設定する必要があります）。
• スケジューリングサーバー : スケジューリングインスタンスの設定。この設定では、 schedulingマイクロサービスがデプロイされるマシンを指定します（ PDマイクロサービス有効にするには、 globalでpd_mode: "ms"設定する必要があります）。
• 監視サーバー : 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」です。

• pd_mode : PD動作モード。このフィールドは、 PDマイクロサービスマイクロサービスを有効にするかどうかを制御します。サポートされる値は「ms」です。このフィールドを指定すると、PDマイクロサービスが有効になります。

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

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

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

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

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

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

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

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

• tso : tsoマイクロサービス関連の設定。完全な設定についてはTSO構成ファイル参照してください。

• scheduling : schedulingマイクロサービス関連の設定。完全な設定についてはスケジュール設定ファイル参照してください。

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 ダッシュボードコンポーネントのバージョン
• cdc : CDCコンポーネントのバージョン
• kvcdc : TiKV-CDCコンポーネントのバージョン
• tiproxy : TiProxyコンポーネントのバージョン
• prometheus : Prometheusコンポーネントのバージョン
• grafana : Grafanaコンポーネントのバージョン
• alertmanager : Alertmanagerコンポーネントのバージョン
• tso : TSOコンポーネントのバージョン
• scheduling : スケジュールコンポーネントのバージョン

以下は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 TiUP以降、この設定項目は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です。

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

• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_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
• arch
• os

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

tiproxy_servers:
  - host: 10.0.1.21
    port: 6000
    status_port: 3080
    config:
      labels: { zone: "zone1" }
  - host: 10.0.1.22
    port: 6000
    status_port: 3080
    config:
      labels: { zone: "zone2" }

その他の構成例については、 TiProxy 展開トポロジ参照してください。

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"

tso_servers

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

• host : tsoマイクロサービスがデプロイされているマシンのIPアドレスを指定します。このフィールド値は必須です。
• ssh_port : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。
• port : tsoマイクロサービスのリスニングポートを指定します。デフォルト値は3379です。
• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。
• data_dir : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに従ってディレクトリが生成されます。
• config : このフィールドの設定ルールは、 server_configsのtso設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容はserver_configsのtso内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 hostで指定されたマシンに送信されます。
• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。
• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

上記のフィールドのうち、デプロイメント後に次のフィールドを変更することはできません。

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

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

tso_servers:
  - host: 10.0.1.21
  - host: 10.0.1.22

scheduling_servers

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

• host : schedulingマイクロサービスがデプロイされているマシンのIPアドレスを指定します。このフィールドは必須です。
• ssh_port : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 globalセクションのうちssh_portのセクションが使用されます。
• port : schedulingマイクロサービスのリスニングポートを指定します。デフォルト値は3379です。
• deploy_dir : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdeploy_dirディレクトリに従ってディレクトリが生成されます。
• data_dir : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 globalで設定されたdata_dirディレクトリに従ってディレクトリが生成されます。
• config : このフィールドの設定ルールは、 server_configsのscheduling設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容はserver_configsのscheduling内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 hostで指定されたマシンに送信されます。
• os : hostで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値はglobalのos値になります。
• arch : hostで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値はglobalのarch値になります。

上記のフィールドのうち、デプロイメント後に次のフィールドを変更することはできません。

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

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

scheduling_servers:
  - host: 10.0.1.21
  - host: 10.0.1.22

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