TiDB Cloud
TiDB
Playground
お問い合わせ

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

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

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

TiUPを使用して TiDB クラスターをデプロイすると、 TiUP は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_サーバー : TiKV インスタンスの構成。この構成は、TiKVコンポーネントがデプロイされるマシンを指定します。
  • tiflash_servers : TiFlashインスタンスの構成。この構成は、 TiFlashコンポーネントがデプロイされるマシンを指定します。
  • プロキシサーバー : TiProxy インスタンスの構成。この構成は、TiProxyコンポーネントが展開されるマシンを指定します。
  • ポンプサーバー : Pumpインスタンスの構成。この構成は、 Pumpコンポーネントがデプロイされるマシンを指定します。
  • ドレイナーサーバー : Drainerインスタンスの構成。この構成は、 Drainerコンポーネントがデプロイされるマシンを指定します。
  • cdc_servers : TiCDC インスタンスの構成。この構成は、TiCDCコンポーネントがデプロイされるマシンを指定します。
  • tispark_masters : TiSpark マスター インスタンスの構成。この構成は、TiSpark マスターコンポーネントがデプロイされるマシンを指定します。デプロイできる TiSpark マスターのノードは 1 つだけです。
  • tispark_workers : TiSpark ワーカー インスタンスの構成。この構成は、TiSpark ワーカーコンポーネントがデプロイされるマシンを指定します。
  • 監視サーバー : Prometheus と NGMonitoring がデプロイされるマシンを指定します。TiUPは複数の Prometheus インスタンスのデプロイをサポートしていますが、最初のインスタンスのみが使用されます。
  • grafana_サーバー : Grafana インスタンスの構成。この構成は、Grafana がデプロイされるマシンを指定します。
  • アラートマネージャサーバー : Alertmanager インスタンスの構成。この構成は、Alertmanager がデプロイされるマシンを指定します。

global

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

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

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

  • 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」は最大 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 を構成するために使用されます。通常、この構成項目の下のコンテンツを変更することは推奨されません。

  • 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 ポリシーはヌマクトルを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、"0,1" などの NUMA ノードの ID です。

  • 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 : MySQL クライアントへの接続を提供するために使用される TiDB サービスのリスニング ポート。デフォルト値は4000です。

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

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

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

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

  • 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 ポリシーはヌマクトルを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、"0,1" などの NUMA ノードの ID です。

  • 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です。

  • 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 ポリシーはヌマクトルを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、"0,1" などの NUMA ノードの ID です。

  • 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
  • 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

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 ポリシーはヌマクトルを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、"0,1" などの NUMA ノードの ID です。

  • 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サービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。2 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 ポリシーはヌマクトルを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、"0,1" などの NUMA ノードの ID です。

  • 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

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 セーフポイントの有効期間 (TTL) (秒単位)。デフォルト値は86400 (24 時間) です。

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

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

  • 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 : 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 がリッスンするポートを指定します。TiUP v1.7.0 で導入されたこのフィールドは、 継続的なプロファイリングと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 ポリシーはヌマクトルを使用して割り当てられます。このフィールドは文字列型です。フィールド値は、"0,1" などの NUMA ノードの ID です。

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

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

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

  • 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 : 1 つの Alertmanager と他の Alertmanager 間の通信ポートを指定します。デフォルト値は9094です。

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

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

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

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

  • 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

このページは役に立ちましたか？

Playground
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Dedicated
TiDB Serverless
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
リソース
よくあるご質問
開発者ガイド
ニュース&ブログ
Education
導入実績
サポート
Discord
Forum
Slack
Support Portal
会社関連
会社概要
キャリア
規約類
お問い合わせ
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.