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

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

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

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

ファイル構造

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

  • グローバル :クラスターのグローバル構成。一部の構成項目はデフォルト値を使用しており、インスタンスごとに個別に構成できます。
  • 監視 :監視サービスのConfiguration / コンフィグレーション、つまり、blackbox_exporterとnode_exporter 。各マシンには、 node_exporterblackbox_exporterが展開されています。
  • server_configs :コンポーネントのグローバル構成。各コンポーネントを個別に構成できます。インスタンスに同じ名前の構成アイテムがある場合、インスタンスの構成アイテムが有効になります。
  • pd_servers :PDインスタンスの構成。この構成は、PDコンポーネントが展開されるマシンを指定します。
  • tidb_servers :TiDBインスタンスの構成。この構成は、TiDBコンポーネントがデプロイされるマシンを指定します。
  • tikv_servers :TiKVインスタンスの構成。この構成は、TiKVコンポーネントが展開されるマシンを指定します。
  • tiflash_servers :TiFlashインスタンスの構成。この構成は、TiFlashコンポーネントが展開されるマシンを指定します。
  • pump_servers : Pumpインスタンスの構成。この構成は、 Pumpコンポーネントがデプロイされるマシンを指定します。
  • drainer_servers : Drainerインスタンスの構成。この構成は、 Drainerコンポーネントがデプロイされるマシンを指定します。
  • cdc_servers :TiCDCインスタンスの構成。この構成は、TiCDCコンポーネントが展開されるマシンを指定します。
  • tispark_masters :TiSparkマスターインスタンスの構成。この構成は、TiSparkマスターコンポーネントが展開されるマシンを指定します。 TiSparkマスターの1つのノードのみをデプロイできます。
  • tispark_workers :TiSparkワーカーインスタンスの構成。この構成は、TiSparkワーカーコンポーネントがデプロイされるマシンを指定します。
  • Monitoring_servers :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」は、最大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_portnode_exporterのサービスポート。デフォルト値は9100です。

  • blackbox_exporter_portblackbox_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_exporter9100ポートを使用し、 blackbox_exporter9115ポートを使用することを指定しています。

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サービス関連の構成。完全な構成については、 Binlog構成ファイルを参照してください。

  • drainer :ドDrainerサービス関連の構成。完全な構成については、 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_configspd構成ルールと同じです。このフィールドが構成されている場合、フィールドのコンテンツはserver_configspdのコンテンツとマージされます(2つのフィールドが重複している場合、このフィールドのコンテンツが有効になります)。次に、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

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

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

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

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

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

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

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

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

  • resource_control :サービスのリソース制御。このフィールドが構成されている場合、フィールドのコンテンツはglobalresource_controlつのコンテンツとマージされます(2つのフィールドが重複している場合、このフィールドのコンテンツが有効になります)。次に、systemd構成ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの構成ルールは、 globalresource_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 :TiFlashTCPサービスのポート。デフォルト値は9000です。

  • http_port :TiFlashHTTPサービスのポート。デフォルト値は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_configstiflash構成ルールと同じです。このフィールドが構成されている場合、フィールドのコンテンツはserver_configstiflashのコンテンツとマージされます(2つのフィールドが重複している場合、このフィールドのコンテンツが有効になります)。次に、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

  • learner_config :各TiFlashノードには特別な組み込みTiKVがあります。この構成アイテムは、この特別なTiKVを構成するために使用されます。通常、この構成アイテムのコンテンツを変更することはお勧めしません。

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

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

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

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

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

  • resource_control :サービスのリソース制御。このフィールドが構成されている場合、フィールドのコンテンツはglobalresource_controlつのコンテンツとマージされます(2つのフィールドが重複している場合、このフィールドのコンテンツが有効になります)。次に、systemd構成ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの構成ルールは、 globalresource_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は、 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がチェックポイントを取得しない場合、Drainerはこのフィールドを最初の起動のレプリケーション時点として使用します。このフィールドのデフォルトは-1です(Drainerは常にPDからcommit_tsとして最新のタイムスタンプを取得します)。

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

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

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

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

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

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

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

commit_tsフィールドは、TiUP v1.9.2以降非推奨になり、 Drainerの開始スクリプトには記録されません。それでもこのフィールドを使用する必要がある場合は、次の例を参照してconfiginitial-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 :TiCDCによってPDで設定されたサービスレベルGCセーフポイントの存続時間(TTL)期間(秒単位)。デフォルト値は86400 、つまり24時間です。

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

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

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

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

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

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

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

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

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の起動時に環境変数を設定します。

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

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

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

  • 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のシステム環境変数に対応します。

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

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

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

  • 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で導入されたこのフィールドは、TiDB5.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つの構成があります。

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

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

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

  • resource_control :サービスのリソース制御。このフィールドが構成されている場合、フィールドのコンテンツはglobalresource_controlつのコンテンツとマージされます(2つのフィールドが重複している場合、このフィールドのコンテンツが有効になります)。次に、systemd構成ファイルが生成され、 hostで指定されたマシンに送信されます。 resource_controlの構成ルールは、 globalresource_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ディレクトリに従って生成されます。

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

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

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

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

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

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

ノート:

grafana_serversdashboard_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つのAlertmangerと他の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の構成として指定します。

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

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

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