TiUP を使用した TiDB 展開用のトポロジConfiguration / コンフィグレーションファイル

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

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

ファイル構造

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

• グローバル : クラスターのグローバル構成。一部の構成項目はデフォルト値を使用しており、インスタンスごとに個別に構成できます。
• 監視対象 : 監視サービス、つまり blackbox_exporter およびnode_exporterのConfiguration / コンフィグレーション。各マシンには、 node_exporterとblackbox_exporterが展開されています。
• サーバー構成 : コンポーネントのグローバル構成。各コンポーネントを個別に構成できます。インスタンスに同じ名前の構成アイテムがある場合、インスタンスの構成アイテムが有効になります。
• pd_servers : PD インスタンスの構成。この構成は、PD コンポーネントがデプロイされるマシンを指定します。
• tidb_servers : TiDB インスタンスの構成。この構成は、TiDB コンポーネントがデプロイされるマシンを指定します。
• tikv_servers : TiKV インスタンスの構成。この構成は、TiKV コンポーネントがデプロイされるマシンを指定します。
• tiflash_servers : TiFlash インスタンスの構成。この構成は、TiFlash コンポーネントがデプロイされるマシンを指定します。
• ポンプ_サーバー : Pumpインスタンスの構成。この構成は、 Pumpコンポーネントがデプロイされるマシンを指定します。
• ドレーンサーバー : Drainerインスタンスの構成。この構成は、 Drainerコンポーネントがデプロイされるマシンを指定します。
• cdc_servers : TiCDC インスタンスの構成。この構成は、TiCDC コンポーネントがデプロイされるマシンを指定します。
• tispark_masters : TiSpark マスター インスタンスの構成。この構成は、TiSpark マスター コンポーネントがデプロイされるマシンを指定します。 TiSpark マスターの 1 つのノードのみをデプロイできます。
• tispark_workers : TiSpark ワーカー インスタンスの構成。この構成は、TiSpark ワーカー コンポーネントがデプロイされるマシンを指定します。
• 監視サーバー : Prometheus と NGMonitoring がデプロイされるマシンを指定します。 TiUP は複数の Prometheus インスタンスのデプロイをサポートしていますが、最初のインスタンスのみが使用されます。
• grafana_servers : Grafana インスタンスの構成。この構成は、Grafana がデプロイされるマシンを指定します。
• alertmanager_servers : Alertmanager インスタンスの構成。この構成は、Alertmanager がデプロイされるマシンを指定します。

global

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

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

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

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

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

• 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」は、最大 2 GB のメモリを使用できることを意味します。

  • 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人のユーザーを使用してクラスターを開始します。同時に、各コンポーネントは実行時に最大 2 GB のメモリに制限されます。

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セクションと同様に、このセクションの構成は、インスタンス内の同じ名前の構成によって上書きできます。 server_configsには、主に次のフィールドが含まれます。

• tidb : TiDB サービス関連の構成。完全な構成については、 TiDB 構成ファイルを参照してください。

• tikv : TiKV サービス関連の構成。完全な構成については、 TiKV 構成ファイルを参照してください。

• pd : PD サービス関連の構成。完全な構成については、 PD 構成ファイルを参照してください。

• tiflash : TiFlash サービス関連の構成。完全な構成については、 TiFlash 構成ファイルを参照してください。

• tiflash_learner : 各 TiFlash ノードには、特別なビルトイン TiKV があります。この構成項目は、この特別な TiKV を構成するために使用されます。通常、この構成項目の内容を変更することはお勧めしません。

• pump :Pumpサービス関連の構成。完全な構成については、 TiDB Binlog構成ファイルを参照してください。

• drainer : Drainerサービス関連の構成。完全な構成については、 TiDB Binlog構成ファイルを参照してください。

• cdc : TiCDC サービス関連の構成。完全な構成については、 TiCDC をデプロイを参照してください。

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

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

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

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 ポリシーをインスタンスに割り当てます。このフィールドを指定する前に、ターゲット マシンにnumactlがインストールされていることを確認する必要があります。このフィールドが指定されている場合、 cpubind および membind ポリシーはnumactlを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、「0,1」などの NUMA ノードの ID です。

