TiUP を使用した DMクラスタ展開用のトポロジConfiguration / コンフィグレーションファイル
TiDB Data Migration (DM) クラスターをデプロイまたはスケーリングするには、クラスター トポロジーを記述するトポロジー ファイル ( サンプル ) を提供する必要があります。
同様に、クラスタ トポロジを変更するには、トポロジ ファイルを変更する必要があります。違いは、クラスターがデプロイされた後は、トポロジー ファイル内のフィールドの一部しか変更できないことです。このドキュメントでは、トポロジ ファイルの各セクションと、各セクションの各フィールドについて説明します。
ファイル構造
TiUP を使用した DM クラスター展開のトポロジ構成ファイルには、次のセクションが含まれる場合があります。
- グローバル : クラスターのグローバル構成。一部の構成項目はクラスターのデフォルト値を使用し、インスタンスごとに個別に構成できます。
 - サーバー構成 : コンポーネントのグローバル構成。各コンポーネントを個別に構成できます。インスタンスに同じキーを持つ構成アイテムがある場合、インスタンスの構成アイテムが有効になります。
 - master_servers : DM-master インスタンスの構成。構成は、DM コンポーネントのマスター サービスがデプロイされるマシンを指定します。
 - worker_servers : DM-worker インスタンスの構成。構成は、DM コンポーネントのワーカー サービスがデプロイされるマシンを指定します。
 - 監視サーバー : Prometheus インスタンスがデプロイされるマシンを指定します。 TiUP は複数の Prometheus インスタンスのデプロイをサポートしていますが、最初のインスタンスのみが使用されます。
 - grafana_servers : Grafana インスタンスの構成。構成は、Grafana インスタンスがデプロイされるマシンを指定します。
 - alertmanager_servers : Alertemanager インスタンスの構成。構成は、Alertmanager インスタンスがデプロイされるマシンを指定します。
 
global
globalセクションはクラスターのグローバル構成に対応し、次のフィールドがあります。
user: デプロイされたクラスターを開始するユーザー。デフォルト値は「tidb」です。<user>フィールドで指定されたユーザーがターゲット マシンに存在しない場合、TiUP は自動的にユーザーの作成を試みます。group: ユーザーが自動作成されたときにユーザーが属するユーザーグループ。デフォルト値は<user>フィールドと同じです。指定したグループが存在しない場合は、自動的に作成されます。ssh_port: 操作のためにターゲット マシンに接続するための SSH ポート。デフォルト値は「22」です。deploy_dir: 各コンポーネントのデプロイメント ディレクトリ。デフォルト値は「デプロイ」です。構築規則は次のとおりです。- 絶対パス
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_dirがインスタンス レベルで設定されている場合、実際のデータ ディレクトリはインスタンス用に設定されたdata_dirになります。 - インスタンスごとに、 
data_dirが構成されていない場合、デフォルト値は<global.data_dir>です。 data_dirが相対パスに設定されている場合、コンポーネント データは<deploy_dir>/<data_dir>に格納されます。<deploy_dir>の構成規則については、deploy_dirフィールドの構成規則を参照してください。
- 絶対パス
 log_dir: データ ディレクトリ。デフォルト値は「ログ」です。構築ルールは以下の通りです。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:0 100M"です。io_write_bandwidth_max: ディスク書き込みの最大 I/O 帯域幅を制限します。たとえば、"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M"です。limit_core: コア ダンプのサイズを制御します。
global構成例:
global:
  user: "tidb"
  resource_control:
    memory_limit: "2G"
この例の構成では、クラスターの開始にtidb人のユーザーが使用されること、および各コンポーネントの実行時のメモリが最大 2 GB に制限されることが指定されています。
server_configs
server_configsは、サービスを構成し、各コンポーネントの構成ファイルを生成するために使用されます。 globalセクションと同様に、 server_configsセクションの構成は、インスタンス内の同じキーを持つ構成によって上書きできます。 server_configsには、主に次のフィールドが含まれます。
master: DM-master サービスに関連する構成。サポートされているすべての構成アイテムについては、 DMマスターConfiguration / コンフィグレーションファイルを参照してください。worker: DM-worker サービスに関連する構成。サポートされているすべての構成項目については、 DM-workerConfiguration / コンフィグレーションファイルを参照してください。
server_configsの構成例は次のとおりです。
server_configs:
  master:
    log-level: info
    rpc-timeout: "30s"
    rpc-rate-limit: 10.0
    rpc-rate-burst: 40
  worker:
    log-level: info
