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

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

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

ファイル構造

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

  • グローバル : クラスターのグローバル構成。一部の構成項目はデフォルト値を使用しており、インスタンスごとに個別に構成できます。
  • 監視されている : 監視サービス、つまり blackbox_exporter とnode_exporterのコンフィグレーション。各マシンにはnode_exporterblackbox_exporterがデプロイされます。
  • サーバー構成 : コンポーネントのグローバル構成。各コンポーネントを個別に構成できます。インスタンスに同じ名前の構成アイテムがある場合、インスタンスの構成アイテムが有効になります。
  • コンポーネントのバージョン : コンポーネントのバージョン。コンポーネントがクラスター バージョンを使用しない場合に構成できます。このセクションは、 tiup-cluster v1.14.0 で導入されました。
  • pd_servers : PD インスタンスの構成。この構成では、PDコンポーネントがデプロイされるマシンを指定します。
  • tidb_servers : TiDB インスタンスの構成。この構成では、TiDBコンポーネントがデプロイされるマシンを指定します。
  • tikv_servers : TiKV インスタンスの構成。この構成では、TiKVコンポーネントがデプロイされるマシンを指定します。
  • tflash_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 インスタンスの構成。この構成では、Grafana がデプロイされるマシンを指定します。
  • アラートマネージャー_サーバー : Alertmanager インスタンスの構成。この構成では、Alertmanager が展開されるマシンを指定します。

global

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

  • user : デプロイされたクラスターの起動に使用されたユーザー。デフォルト値は"tidb"です。 <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」は、最大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ユーザーを使用してクラスターを起動します。同時に、各コンポーネントの実行時のメモリは最大 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サービス関連の構成。完全な構成については、 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_configspdの設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容はserver_configspd内容とマージされます (2 つのフィールドが重複する場合、このフィールドの内容が有効になります)。次に、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

  • os : hostで指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

  • arch : hostで指定したマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は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に展開されることを指定し、PD 10.0.1.11に対して特定の設定を行っています。

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

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

  • os : hostで指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

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

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

  • os : hostで指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

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

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

  • os : hostで指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

  • arch : hostで指定したマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は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 、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_configspumpの設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容はserver_configspump内容とマージされます (2 つのフィールドが重複する場合、このフィールドの内容が有効になります)。次に、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

  • os : hostで指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

  • arch : hostで指定したマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は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 、TiDB BinlogのDrainerサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。 drainer_serversは配列です。各配列要素には次のフィールドが含まれます。

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

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

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

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

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

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

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

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

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

  • os : hostで指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

  • arch : hostで指定したマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は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 : PD の TiCDC によって設定されたサービス レベル GC セーフポイントの存続時間 (TTL) の期間 (秒単位)。デフォルト値は86400 、つまり 24 時間です。

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

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

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

  • os : hostで指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

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

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

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

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

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

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

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

tispark_masters

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

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

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

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

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

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

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

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

  • spark_config : TiSpark サービスを構成するように構成します。次に、構成ファイルが生成され、 hostで指定されたマシンに送信されます。

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

  • os : hostで指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

  • arch : hostで指定したマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は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 : Spark の Web ポート。Web サービスとタスクのステータスを提供します。デフォルト値は8080です。

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

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

  • os : hostで指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

  • arch : hostで指定したマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は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 がリッスンするポートを指定します。 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 つの構成があります。

    • remote_write : Prometheus のドキュメント&#x3C;remote_write>を参照してください。
    • remote_read : Prometheus のドキュメント&#x3C;remote_read>を参照してください。
  • external_alertmanagers : external_alertmanagersフィールドが設定されている場合、Prometheus はクラスターの外部にある Alertmanager に設定動作を警告します。このフィールドは配列であり、その各要素は外部 Alertmanager であり、 hostフィールドとweb_portフィールドで構成されます。

  • os : hostで指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

  • arch : hostで指定したマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は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ディレクトリに従ってディレクトリが生成されます。

  • os : hostで指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

  • arch : hostで指定したマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は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 つのアラートマネージャーと他のアラートマネージャー間の通信ポートを指定します。デフォルト値は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で指定したマシンのOS。このフィールドが指定されていない場合、デフォルト値はglobalos値です。

  • arch : hostで指定したマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は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

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

Playground
新規
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.