• config : このフィールドの構成規則は、 server_configsのpd構成規則と同じです。このフィールドが設定されている場合、フィールド コンテンツはpdコンテンツ インserver_configsとマージされます (2 つのフィールドが重複する場合、このフィールドのコンテンツが有効になります)。次に、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

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

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

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はresource_controlの内容をglobalつにマージされます (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 : MySQL クライアントへの接続を提供するために使用される TiDB サービスのリッスン ポート。デフォルト値は4000です。

• status_port : TiDB ステータス サービスのリッスン ポート。HTTP 要求を介して外部から TiDB サービスのステータスを表示するために使用されます。デフォルト値は10080です。

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

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

• numa_node : NUMA ポリシーをインスタンスに割り当てます。このフィールドを指定する前に、ターゲット マシンにnumactlがインストールされていることを確認する必要があります。このフィールドが指定されている場合、 cpubind および membind ポリシーはnumactlを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、「0,1」などの NUMA ノードの ID です。

• config : このフィールドの構成規則は、 server_configsのtidb構成規則と同じです。このフィールドが設定されている場合、フィールド コンテンツはtidbコンテンツ インserver_configsとマージされます (2 つのフィールドが重複する場合、このフィールドのコンテンツが有効になります)。次に、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

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

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

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はresource_controlの内容をglobalつにマージされます (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 ポリシーをインスタンスに割り当てます。このフィールドを指定する前に、ターゲット マシンにnumactlがインストールされていることを確認する必要があります。このフィールドが指定されている場合、 cpubind および membind ポリシーはnumactlを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、「0,1」などの NUMA ノードの ID です。

• config : このフィールドの構成規則は、 server_configsのtikv構成規則と同じです。このフィールドが設定されている場合、フィールド コンテンツはtikvコンテンツ インserver_configsとマージされます (2 つのフィールドが重複する場合、このフィールドのコンテンツが有効になります)。次に、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

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

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

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はresource_controlの内容をglobalつにマージされます (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です。

• http_port : TiFlash HTTP サービスのポート。デフォルト値は8123です。

• 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 一時ファイルのストレージ パス。デフォルト値は [ pathまたはstorage.latest.dirの最初のディレクトリ] + "/tmp" です。

• numa_node : NUMA ポリシーをインスタンスに割り当てます。このフィールドを指定する前に、ターゲット マシンにnumactlがインストールされていることを確認する必要があります。このフィールドが指定されている場合、 cpubind および membind ポリシーはnumactlを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、「0,1」などの NUMA ノードの ID です。

• config : このフィールドの構成規則は、 server_configsのtiflash構成規則と同じです。このフィールドが設定されている場合、フィールド コンテンツはtiflashコンテンツ インserver_configsとマージされます (2 つのフィールドが重複する場合、このフィールドのコンテンツが有効になります)。次に、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

• learner_config : 各 TiFlash ノードには、特別なビルトイン TiKV があります。この構成項目は、この特別な TiKV を構成するために使用されます。通常、この構成項目の内容を変更することはお勧めしません。

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

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

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

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

• host
• tcp_port
• http_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

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 ポリシーをインスタンスに割り当てます。このフィールドを指定する前に、ターゲット マシンにnumactlがインストールされていることを確認する必要があります。このフィールドが指定されている場合、 cpubind および membind ポリシーはnumactlを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、「0,1」などの NUMA ノードの ID です。

• config : このフィールドの構成規則は、 server_configsのpump構成規則と同じです。このフィールドが設定されている場合、フィールド コンテンツはpumpコンテンツ インserver_configsとマージされます (2 つのフィールドが重複する場合、このフィールドのコンテンツが有効になります)。次に、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

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

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

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はresource_controlの内容をglobalつにマージされます (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 BinlogDrainerがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。 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 ポリシーをインスタンスに割り当てます。このフィールドを指定する前に、ターゲット マシンにnumactlがインストールされていることを確認する必要があります。このフィールドが指定されている場合、 cpubind および membind ポリシーはnumactlを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、「0,1」などの NUMA ノードの ID です。

• config : このフィールドの構成規則は、 server_configsのdrainer構成規則と同じです。このフィールドが設定されている場合、フィールド コンテンツはdrainerコンテンツ インserver_configsとマージされます (2 つのフィールドが重複する場合、このフィールドのコンテンツが有効になります)。次に、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

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

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

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はresource_controlの内容をglobalつにマージされます (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

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 : PD で TiCDC によって設定されたサービス レベル GC セーフポイントの Time To Live (TTL) 期間 (秒単位)。デフォルト値は86400で、これは 24 時間です。

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

• numa_node : NUMA ポリシーをインスタンスに割り当てます。このフィールドを指定する前に、ターゲット マシンにnumactlがインストールされていることを確認する必要があります。このフィールドが指定されている場合、 cpubind および membind ポリシーはnumactlを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、「0,1」などの NUMA ノードの ID です。

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

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

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

• resource_control : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はresource_controlの内容をglobalつにマージされます (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 : Web サービスとタスクの状態を提供する Spark の 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 : Web サービスとタスクの状態を提供する Spark の 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 に接続する SSH ポートを指定します。 TiUP v1.7.0 で導入されたこのフィールドは、TiDB 5.3.0 以降で継続的なプロファイリングおよびTop SQLをサポートします。

• 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 ポリシーをインスタンスに割り当てます。このフィールドを指定する前に、ターゲット マシンにnumactlがインストールされていることを確認する必要があります。このフィールドが指定されている場合、 cpubind および membind ポリシーはnumactlを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、「0,1」などの NUMA ノードの ID です。

• 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 : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はresource_controlの内容をglobalつにマージされます (2 つのフィールドが重複する場合、このフィールドの内容が有効になります)。次に、systemd 構成ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの構成ルールはglobalのresource_controlの内容と同じです。

上記のフィールドについては、展開後にこれらの構成済みフィールドを変更することはできません。

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

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

monitoring_servers:
  - host: 10.0.1.11
    rule_dir: /local/rule/dir
    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 : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容はresource_controlの内容をglobalつにマージされます (2 つのフィールドが重複する場合、このフィールドの内容が有効になります)。次に、systemd 構成ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの構成ルールはglobalのresource_controlの内容と同じです。

ノート：

grafana_serversのdashboard_dirフィールドが構成されている場合、 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 : 1 つの Alertmanager と他の Alertmanager 間の通信ポートを指定します。デフォルト値は9094です。

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

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

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

• numa_node : NUMA ポリシーをインスタンスに割り当てます。このフィールドを指定する前に、ターゲット マシンにnumactlがインストールされていることを確認する必要があります。このフィールドが指定されている場合、 cpubind および membind ポリシーはnumactlを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、「0,1」などの NUMA ノードの ID です。

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

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

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

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

上記のフィールドについては、展開後にこれらの構成済みフィールドを変更することはできません。

• 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