master_servers
master_serversは、DM コンポーネントのマスター ノードがデプロイされるマシンを指定します。各マシンでサービス構成を指定することもできます。 master_serversは配列です。各配列要素には、次のフィールドが含まれます。
host: デプロイ先のマシンを指定します。フィールド値は IP アドレスで、必須です。ssh_port: 操作のためにターゲット マシンに接続するための SSH ポートを指定します。フィールドが指定されていない場合は、globalセクションのssh_portが使用されます。name: DM マスター インスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。そうしないと、クラスターをデプロイできません。port: DM-master がサービスを提供するポートを指定します。デフォルト値は「8261」です。peer_port: DM マスター間の通信用のポートを指定します。デフォルト値は「8291」です。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セクションのmasterと同じです。configを指定すると、configの構成がserver_configsのmasterの構成とマージされ (2 つのフィールドが重複する場合は、このフィールドの構成が有効になります)、構成ファイルが生成され、指定されたマシンに配布されます。hostフィールド。os:hostフィールドで指定されたマシンのオペレーティング システム。フィールドが指定されていない場合、デフォルト値はglobalセクションで設定されたosの値です。arch:hostフィールドで指定されたマシンのアーキテクチャ。フィールドが指定されていない場合、デフォルト値はglobalセクションで設定されたarchの値です。resource_control: このサービスのリソース制御。このフィールドを指定すると、このフィールドの設定がglobalセクションのresource_controlの設定とマージされ (2 つのフィールドが重複する場合は、このフィールドの設定が有効になります)、systemd の設定ファイルが生成され、配布されます。hostフィールドで指定されたマシンに。このフィールドの構成ルールは、globalセクションのresource_controlと同じです。v1_source_path: v1.0.x からアップグレードする場合、V1 ソースの構成ファイルが置かれているディレクトリをこのフィールドに指定できます。
master_serversセクションでは、デプロイの完了後に次のフィールドを変更できません。
hostnameportpeer_portdeploy_dirdata_dirlog_dirarchosv1_source_path
master_serversの構成例は次のとおりです。
master_servers:
  - host: 10.0.1.11
    name: master1
    ssh_port: 22
    port: 8261
    peer_port: 8291
    deploy_dir: "/dm-deploy/dm-master-8261"
    data_dir: "/dm-data/dm-master-8261"
    log_dir: "/dm-deploy/dm-master-8261/log"
    numa_node: "0,1"
    # The following configs are used to overwrite the `server_configs.master` values.
    config:
      log-level: info
      rpc-timeout: "30s"
      rpc-rate-limit: 10.0
      rpc-rate-burst: 40
  - host: 10.0.1.18
    name: master2
  - host: 10.0.1.19
    name: master3
worker_servers
worker_serversは、DM コンポーネントのマスター ノードがデプロイされるマシンを指定します。各マシンでサービス構成を指定することもできます。 worker_serversは配列です。各配列要素には、次のフィールドが含まれます。
host: デプロイ先のマシンを指定します。フィールド値は IP アドレスで、必須です。ssh_port: 操作のためにターゲット マシンに接続するための SSH ポートを指定します。フィールドが指定されていない場合は、globalセクションのssh_portが使用されます。name: DM-worker インスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。そうしないと、クラスターをデプロイできません。port: DM-worker がサービスを提供するポートを指定します。デフォルト値は「8262」です。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セクションのworkerと同じです。configを指定すると、configの構成がserver_configsのworkerの構成とマージされ (2 つのフィールドが重複する場合は、このフィールドの構成が有効になります)、構成ファイルが生成され、指定されたマシンに配布されます。hostフィールド。os:hostフィールドで指定されたマシンのオペレーティング システム。フィールドが指定されていない場合、デフォルト値はglobalセクションで設定されたosの値です。arch:hostフィールドで指定されたマシンのアーキテクチャ。フィールドが指定されていない場合、デフォルト値はglobalセクションで設定されたarchの値です。resource_control: このサービスのリソース制御。このフィールドを指定すると、このフィールドの設定がglobalセクションのresource_controlの設定とマージされ (2 つのフィールドが重複する場合は、このフィールドの設定が有効になります)、systemd の設定ファイルが生成され、配布されます。hostフィールドで指定されたマシンに。このフィールドの構成ルールは、globalセクションのresource_controlと同じです。
worker_serversセクションでは、デプロイの完了後に次のフィールドを変更できません。
hostnameportdeploy_dirdata_dirlog_dirarchos
worker_serversの構成例は次のとおりです。
worker_servers:
  - host: 10.0.1.12
    ssh_port: 22
    port: 8262
    deploy_dir: "/dm-deploy/dm-worker-8262"
    log_dir: "/dm-deploy/dm-worker-8262/log"
    numa_node: "0,1"
    # config is used to overwrite the `server_configs.worker` values
    config:
      log-level: info
  - host: 10.0.1.19
