From 77d70572bc8ff24870214c64a322becf79e9bd10 Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 14 Apr 2021 10:17:13 +0800 Subject: [PATCH 01/14] Create tiup-dm-topology-reference.md --- tiup/tiup-dm-topology-reference.md | 293 +++++++++++++++++++++++++++++ 1 file changed, 293 insertions(+) create mode 100644 tiup/tiup-dm-topology-reference.md diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md new file mode 100644 index 0000000000000..59b055750f0fe --- /dev/null +++ b/tiup/tiup-dm-topology-reference.md @@ -0,0 +1,293 @@ +--- +title: Topology Configuration File for DM Cluster Deployment using TiUP +--- + +# Topology Configuration File for DM Cluster Deployment using TiUP + +To deploy or scale a TiDB Data Migration (DM) cluster, you need to provide a topology file to describe the cluster topology. Similarly, to modify the cluster topology, you need to modify the topology file. The difference is that you can only modify a part of the fields in the topology file. + +Here is an [example topology file](https://github.com/pingcap/tiup/blob/master/embed/templates/examples/dm/topology.example.yaml) for your reference. + +## File Structure + +The topology file of a DM cluster might contain the following blocks: + +- [global](/tiup/tiup-dm-topology-reference.md#global): the global configuration of the cluster. Some of the configuration items use the default values on the cluster, and you can configure them separately in each instance. +- [server_configs](/tiup/tiup-dm-topology-reference.md#server_configs): the global configuration of the components. You can configure each component separately. If an instance has a configuration item with the same name, the items configured in the instance will take effect. +- [master_servers](/tiup/tiup-dm-topology-reference.md#master_servers): the configuration of DM master instance. The block is used to specify the machines to which the master service of the DM component is deployed. +- [worker_servers](/tiup/tiup-dm-topology-reference.md#worker_servers): the configuration of DM worker instance. The block is used to specify the machines to which the worker service of the DM component is deployed. +- [monitoring_servers](/tiup/tiup-cluster-topology-reference.md#monitoring_servers): specifies the machines to which the Prometheus instances are deployed. TiUP supports the deployment of multiple Prometheus instances, but only the first instance is actually in use. +- [grafana_servers](/tiup/tiup-cluster-topology-reference.md#grafana_servers): the configuration of Grafana instances. The block is used to specify the machines to which the Grafana instances are deployed. +- [alertmanager_servers](/tiup/tiup-cluster-topology-reference.md#alertmanager_servers): the configuration of the Alertemanager instances. The block is used to specify the machines to which the Alertmanager instances are deployed. + +### `global` + +The `global` block corresponds to the global configuration of the cluster and contains the following fields: + +- `user`: the user to start the deployed cluster. The default value is "tidb". If the user specified in the `` field does not exist on the target machine, TiUP will automatically try to create the user. +- `group`: the user group to which a user belongs when the user is automatically created. The default value is the same as the `` field. If the specified group does not exist, it will be created automatically. +- `ssh_port`: the SSH port to connect to the target machine for operations. The default value is "22". +- `deploy_dir`: the deployment directory for each component. The default value is "deploy". The application rules are as follows: + - If the absolute path `deploy_dir` is configured at the instance level, the actual deployment directory is the `deploy_dir` configured for the instance. + - For each instance, if `deploy_dir` is not configured, the default value is the relative path `-`. + - If `global.deploy_dir` is set to an absolute path, the component is deployed to `/` directory. + - If `global.deploy_dir` is set to a relative path, the component is deployed to `/home///` directory. +- `data_dir`: the data directory. The default value is "data". The application rules are as follows. + - If the absolute path `data_dir` is configured at the instance level, the actual data directory is the `data_dir` configured for the instance. + - For each instance, if `data_dir` is not configured, the default value is ``. + - If `data_dir` is set to a relative path, the component data is stored in `/`. For the calculation rules of ``, see the application rules of the `deploy_dir` field. +- `log_dir`: the data directory. The default value is "log". The application rules are as follows. + - If the absolute path of `log_dir` is configured at the instance level, the actual log directory is the `log_dir` configured for the instance. + - For each instance, if `log_dir` is not configured by the user, the default value is ``. + - If `log_dir` is a relative path, the component logs will be stored in `/`. For the calculation rules of ``, see the application rules of the `deploy_dir` field. +- `os`: the operating system of the target machine. The field controls which operating system to adapt to for the components pushed to the target machine. The default value is "linux". +- `arch`: the CPU architecture of the target machine. The field controls which platform to adapt to for the binary packages pushed to the target machine. The supported values are "amd64" and "arm64". The default value is "amd64". +- `resource_control`: runtime resource control. All configurations under this field will be written to the `service` file of systemd. By default, the runtime resource is unlimited. The supported resources for control are as follows: + - `memory_limit`: limits the maximum memory at runtime. For example, "2G" means that the maximum memory of 2 GB can be used. + - `cpu_quota`: limits the maximum CPU usage at runtime. For example, "200%". + - `io_read_bandwidth_max`: limits the maximum bandwidth for read disk IO. For example, "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M". + - `io_write_bandwidth_max`: limits the maximum bandwidth of write disk IO. For example, "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M". + - `limit_core`: controls the size of core dump. + +A `global` configuration example: + +```yaml +global: + user: "tidb" + resource_control: + memory_limit: "2G" +``` + +In the example, the configuration specifies that the `tidb` user is used to start the cluster, and that each component is limited to a maximum of 2GB of memory when it is running. + +### `server_configs` + +`server_configs` is used to configure the service and generate the configuration file for each component. Similar to the `global` block, the configurations in the `server_configs` block can be overridden by the configurations with the same names in the instance. The block mainly contains the following fields: + +- `master`: configuration related to the DM master service. For all the supported configuration items, see [DM-master Configuration File](https://docs.pingcap.com/zh/tidb-data-migration/stable/dm-master-configuration-file). +- `worker`: configuration related to the DM worker service, For all the supported configuration items, see [DM-worker Configuration File](https://docs.pingcap.com/zh/tidb-data-migration/stable/dm-worker-configuration-file). + +`server_configs` configuration example: + +```yaml +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` specifies the machines to which the master node of the DM component is deployed. You can also specify the service configuration on each machine. `master_servers` is an array. Each array element contains the following fields: + +- `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. +- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. +- `name`: specifies the name of the DM master instance. The name must be unique for different instances. Otherwise, the cluster cannot be deployed. +- `port`: specifies the port on which DM master provides services. The default values is "8261". +- `peer_port`: specifies the port that DM masters use to communicate with each other. The default value is "8291". +- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. +- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. +- `log_dir`: specifies the log directory. If the field not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". +- `config`: the configuration rules of this field are the same as that of `master` in the `server_configs` block. If `config` is specified, the configuration of `config` will be merged with the configuration of `master` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. +- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. +- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` block. +- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` block (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` block. +- `v1_source_path`: when upgrading from v1.0.x, you can specify the directory where the configuration file of the V1 source is located in this field. + +In the `master_servers` block, the following fields cannot be modified after the deployment is completed: + +- `host` +- `name` +- `port` +- `peer_port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` +- `v1_source_path` + +`master_servers` configuration example: + +```yaml +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` specifies the machines to which the master node of the DM component is deployed. You can also specify the service configuration on each machine. `worker_servers` is an array. Each array element contains the following fields: + +- `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. +- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. +- `name`: specifies the name of the DM worker instance. The name must be unique for different instances. Otherwise, the cluster cannot be deployed. +- `port`: specifies the port on which DM worker provides services. The default values is "8262". +- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. +- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. +- `log_dir`: specifies the log directory. If the field not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". +- `config`: the configuration rules of this field are the same as that of `worker` in the `server_configs` block. If `config` is specified, the configuration of `config` will be merged with the configuration of `worker` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. +- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. +- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` block. +- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` block (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` block. + +In the `worker_servers` block, the following fields cannot be modified after the deployment is completed: + +- `host` +- `name` +- `port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` + +`worker_servers` configuration example: + +```yaml +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` specifies the machines to which the Prometheus service is deployed. You can also specify the service configuration on the machine. `monitoring_servers` is an array. Each array element contains the following fields: + +- `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. +- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. +- `port`: specifies the port on which Prometheus provides services. The default values is "9090". +- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. +- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. +- `log_dir`: specifies the log directory. If the field not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". +- `storage_retention`: specifies the retention time of the Prometheus monitoring data. The default value is "15d". +- `rule_dir`: specifies a local directory where the complete `*.rules.yml` files are located. The files in the specified directory will be sent to the target machine as the Prometheus rules during the initialization phase of the cluster configuration. +- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. +- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` block. +- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` block (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` block. + +In the `monitoring_servers` block, the following fields cannot be modified after the deployment is completed: + +- `host` +- `port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` + +`monitoring_servers` configuration example: + +```yaml +monitoring_servers: + - host: 10.0.1.11 + rule_dir: /local/rule/dir +``` + +### ``grafana_servers`` + +`grafana_servers` specifies the machines to which the Grafana service is deployed. You can also specify the service configuration on the machine. `grafana_servers` is an array. Each array element contains the following fields: + +- `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. +- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. +- `port`: specifies the port on which Grafana provides services. The default values is "3000". +- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. +- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. +- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` block. +- `username`: specifies the username of the Grafana login screen. +- `password`: specifies the corresponding password of Grafana. +- `dashboard_dir`: specifies a local directory where the complete `dashboard(*.json)` files are located. The files in the specified directory will be sent to the target machine as Grafana dashboards during the initialization phase of the cluster configuration. +- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` block (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` block. + +> **Note:** +> +> If the `dashboard_dir` field of `grafana_servers` is configured, after executing the `tiup cluster rename` command to rename the cluster, you need to do the following: +> +> 1. In the local `dashboards` directory, update the value of the `datasource` field to the new cluster name (the `datasource` is named according to the cluster name). +> 2. Execute the `tiup cluster reload -R grafana` command. + +In `grafana_servers`, the following fields cannot be modified after the deployment is completed: + +- `host` +- `port` +- `deploy_dir` +- `arch` +- `os` + +`grafana_servers` configuration example： + +```yaml +grafana_servers: + - host: 10.0.1.11 + dashboard_dir: /local/dashboard/dir +``` + +### `alertmanager_servers` + +`alertmanager_servers` specifies the machines to which the Alertmanager service is deployed. You can also specify the service configuration on each machine. `alertmanager_servers` is an array. Each array element contains the following fields: + +- `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. +- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. +- `web_port`: specify the port on which Alertmanager provides webpage services. The default value is "9093". +- `cluster_port`: Specify the port on which Alertmanger communicates with Alertmanagers. The default value is "9094". +- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. +- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. +- `log_dir`: specifies the log directory. If the field not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". +- `config_file`: specifies a local file. The specified file will be sent to the target machine as the configuration for Alertmanager during the initialization phase of the cluster configuration. +- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. +- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` block. +- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` block (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` block. + +In `alertmanager_servers`, the following fields cannot be modified after the deployment is completed: + +- `host` +- `web_port` +- `cluster_port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` + +`alertmanager_servers` configuration example： + +```yaml +alertmanager_servers: + - host: 10.0.1.11 + config_file: /local/config/file + - host: 10.0.1.12 + config_file: /local/config/file +``` From 045211e13022536e56e7e9920ce692437a112fe3 Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 14 Apr 2021 10:23:51 +0800 Subject: [PATCH 02/14] Update tiup-dm-topology-reference.md --- tiup/tiup-dm-topology-reference.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 59b055750f0fe..0463044e32bf4 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -67,7 +67,7 @@ In the example, the configuration specifies that the `tidb` user is used to star - `master`: configuration related to the DM master service. For all the supported configuration items, see [DM-master Configuration File](https://docs.pingcap.com/zh/tidb-data-migration/stable/dm-master-configuration-file). - `worker`: configuration related to the DM worker service, For all the supported configuration items, see [DM-worker Configuration File](https://docs.pingcap.com/zh/tidb-data-migration/stable/dm-worker-configuration-file). -`server_configs` configuration example: +A `server_configs` configuration example: ```yaml server_configs: @@ -112,7 +112,7 @@ In the `master_servers` block, the following fields cannot be modified after the - `os` - `v1_source_path` -`master_servers` configuration example: +A `master_servers` configuration example: ```yaml master_servers: @@ -165,7 +165,7 @@ In the `worker_servers` block, the following fields cannot be modified after the - `arch` - `os` -`worker_servers` configuration example: +A `worker_servers` configuration example: ```yaml worker_servers: @@ -208,7 +208,7 @@ In the `monitoring_servers` block, the following fields cannot be modified after - `arch` - `os` -`monitoring_servers` configuration example: +A `monitoring_servers` configuration example: ```yaml monitoring_servers: @@ -246,7 +246,7 @@ In `grafana_servers`, the following fields cannot be modified after the deployme - `arch` - `os` -`grafana_servers` configuration example： +A `grafana_servers` configuration example： ```yaml grafana_servers: @@ -282,7 +282,7 @@ In `alertmanager_servers`, the following fields cannot be modified after the dep - `arch` - `os` -`alertmanager_servers` configuration example： +An `alertmanager_servers` configuration example： ```yaml alertmanager_servers: From f4bba1a0a3f7263bf3da868c5fbd6998583d2427 Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 14 Apr 2021 10:30:16 +0800 Subject: [PATCH 03/14] Update tiup-dm-topology-reference.md --- tiup/tiup-dm-topology-reference.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 0463044e32bf4..af3c46282b87f 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -87,11 +87,11 @@ server_configs: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. - `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. - `name`: specifies the name of the DM master instance. The name must be unique for different instances. Otherwise, the cluster cannot be deployed. -- `port`: specifies the port on which DM master provides services. The default values is "8261". +- `port`: specifies the port on which DM master provides services. The default value is "8261". - `peer_port`: specifies the port that DM masters use to communicate with each other. The default value is "8291". - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. -- `log_dir`: specifies the log directory. If the field not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. - `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". - `config`: the configuration rules of this field are the same as that of `master` in the `server_configs` block. If `config` is specified, the configuration of `config` will be merged with the configuration of `master` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. @@ -144,10 +144,10 @@ master_servers: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. - `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. - `name`: specifies the name of the DM worker instance. The name must be unique for different instances. Otherwise, the cluster cannot be deployed. -- `port`: specifies the port on which DM worker provides services. The default values is "8262". +- `port`: specifies the port on which DM worker provides services. The default value is "8262". - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. -- `log_dir`: specifies the log directory. If the field not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. - `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". - `config`: the configuration rules of this field are the same as that of `worker` in the `server_configs` block. If `config` is specified, the configuration of `config` will be merged with the configuration of `worker` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. @@ -187,10 +187,10 @@ worker_servers: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. - `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. -- `port`: specifies the port on which Prometheus provides services. The default values is "9090". +- `port`: specifies the port on which Prometheus provides services. The default value is "9090". - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. -- `log_dir`: specifies the log directory. If the field not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. - `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". - `storage_retention`: specifies the retention time of the Prometheus monitoring data. The default value is "15d". - `rule_dir`: specifies a local directory where the complete `*.rules.yml` files are located. The files in the specified directory will be sent to the target machine as the Prometheus rules during the initialization phase of the cluster configuration. @@ -222,7 +222,7 @@ monitoring_servers: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. - `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. -- `port`: specifies the port on which Grafana provides services. The default values is "3000". +- `port`: specifies the port on which Grafana provides services. The default value is "3000". - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. - `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` block. @@ -264,7 +264,7 @@ grafana_servers: - `cluster_port`: Specify the port on which Alertmanger communicates with Alertmanagers. The default value is "9094". - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. -- `log_dir`: specifies the log directory. If the field not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. - `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". - `config_file`: specifies a local file. The specified file will be sent to the target machine as the configuration for Alertmanager during the initialization phase of the cluster configuration. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. From f33db4e9abc9e7e7980e360ee07bd4c731898ef8 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Wed, 14 Apr 2021 17:41:45 +0800 Subject: [PATCH 04/14] Update tiup/tiup-dm-topology-reference.md Co-authored-by: Ran --- tiup/tiup-dm-topology-reference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index af3c46282b87f..140c2d19929aa 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -1,5 +1,5 @@ --- -title: Topology Configuration File for DM Cluster Deployment using TiUP +title: Topology Configuration File for DM Cluster Deployment Using TiUP --- # Topology Configuration File for DM Cluster Deployment using TiUP From 66c67c68cc6778d2c63694c8a54405e68af8fd2f Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Wed, 14 Apr 2021 17:41:57 +0800 Subject: [PATCH 05/14] Update tiup/tiup-dm-topology-reference.md Co-authored-by: Ran --- tiup/tiup-dm-topology-reference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 140c2d19929aa..aa65980c82891 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -8,7 +8,7 @@ To deploy or scale a TiDB Data Migration (DM) cluster, you need to provide a top Here is an [example topology file](https://github.com/pingcap/tiup/blob/master/embed/templates/examples/dm/topology.example.yaml) for your reference. -## File Structure +## File structure The topology file of a DM cluster might contain the following blocks: From 02238f478b21308d19a8e136598439f0f72f8976 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Wed, 14 Apr 2021 17:42:08 +0800 Subject: [PATCH 06/14] Update tiup/tiup-dm-topology-reference.md Co-authored-by: Ran --- tiup/tiup-dm-topology-reference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index aa65980c82891..5c8ed031842f9 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -2,7 +2,7 @@ title: Topology Configuration File for DM Cluster Deployment Using TiUP --- -# Topology Configuration File for DM Cluster Deployment using TiUP +# Topology Configuration File for DM Cluster Deployment Using TiUP To deploy or scale a TiDB Data Migration (DM) cluster, you need to provide a topology file to describe the cluster topology. Similarly, to modify the cluster topology, you need to modify the topology file. The difference is that you can only modify a part of the fields in the topology file. From cf60c1267cbdfb084a71d250149c9ec60e27ce44 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Wed, 14 Apr 2021 17:42:15 +0800 Subject: [PATCH 07/14] Update tiup/tiup-dm-topology-reference.md Co-authored-by: Ran --- tiup/tiup-dm-topology-reference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 5c8ed031842f9..697478876231d 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -10,7 +10,7 @@ Here is an [example topology file](https://github.com/pingcap/tiup/blob/master/e ## File structure -The topology file of a DM cluster might contain the following blocks: +The topology file of a DM cluster might contain the following sections: - [global](/tiup/tiup-dm-topology-reference.md#global): the global configuration of the cluster. Some of the configuration items use the default values on the cluster, and you can configure them separately in each instance. - [server_configs](/tiup/tiup-dm-topology-reference.md#server_configs): the global configuration of the components. You can configure each component separately. If an instance has a configuration item with the same name, the items configured in the instance will take effect. From be3a11641cb53da5505dbe852dfb4a9f7eb9654a Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 14 Apr 2021 19:01:19 +0800 Subject: [PATCH 08/14] Update tiup-dm-topology-reference.md --- tiup/tiup-dm-topology-reference.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 697478876231d..1d96c5d5d8e39 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -10,19 +10,19 @@ Here is an [example topology file](https://github.com/pingcap/tiup/blob/master/e ## File structure -The topology file of a DM cluster might contain the following sections: +A topology configuration file for DM cluster deployment using TiUP might contain the following sections: -- [global](/tiup/tiup-dm-topology-reference.md#global): the global configuration of the cluster. Some of the configuration items use the default values on the cluster, and you can configure them separately in each instance. -- [server_configs](/tiup/tiup-dm-topology-reference.md#server_configs): the global configuration of the components. You can configure each component separately. If an instance has a configuration item with the same name, the items configured in the instance will take effect. -- [master_servers](/tiup/tiup-dm-topology-reference.md#master_servers): the configuration of DM master instance. The block is used to specify the machines to which the master service of the DM component is deployed. -- [worker_servers](/tiup/tiup-dm-topology-reference.md#worker_servers): the configuration of DM worker instance. The block is used to specify the machines to which the worker service of the DM component is deployed. -- [monitoring_servers](/tiup/tiup-cluster-topology-reference.md#monitoring_servers): specifies the machines to which the Prometheus instances are deployed. TiUP supports the deployment of multiple Prometheus instances, but only the first instance is actually in use. -- [grafana_servers](/tiup/tiup-cluster-topology-reference.md#grafana_servers): the configuration of Grafana instances. The block is used to specify the machines to which the Grafana instances are deployed. -- [alertmanager_servers](/tiup/tiup-cluster-topology-reference.md#alertmanager_servers): the configuration of the Alertemanager instances. The block is used to specify the machines to which the Alertmanager instances are deployed. +- [global](#global): the cluster's global configuration. Some of the configuration items use the default values on the cluster, and you can configure them separately in each instance. +- [server_configs](#server_configs): the global configuration of the components. You can configure each component separately. If an instance has a configuration item with the same name, the items configured in the instance will take effect. +- [master_servers](#master_servers): the configuration of DM master instance. The block is used to specify the machines to which the master service of the DM component is deployed. +- [worker_servers](#worker_servers): the configuration of DM worker instance. The block is used to specify the machines to which the worker service of the DM component is deployed. +- [monitoring_servers](#monitoring_servers): specifies the machines to which the Prometheus instances are deployed. TiUP supports the deployment of multiple Prometheus instances, but only the first instance is actually in use. +- [grafana_servers](#grafana_servers): the configuration of Grafana instances. The block is used to specify the machines to which the Grafana instances are deployed. +- [alertmanager_servers](#alertmanager_servers): the configuration of the Alertemanager instances. The block is used to specify the machines to which the Alertmanager instances are deployed. ### `global` -The `global` block corresponds to the global configuration of the cluster and contains the following fields: +The `global` section corresponds to the global configuration of the cluster and contains the following fields: - `user`: the user to start the deployed cluster. The default value is "tidb". If the user specified in the `` field does not exist on the target machine, TiUP will automatically try to create the user. - `group`: the user group to which a user belongs when the user is automatically created. The default value is the same as the `` field. If the specified group does not exist, it will be created automatically. From bea647aa859010ab99f92fd6077a46a0b6d73aac Mon Sep 17 00:00:00 2001 From: qiancai Date: Thu, 15 Apr 2021 15:25:45 +0800 Subject: [PATCH 09/14] align the translation with https://github.com/pingcap/docs/pull/5314/files --- tiup/tiup-dm-topology-reference.md | 118 ++++++++++++++--------------- 1 file changed, 59 insertions(+), 59 deletions(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 1d96c5d5d8e39..cc92e7592d0c5 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -4,32 +4,32 @@ title: Topology Configuration File for DM Cluster Deployment Using TiUP # Topology Configuration File for DM Cluster Deployment Using TiUP -To deploy or scale a TiDB Data Migration (DM) cluster, you need to provide a topology file to describe the cluster topology. Similarly, to modify the cluster topology, you need to modify the topology file. The difference is that you can only modify a part of the fields in the topology file. +To deploy or scale a TiDB Data Migration (DM) cluster, you need to provide a topology file ([sample](https://github.com/pingcap/tiup/blob/master/embed/templates/examples/dm/topology.example.yaml)) to describe the cluster topology. -Here is an [example topology file](https://github.com/pingcap/tiup/blob/master/embed/templates/examples/dm/topology.example.yaml) for your reference. +Similarly, to modify the cluster topology, you need to modify the topology file. The difference is that you can only modify a part of the fields in the topology file. This document introduces each section of the topology file and each field in each section. ## File structure A topology configuration file for DM cluster deployment using TiUP might contain the following sections: - [global](#global): the cluster's global configuration. Some of the configuration items use the default values on the cluster, and you can configure them separately in each instance. -- [server_configs](#server_configs): the global configuration of the components. You can configure each component separately. If an instance has a configuration item with the same name, the items configured in the instance will take effect. -- [master_servers](#master_servers): the configuration of DM master instance. The block is used to specify the machines to which the master service of the DM component is deployed. -- [worker_servers](#worker_servers): the configuration of DM worker instance. The block is used to specify the machines to which the worker service of the DM component is deployed. -- [monitoring_servers](#monitoring_servers): specifies the machines to which the Prometheus instances are deployed. TiUP supports the deployment of multiple Prometheus instances, but only the first instance is actually in use. -- [grafana_servers](#grafana_servers): the configuration of Grafana instances. The block is used to specify the machines to which the Grafana instances are deployed. -- [alertmanager_servers](#alertmanager_servers): the configuration of the Alertemanager instances. The block is used to specify the machines to which the Alertmanager instances are deployed. +- [server_configs](#server_configs): the components' global configuration. You can configure each component separately. If an instance has a configuration item with the same name, the instance's configuration item will take effect. +- [master_servers](#master_servers): the configuration of DM master instance. The configuration specifies the machines to which the master service of the DM component is deployed. +- [worker_servers](#worker_servers): the configuration of DM worker instance. The configuration specifies the machines to which the worker service of the DM component is deployed. +- [monitoring_servers](#monitoring_servers): specifies the machines to which the Prometheus instances are deployed. TiUP supports deploying multiple Prometheus instances but only the first instance is used. +- [grafana_servers](#grafana_servers): the configuration of the Grafana instances. The configuration specifies the machines to which the Grafana instances are deployed. +- [alertmanager_servers](#alertmanager_servers): the configuration of the Alertemanager instances. The configuration specifies the machines to which the Alertmanager instances are deployed. ### `global` -The `global` section corresponds to the global configuration of the cluster and contains the following fields: +The `global` section corresponds to the cluster's global configuration and has the following fields: - `user`: the user to start the deployed cluster. The default value is "tidb". If the user specified in the `` field does not exist on the target machine, TiUP will automatically try to create the user. - `group`: the user group to which a user belongs when the user is automatically created. The default value is the same as the `` field. If the specified group does not exist, it will be created automatically. - `ssh_port`: the SSH port to connect to the target machine for operations. The default value is "22". - `deploy_dir`: the deployment directory for each component. The default value is "deploy". The application rules are as follows: - If the absolute path `deploy_dir` is configured at the instance level, the actual deployment directory is the `deploy_dir` configured for the instance. - - For each instance, if `deploy_dir` is not configured, the default value is the relative path `-`. + - For each instance, if you do not configure `deploy_dir`, the default value is the relative path `-`. - If `global.deploy_dir` is set to an absolute path, the component is deployed to `/` directory. - If `global.deploy_dir` is set to a relative path, the component is deployed to `/home///` directory. - `data_dir`: the data directory. The default value is "data". The application rules are as follows. @@ -42,11 +42,11 @@ The `global` section corresponds to the global configuration of the cluster and - If `log_dir` is a relative path, the component logs will be stored in `/`. For the calculation rules of ``, see the application rules of the `deploy_dir` field. - `os`: the operating system of the target machine. The field controls which operating system to adapt to for the components pushed to the target machine. The default value is "linux". - `arch`: the CPU architecture of the target machine. The field controls which platform to adapt to for the binary packages pushed to the target machine. The supported values are "amd64" and "arm64". The default value is "amd64". -- `resource_control`: runtime resource control. All configurations under this field will be written to the `service` file of systemd. By default, the runtime resource is unlimited. The supported resources for control are as follows: +- `resource_control`: runtime resource control. All configurations in this field are written to the service file of systemd. There is no limit by default. The resources that can be controlled are as follows: - `memory_limit`: limits the maximum memory at runtime. For example, "2G" means that the maximum memory of 2 GB can be used. - `cpu_quota`: limits the maximum CPU usage at runtime. For example, "200%". - - `io_read_bandwidth_max`: limits the maximum bandwidth for read disk IO. For example, "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M". - - `io_write_bandwidth_max`: limits the maximum bandwidth of write disk IO. For example, "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M". + - `io_read_bandwidth_max`: limits the maximum I/O bandwidth for disk reads. For example, "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M". + - `io_write_bandwidth_max`: limits the maximum I/O bandwidth for disk writes. For example, "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M". - `limit_core`: controls the size of core dump. A `global` configuration example: @@ -62,12 +62,12 @@ In the example, the configuration specifies that the `tidb` user is used to star ### `server_configs` -`server_configs` is used to configure the service and generate the configuration file for each component. Similar to the `global` block, the configurations in the `server_configs` block can be overridden by the configurations with the same names in the instance. The block mainly contains the following fields: +`server_configs` is used to configure services and to generate configuration files for each component. Similar to the `global` section, the configurations in the `server_configs` section can be overwritten by the configurations with the same names in an instance. `server_configs` mainly contains the following fields: - `master`: configuration related to the DM master service. For all the supported configuration items, see [DM-master Configuration File](https://docs.pingcap.com/zh/tidb-data-migration/stable/dm-master-configuration-file). - `worker`: configuration related to the DM worker service, For all the supported configuration items, see [DM-worker Configuration File](https://docs.pingcap.com/zh/tidb-data-migration/stable/dm-worker-configuration-file). -A `server_configs` configuration example: +A `server_configs` configuration example is as follows: ```yaml server_configs: @@ -85,21 +85,21 @@ server_configs: `master_servers` specifies the machines to which the master node of the DM component is deployed. You can also specify the service configuration on each machine. `master_servers` is an array. Each array element contains the following fields: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. -- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. +- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` section is used. - `name`: specifies the name of the DM master instance. The name must be unique for different instances. Otherwise, the cluster cannot be deployed. - `port`: specifies the port on which DM master provides services. The default value is "8261". -- `peer_port`: specifies the port that DM masters use to communicate with each other. The default value is "8291". -- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. -- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. -- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `peer_port`: specifies the port for communication between DM masters. The default value is "8291". +- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. +- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. +- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. - `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". -- `config`: the configuration rules of this field are the same as that of `master` in the `server_configs` block. If `config` is specified, the configuration of `config` will be merged with the configuration of `master` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. -- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. -- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` block. -- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` block (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` block. +- `config`: the configuration rules of this field are the same as that of `master` in the `server_configs` section. If `config` is specified, the configuration of `config` will be merged with the configuration of `master` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. +- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. +- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. +- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` section (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` section. - `v1_source_path`: when upgrading from v1.0.x, you can specify the directory where the configuration file of the V1 source is located in this field. -In the `master_servers` block, the following fields cannot be modified after the deployment is completed: +In the `master_servers` section, the following fields cannot be modified after the deployment is completed: - `host` - `name` @@ -112,7 +112,7 @@ In the `master_servers` block, the following fields cannot be modified after the - `os` - `v1_source_path` -A `master_servers` configuration example: +A `master_servers` configuration example is as follows: ```yaml master_servers: @@ -142,19 +142,19 @@ master_servers: `worker_servers` specifies the machines to which the master node of the DM component is deployed. You can also specify the service configuration on each machine. `worker_servers` is an array. Each array element contains the following fields: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. -- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. +- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` section is used. - `name`: specifies the name of the DM worker instance. The name must be unique for different instances. Otherwise, the cluster cannot be deployed. - `port`: specifies the port on which DM worker provides services. The default value is "8262". -- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. -- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. -- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. +- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. +- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. - `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". -- `config`: the configuration rules of this field are the same as that of `worker` in the `server_configs` block. If `config` is specified, the configuration of `config` will be merged with the configuration of `worker` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. -- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. -- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` block. -- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` block (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` block. +- `config`: the configuration rules of this field are the same as that of `worker` in the `server_configs` section. If `config` is specified, the configuration of `config` will be merged with the configuration of `worker` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. +- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. +- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. +- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` section (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` section. -In the `worker_servers` block, the following fields cannot be modified after the deployment is completed: +In the `worker_servers` section, the following fields cannot be modified after the deployment is completed: - `host` - `name` @@ -165,7 +165,7 @@ In the `worker_servers` block, the following fields cannot be modified after the - `arch` - `os` -A `worker_servers` configuration example: +A `worker_servers` configuration example is as follows: ```yaml worker_servers: @@ -186,19 +186,19 @@ worker_servers: `monitoring_servers` specifies the machines to which the Prometheus service is deployed. You can also specify the service configuration on the machine. `monitoring_servers` is an array. Each array element contains the following fields: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. -- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. +- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` section is used. - `port`: specifies the port on which Prometheus provides services. The default value is "9090". -- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. -- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. -- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. +- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. +- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. - `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". - `storage_retention`: specifies the retention time of the Prometheus monitoring data. The default value is "15d". - `rule_dir`: specifies a local directory where the complete `*.rules.yml` files are located. The files in the specified directory will be sent to the target machine as the Prometheus rules during the initialization phase of the cluster configuration. -- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. -- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` block. -- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` block (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` block. +- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. +- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. +- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` section (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` section. -In the `monitoring_servers` block, the following fields cannot be modified after the deployment is completed: +In the `monitoring_servers` section, the following fields cannot be modified after the deployment is completed: - `host` - `port` @@ -208,7 +208,7 @@ In the `monitoring_servers` block, the following fields cannot be modified after - `arch` - `os` -A `monitoring_servers` configuration example: +A `monitoring_servers` configuration example is as follows: ```yaml monitoring_servers: @@ -221,15 +221,15 @@ monitoring_servers: `grafana_servers` specifies the machines to which the Grafana service is deployed. You can also specify the service configuration on the machine. `grafana_servers` is an array. Each array element contains the following fields: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. -- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. +- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` section is used. - `port`: specifies the port on which Grafana provides services. The default value is "3000". -- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. -- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. -- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` block. +- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. +- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. +- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. - `username`: specifies the username of the Grafana login screen. - `password`: specifies the corresponding password of Grafana. - `dashboard_dir`: specifies a local directory where the complete `dashboard(*.json)` files are located. The files in the specified directory will be sent to the target machine as Grafana dashboards during the initialization phase of the cluster configuration. -- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` block (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` block. +- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` section (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` section. > **Note:** > @@ -246,7 +246,7 @@ In `grafana_servers`, the following fields cannot be modified after the deployme - `arch` - `os` -A `grafana_servers` configuration example： +A `grafana_servers` configuration example is as follows: ```yaml grafana_servers: @@ -259,17 +259,17 @@ grafana_servers: `alertmanager_servers` specifies the machines to which the Alertmanager service is deployed. You can also specify the service configuration on each machine. `alertmanager_servers` is an array. Each array element contains the following fields: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. -- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` block is used. +- `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` section is used. - `web_port`: specify the port on which Alertmanager provides webpage services. The default value is "9093". - `cluster_port`: Specify the port on which Alertmanger communicates with Alertmanagers. The default value is "9094". -- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` block. -- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` block. -- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` block. +- `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. +- `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. +- `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. - `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". - `config_file`: specifies a local file. The specified file will be sent to the target machine as the configuration for Alertmanager during the initialization phase of the cluster configuration. -- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` block. -- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` block. -- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` block (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` block. +- `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. +- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. +- `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` section (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` section. In `alertmanager_servers`, the following fields cannot be modified after the deployment is completed: @@ -282,7 +282,7 @@ In `alertmanager_servers`, the following fields cannot be modified after the dep - `arch` - `os` -An `alertmanager_servers` configuration example： +An `alertmanager_servers` configuration example is as follows: ```yaml alertmanager_servers: From dbee63f9412fe77a5e601a4a834b77c6ea94d999 Mon Sep 17 00:00:00 2001 From: qiancai Date: Thu, 15 Apr 2021 15:40:37 +0800 Subject: [PATCH 10/14] Update tiup-dm-topology-reference.md --- tiup/tiup-dm-topology-reference.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index cc92e7592d0c5..17b709c3f626c 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -92,7 +92,7 @@ server_configs: - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. - `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. -- `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". +- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is the string type. The field value is the ID of the NUMA node, such as "0,1". - `config`: the configuration rules of this field are the same as that of `master` in the `server_configs` section. If `config` is specified, the configuration of `config` will be merged with the configuration of `master` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. - `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. @@ -148,7 +148,7 @@ master_servers: - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. - `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. -- `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". +- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is the string type. The field value is the ID of the NUMA node, such as "0,1". - `config`: the configuration rules of this field are the same as that of `worker` in the `server_configs` section. If `config` is specified, the configuration of `config` will be merged with the configuration of `worker` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. - `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. @@ -191,7 +191,7 @@ worker_servers: - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. - `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. -- `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". +- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is the string type. The field value is the ID of the NUMA node, such as "0,1" - `storage_retention`: specifies the retention time of the Prometheus monitoring data. The default value is "15d". - `rule_dir`: specifies a local directory where the complete `*.rules.yml` files are located. The files in the specified directory will be sent to the target machine as the Prometheus rules during the initialization phase of the cluster configuration. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. @@ -265,7 +265,7 @@ grafana_servers: - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. - `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. -- `numa_node`: assigns the NUMA policy to the instance. If the field is specified, make sure that [numactl](https://linux.die.net/man/8/numactl) is installed on the target machine, then [numactl](https://linux.die.net/man/8/numactl) will assign the cpubind and membind policies. The field value type is `STRING`. The field value is the NUMA node ID, for example, "0,1". +- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is the string type. The field value is the ID of the NUMA node, such as "0,1" - `config_file`: specifies a local file. The specified file will be sent to the target machine as the configuration for Alertmanager during the initialization phase of the cluster configuration. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. - `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. From d82073c8a45c0a4d3134b50ff0439c77c6b05f4b Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Fri, 16 Apr 2021 11:22:02 +0800 Subject: [PATCH 11/14] Apply suggestions from code review Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com> Co-authored-by: SIGSEGV Co-authored-by: Allen Zhong --- tiup/tiup-dm-topology-reference.md | 36 +++++++++++++++--------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 17b709c3f626c..47eca5dce7107 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -6,14 +6,14 @@ title: Topology Configuration File for DM Cluster Deployment Using TiUP To deploy or scale a TiDB Data Migration (DM) cluster, you need to provide a topology file ([sample](https://github.com/pingcap/tiup/blob/master/embed/templates/examples/dm/topology.example.yaml)) to describe the cluster topology. -Similarly, to modify the cluster topology, you need to modify the topology file. The difference is that you can only modify a part of the fields in the topology file. This document introduces each section of the topology file and each field in each section. +Similarly, to modify the cluster topology, you need to modify the topology file. The difference is that, after the cluster is deployed, you can only modify a part of the fields in the topology file. This document introduces each section of the topology file and each field in each section. ## File structure A topology configuration file for DM cluster deployment using TiUP might contain the following sections: -- [global](#global): the cluster's global configuration. Some of the configuration items use the default values on the cluster, and you can configure them separately in each instance. -- [server_configs](#server_configs): the components' global configuration. You can configure each component separately. If an instance has a configuration item with the same name, the instance's configuration item will take effect. +- [global](#global): the cluster's global configuration. Some of the configuration items use the default values of the cluster, and you can configure them separately in each instance. +- [server_configs](#server_configs): the components' global configuration. You can configure each component separately. If an instance has a configuration item with the same key, the instance's configuration item will take effect. - [master_servers](#master_servers): the configuration of DM master instance. The configuration specifies the machines to which the master service of the DM component is deployed. - [worker_servers](#worker_servers): the configuration of DM worker instance. The configuration specifies the machines to which the worker service of the DM component is deployed. - [monitoring_servers](#monitoring_servers): specifies the machines to which the Prometheus instances are deployed. TiUP supports deploying multiple Prometheus instances but only the first instance is used. @@ -27,19 +27,19 @@ The `global` section corresponds to the cluster's global configuration and has t - `user`: the user to start the deployed cluster. The default value is "tidb". If the user specified in the `` field does not exist on the target machine, TiUP will automatically try to create the user. - `group`: the user group to which a user belongs when the user is automatically created. The default value is the same as the `` field. If the specified group does not exist, it will be created automatically. - `ssh_port`: the SSH port to connect to the target machine for operations. The default value is "22". -- `deploy_dir`: the deployment directory for each component. The default value is "deploy". The application rules are as follows: +- `deploy_dir`: the deployment directory for each component. The default value is "deploy". The construction rules are as follows: - If the absolute path `deploy_dir` is configured at the instance level, the actual deployment directory is the `deploy_dir` configured for the instance. - For each instance, if you do not configure `deploy_dir`, the default value is the relative path `-`. - - If `global.deploy_dir` is set to an absolute path, the component is deployed to `/` directory. - - If `global.deploy_dir` is set to a relative path, the component is deployed to `/home///` directory. -- `data_dir`: the data directory. The default value is "data". The application rules are as follows. + - If `global.deploy_dir` is set to an absolute path, the component is deployed to the `/` directory. + - If `global.deploy_dir` is set to a relative path, the component is deployed to the `/home///` directory. +- `data_dir`: the data directory. The default value is "data". The construction rules are as follows. - If the absolute path `data_dir` is configured at the instance level, the actual data directory is the `data_dir` configured for the instance. - For each instance, if `data_dir` is not configured, the default value is ``. - - If `data_dir` is set to a relative path, the component data is stored in `/`. For the calculation rules of ``, see the application rules of the `deploy_dir` field. -- `log_dir`: the data directory. The default value is "log". The application rules are as follows. + - If `data_dir` is set to a relative path, the component data is stored in `/`. For the construction rules of ``, see the construction rules of the `deploy_dir` field. +- `log_dir`: the data directory. The default value is "log". The construction rules are as follows. - If the absolute path of `log_dir` is configured at the instance level, the actual log directory is the `log_dir` configured for the instance. - For each instance, if `log_dir` is not configured by the user, the default value is ``. - - If `log_dir` is a relative path, the component logs will be stored in `/`. For the calculation rules of ``, see the application rules of the `deploy_dir` field. + - If `log_dir` is a relative path, the component logs will be stored in `/`. For the construction rules of ``, see the construction rules of the `deploy_dir` field. - `os`: the operating system of the target machine. The field controls which operating system to adapt to for the components pushed to the target machine. The default value is "linux". - `arch`: the CPU architecture of the target machine. The field controls which platform to adapt to for the binary packages pushed to the target machine. The supported values are "amd64" and "arm64". The default value is "amd64". - `resource_control`: runtime resource control. All configurations in this field are written to the service file of systemd. There is no limit by default. The resources that can be controlled are as follows: @@ -64,8 +64,8 @@ In the example, the configuration specifies that the `tidb` user is used to star `server_configs` is used to configure services and to generate configuration files for each component. Similar to the `global` section, the configurations in the `server_configs` section can be overwritten by the configurations with the same names in an instance. `server_configs` mainly contains the following fields: -- `master`: configuration related to the DM master service. For all the supported configuration items, see [DM-master Configuration File](https://docs.pingcap.com/zh/tidb-data-migration/stable/dm-master-configuration-file). -- `worker`: configuration related to the DM worker service, For all the supported configuration items, see [DM-worker Configuration File](https://docs.pingcap.com/zh/tidb-data-migration/stable/dm-worker-configuration-file). +- `master`: The configuration related to the DM-master service. For all the supported configuration items, see [DM-master Configuration File](https://docs.pingcap.com/tidb-data-migration/stable/dm-master-configuration-file). +- `worker`: The configuration related to the DM-worker service, For all the supported configuration items, see [DM-worker Configuration File](https://docs.pingcap.com/tidb-data-migration/stable/dm-worker-configuration-file). A `server_configs` configuration example is as follows: @@ -86,16 +86,16 @@ server_configs: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. - `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` section is used. -- `name`: specifies the name of the DM master instance. The name must be unique for different instances. Otherwise, the cluster cannot be deployed. +- `name`: specifies the name of the DM-master instance. The name must be unique for different instances. Otherwise, the cluster cannot be deployed. - `port`: specifies the port on which DM master provides services. The default value is "8261". - `peer_port`: specifies the port for communication between DM masters. The default value is "8291". - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. - `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. -- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is the string type. The field value is the ID of the NUMA node, such as "0,1". +- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is a string type. The field value is the ID of the NUMA node, such as "0,1". - `config`: the configuration rules of this field are the same as that of `master` in the `server_configs` section. If `config` is specified, the configuration of `config` will be merged with the configuration of `master` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. -- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. +- `arch`: the architecture of the machine specified in the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. - `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` section (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` section. - `v1_source_path`: when upgrading from v1.0.x, you can specify the directory where the configuration file of the V1 source is located in this field. @@ -148,7 +148,7 @@ master_servers: - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. - `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. -- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is the string type. The field value is the ID of the NUMA node, such as "0,1". +- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is a string type. The field value is the ID of the NUMA node, such as "0,1". - `config`: the configuration rules of this field are the same as that of `worker` in the `server_configs` section. If `config` is specified, the configuration of `config` will be merged with the configuration of `worker` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. - `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. @@ -191,7 +191,7 @@ worker_servers: - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. - `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. -- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is the string type. The field value is the ID of the NUMA node, such as "0,1" +- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is a string type. The field value is the ID of the NUMA node, such as "0,1" - `storage_retention`: specifies the retention time of the Prometheus monitoring data. The default value is "15d". - `rule_dir`: specifies a local directory where the complete `*.rules.yml` files are located. The files in the specified directory will be sent to the target machine as the Prometheus rules during the initialization phase of the cluster configuration. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. @@ -265,7 +265,7 @@ grafana_servers: - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. - `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. -- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is the string type. The field value is the ID of the NUMA node, such as "0,1" +- `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is a string type. The field value is the ID of the NUMA node, such as "0,1" - `config_file`: specifies a local file. The specified file will be sent to the target machine as the configuration for Alertmanager during the initialization phase of the cluster configuration. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. - `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. From becddf3f87654aa07464aeb657ffa1ed512fdc0c Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Fri, 16 Apr 2021 11:23:05 +0800 Subject: [PATCH 12/14] Apply suggestions from code review Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com> --- tiup/tiup-dm-topology-reference.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 47eca5dce7107..8cfc2329276d9 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -14,8 +14,8 @@ A topology configuration file for DM cluster deployment using TiUP might contain - [global](#global): the cluster's global configuration. Some of the configuration items use the default values of the cluster, and you can configure them separately in each instance. - [server_configs](#server_configs): the components' global configuration. You can configure each component separately. If an instance has a configuration item with the same key, the instance's configuration item will take effect. -- [master_servers](#master_servers): the configuration of DM master instance. The configuration specifies the machines to which the master service of the DM component is deployed. -- [worker_servers](#worker_servers): the configuration of DM worker instance. The configuration specifies the machines to which the worker service of the DM component is deployed. +- [master_servers](#master_servers): the configuration of the DM-master instance. The configuration specifies the machines to which the master service of the DM component is deployed. +- [worker_servers](#worker_servers): the configuration of the DM-worker instance. The configuration specifies the machines to which the worker service of the DM component is deployed. - [monitoring_servers](#monitoring_servers): specifies the machines to which the Prometheus instances are deployed. TiUP supports deploying multiple Prometheus instances but only the first instance is used. - [grafana_servers](#grafana_servers): the configuration of the Grafana instances. The configuration specifies the machines to which the Grafana instances are deployed. - [alertmanager_servers](#alertmanager_servers): the configuration of the Alertemanager instances. The configuration specifies the machines to which the Alertmanager instances are deployed. From 6d28e81b354acfca10740212bc3bdcd2a149e770 Mon Sep 17 00:00:00 2001 From: qiancai Date: Fri, 16 Apr 2021 11:48:21 +0800 Subject: [PATCH 13/14] Update tiup-dm-topology-reference.md --- tiup/tiup-dm-topology-reference.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 8cfc2329276d9..6e9b95338c4c4 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -62,10 +62,10 @@ In the example, the configuration specifies that the `tidb` user is used to star ### `server_configs` -`server_configs` is used to configure services and to generate configuration files for each component. Similar to the `global` section, the configurations in the `server_configs` section can be overwritten by the configurations with the same names in an instance. `server_configs` mainly contains the following fields: +`server_configs` is used to configure services and to generate configuration files for each component. Similar to the `global` section, the configurations in the `server_configs` section can be overwritten by the configurations with the same keys in an instance. `server_configs` mainly contains the following fields: -- `master`: The configuration related to the DM-master service. For all the supported configuration items, see [DM-master Configuration File](https://docs.pingcap.com/tidb-data-migration/stable/dm-master-configuration-file). -- `worker`: The configuration related to the DM-worker service, For all the supported configuration items, see [DM-worker Configuration File](https://docs.pingcap.com/tidb-data-migration/stable/dm-worker-configuration-file). +- `master`: the configuration related to the DM-master service. For all the supported configuration items, see [DM-master Configuration File](https://docs.pingcap.com/tidb-data-migration/stable/dm-master-configuration-file). +- `worker`: the configuration related to the DM-worker service, For all the supported configuration items, see [DM-worker Configuration File](https://docs.pingcap.com/tidb-data-migration/stable/dm-worker-configuration-file). A `server_configs` configuration example is as follows: @@ -87,8 +87,8 @@ server_configs: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. - `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` section is used. - `name`: specifies the name of the DM-master instance. The name must be unique for different instances. Otherwise, the cluster cannot be deployed. -- `port`: specifies the port on which DM master provides services. The default value is "8261". -- `peer_port`: specifies the port for communication between DM masters. The default value is "8291". +- `port`: specifies the port on which DM-master provides services. The default value is "8261". +- `peer_port`: specifies the port for communication between DM-masters. The default value is "8291". - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. - `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. @@ -143,15 +143,15 @@ master_servers: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. - `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` section is used. -- `name`: specifies the name of the DM worker instance. The name must be unique for different instances. Otherwise, the cluster cannot be deployed. -- `port`: specifies the port on which DM worker provides services. The default value is "8262". +- `name`: specifies the name of the DM-worker instance. The name must be unique for different instances. Otherwise, the cluster cannot be deployed. +- `port`: specifies the port on which DM-worker provides services. The default value is "8262". - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. - `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section. - `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is a string type. The field value is the ID of the NUMA node, such as "0,1". - `config`: the configuration rules of this field are the same as that of `worker` in the `server_configs` section. If `config` is specified, the configuration of `config` will be merged with the configuration of `worker` in `server_configs` (if the two fields overlap, the configuration of this field takes effect), and then the configuration file is generated and distributed to the machine specified in the `host` field. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. -- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. +- `arch`: the architecture of the machine specified in the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. - `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` section (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` section. In the `worker_servers` section, the following fields cannot be modified after the deployment is completed: @@ -195,7 +195,7 @@ worker_servers: - `storage_retention`: specifies the retention time of the Prometheus monitoring data. The default value is "15d". - `rule_dir`: specifies a local directory where the complete `*.rules.yml` files are located. The files in the specified directory will be sent to the target machine as the Prometheus rules during the initialization phase of the cluster configuration. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. -- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. +- `arch`: the architecture of the machine specified in the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. - `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` section (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` section. In the `monitoring_servers` section, the following fields cannot be modified after the deployment is completed: @@ -225,7 +225,7 @@ monitoring_servers: - `port`: specifies the port on which Grafana provides services. The default value is "3000". - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. -- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. +- `arch`: the architecture of the machine specified in the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. - `username`: specifies the username of the Grafana login screen. - `password`: specifies the corresponding password of Grafana. - `dashboard_dir`: specifies a local directory where the complete `dashboard(*.json)` files are located. The files in the specified directory will be sent to the target machine as Grafana dashboards during the initialization phase of the cluster configuration. @@ -268,7 +268,7 @@ grafana_servers: - `numa_node`: allocates the NUMA policy to the instance. Before specifying this field, you need to make sure that the target machine has [numactl](https://linux.die.net/man/8/numactl) installed. If this field is specified, cpubind and membind policies are allocated using [numactl](https://linux.die.net/man/8/numactl). This field is a string type. The field value is the ID of the NUMA node, such as "0,1" - `config_file`: specifies a local file. The specified file will be sent to the target machine as the configuration for Alertmanager during the initialization phase of the cluster configuration. - `os`: the operating system of the machine specified in the `host` field. If the field is not specified, the default value is the `os` value configured in the `global` section. -- `arch`: the architecture of the machine specified by the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. +- `arch`: the architecture of the machine specified in the `host` field. If the field is not specified, the default value is the `arch` value configured in the `global` section. - `resource_control`: resource control on this service. If this field is specified, the configuration of this field will be merged with the configuration of `resource_control` in the `global` section (if the two fields overlap, the configuration of this field takes effect), and then the configuration file of systemd is generated and distributed to the machine specified in the `host` field. The configuration rules of this field are the same as that of `resource_control` in the `global` section. In `alertmanager_servers`, the following fields cannot be modified after the deployment is completed: From 494b022d6a2e4e57e04d165a8ba002f0cc380180 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Fri, 16 Apr 2021 18:41:53 +0800 Subject: [PATCH 14/14] Apply suggestions from code review Co-authored-by: Ran --- tiup/tiup-dm-topology-reference.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 6e9b95338c4c4..a1e951a3aa232 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -45,8 +45,8 @@ The `global` section corresponds to the cluster's global configuration and has t - `resource_control`: runtime resource control. All configurations in this field are written to the service file of systemd. There is no limit by default. The resources that can be controlled are as follows: - `memory_limit`: limits the maximum memory at runtime. For example, "2G" means that the maximum memory of 2 GB can be used. - `cpu_quota`: limits the maximum CPU usage at runtime. For example, "200%". - - `io_read_bandwidth_max`: limits the maximum I/O bandwidth for disk reads. For example, "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M". - - `io_write_bandwidth_max`: limits the maximum I/O bandwidth for disk writes. For example, "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M". + - `io_read_bandwidth_max`: limits the maximum I/O bandwidth for disk reads. For example, `"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M"`. + - `io_write_bandwidth_max`: limits the maximum I/O bandwidth for disk writes. For example, `"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M"`. - `limit_core`: controls the size of core dump. A `global` configuration example: @@ -58,7 +58,7 @@ global: memory_limit: "2G" ``` -In the example, the configuration specifies that the `tidb` user is used to start the cluster, and that each component is limited to a maximum of 2GB of memory when it is running. +In the example, the configuration specifies that the `tidb` user is used to start the cluster, and that each component is limited to a maximum of 2 GB of memory when it is running. ### `server_configs` @@ -216,7 +216,7 @@ monitoring_servers: rule_dir: /local/rule/dir ``` -### ``grafana_servers`` +### `grafana_servers` `grafana_servers` specifies the machines to which the Grafana service is deployed. You can also specify the service configuration on the machine. `grafana_servers` is an array. Each array element contains the following fields: @@ -233,9 +233,9 @@ monitoring_servers: > **Note:** > -> If the `dashboard_dir` field of `grafana_servers` is configured, after executing the `tiup cluster rename` command to rename the cluster, you need to do the following: +> If the `dashboard_dir` field of `grafana_servers` is configured, after executing the `tiup cluster rename` command to rename the cluster, you need to perform the following operations: > -> 1. In the local `dashboards` directory, update the value of the `datasource` field to the new cluster name (the `datasource` is named according to the cluster name). +> 1. In the local `dashboards` directory, update the value of the `datasource` field to the new cluster name (the `datasource` is named after the cluster name). > 2. Execute the `tiup cluster reload -R grafana` command. In `grafana_servers`, the following fields cannot be modified after the deployment is completed: @@ -260,8 +260,8 @@ grafana_servers: - `host`: specifies the machine to deploy to. The field value is an IP address and is mandatory. - `ssh_port`: specifies the SSH port to connect to the target machine for operations. If the field is not specified, the `ssh_port` in the `global` section is used. -- `web_port`: specify the port on which Alertmanager provides webpage services. The default value is "9093". -- `cluster_port`: Specify the port on which Alertmanger communicates with Alertmanagers. The default value is "9094". +- `web_port`: specify the port on which Alertmanager provides web services. The default value is "9093". +- `cluster_port`: Specify the communication port between one Alertmanger and other Alertmanager. The default value is "9094". - `deploy_dir`: specifies the deployment directory. If the field is not specified, or specified as a relative directory, the deployment directory is generated according to the `deploy_dir` configuration in the `global` section. - `data_dir`: specifies the data directory. If the field is not specified, or specified as a relative directory, the data directory is generated according to the `data_dir` configuration in the `global` section. - `log_dir`: specifies the log directory. If the field is not specified, or specified as a relative directory, the log directory is generated according to the `log_dir` configuration in the `global` section.