monitoring_servers
monitoring_serversは、Prometheus サービスがデプロイされるマシンを指定します。マシンでサービス構成を指定することもできます。 monitoring_serversは配列です。各配列要素には、次のフィールドが含まれます。
host: デプロイ先のマシンを指定します。フィールド値は IP アドレスで、必須です。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 モニタリング データの保存期間を指定します。デフォルト値は「15d」です。rule_dir: 完全な*.rules.ymlのファイルが配置されているローカル ディレクトリを指定します。指定されたディレクトリ内のファイルは、クラスター構成の初期化フェーズ中に Prometheus ルールとしてターゲット マシンに送信されます。remote_config: リモートへの Prometheus データの書き込み、またはリモートからのデータの読み取りをサポートします。このフィールドには 2 つの構成があります。remote_write: Prometheus ドキュメント<remote_write>を参照してください。remote_read: Prometheus ドキュメント<remote_read>を参照してください。
external_alertmanagers:external_alertmanagersフィールドが構成されている場合、Prometheus は構成動作をクラスター外の Alertmanager にアラートします。このフィールドは配列であり、その各要素は外部 Alertmanager であり、hostおよびweb_portフィールドで構成されています。os:hostフィールドで指定されたマシンのオペレーティング システム。フィールドが指定されていない場合、デフォルト値はglobalセクションで設定されたosの値です。arch:hostフィールドで指定されたマシンのアーキテクチャ。フィールドが指定されていない場合、デフォルト値はglobalセクションで設定されたarchの値です。resource_control: このサービスのリソース制御。このフィールドを指定すると、このフィールドの設定がglobalセクションのresource_controlの設定とマージされ (2 つのフィールドが重複する場合は、このフィールドの設定が有効になります)、systemd の設定ファイルが生成され、配布されます。hostフィールドで指定されたマシンに。このフィールドの構成ルールは、globalセクションのresource_controlと同じです。
monitoring_serversセクションでは、デプロイの完了後に次のフィールドを変更できません。
hostportdeploy_dirdata_dirlog_dirarchos
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: デプロイ先のマシンを指定します。フィールド値は 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フィールドで指定されたマシンに。このフィールドの構成ルールは、globalセクションのresource_controlと同じです。
ノート:
grafana_serversのdashboard_dirフィールドが構成されている場合、tiup cluster renameコマンドを実行してクラスターの名前を変更した後、次の操作を実行する必要があります。
- ローカル
 dashboardsディレクトリで、datasourceフィールドの値を新しいクラスター名に更新します (datasourceはクラスター名にちなんで命名されます)。tiup cluster reload -R grafanaコマンドを実行します。
grafana_serversでは、デプロイの完了後に次のフィールドを変更できません。
hostportdeploy_dirarchos
grafana_serversの構成例は次のとおりです。
grafana_servers:
  - host: 10.0.1.11
    dashboard_dir: /local/dashboard/dir
alertmanager_servers
alertmanager_serversは、Alertmanager サービスがデプロイされるマシンを指定します。各マシンでサービス構成を指定することもできます。 alertmanager_serversは配列です。各配列要素には、次のフィールドが含まれます。
host: デプロイ先のマシンを指定します。フィールド値は IP アドレスで、必須です。ssh_port: 操作のためにターゲット マシンに接続するための SSH ポートを指定します。フィールドが指定されていない場合は、globalセクションのssh_portが使用されます。web_port: Alertmanager が Web サービスを提供するポートを指定します。デフォルト値は「9093」です。cluster_port: 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: このサービスのリソース制御。このフィールドを指定すると、このフィールドの設定がglobalセクションのresource_controlの設定とマージされ (2 つのフィールドが重複する場合は、このフィールドの設定が有効になります)、systemd の設定ファイルが生成され、配布されます。hostフィールドで指定されたマシンに。このフィールドの構成ルールは、globalセクションのresource_controlと同じです。
alertmanager_serversでは、デプロイの完了後に次のフィールドを変更できません。
hostweb_portcluster_portdeploy_dirdata_dirlog_dirarchos
alertmanager_serversの構成例は次のとおりです。
alertmanager_servers:
  - host: 10.0.1.11
    config_file: /local/config/file
  - host: 10.0.1.12
    config_file: /local/config/file