From f8db544e248d34619c7158861b055096e6918c70 Mon Sep 17 00:00:00 2001 From: DanielZhangQD Date: Tue, 24 Mar 2020 14:26:36 +0800 Subject: [PATCH 1/3] overall update --- zh/TOC.md | 27 +++-- zh/access-tidb.md | 14 ++- zh/backup-and-restore-using-helm-charts.md | 16 ++- zh/configure-a-tidb-cluster.md | 133 ++------------------- zh/configure-backup.md | 10 +- zh/deploy-tidb-operator.md | 37 +----- zh/destroy-a-tidb-cluster.md | 32 ++++- zh/monitor-a-tidb-cluster.md | 8 +- zh/notes-tidb-operator-v1.1.md | 22 ++++ zh/prerequisites.md | 28 +++++ zh/tidb-cluster-chart-config.md | 119 ++++++++++++++++++ 11 files changed, 255 insertions(+), 191 deletions(-) create mode 100644 zh/tidb-cluster-chart-config.md diff --git a/zh/TOC.md b/zh/TOC.md index 03afddbc6cf..4ef0602493d 100644 --- a/zh/TOC.md +++ b/zh/TOC.md @@ -19,12 +19,13 @@ - [阿里云上的 TiDB 集群](deploy-on-alibaba-cloud.md) - [访问 Kubernetes 上的 TiDB 集群](access-tidb.md) + 配置 + - [配置 Storage Class](configure-storage-class.md) + - [资源及容灾配置](configure-a-tidb-cluster.md) - [初始化集群](initialize-a-cluster.md) - - [配置集群](configure-a-tidb-cluster.md) - [通过 TidbCluster 配置集群](configure-cluster-using-tidbcluster.md) - - [配置备份](configure-backup.md) - - [配置 Storage Class](configure-storage-class.md) - [配置 TiDB Binlog Drainer](configure-tidb-binlog-drainer.md) + - [tidb-cluster chart 配置](tidb-cluster-chart-config.md) + - [tidb-backup chart 配置](configure-backup.md) + 监控 - [监控 TiDB 集群](monitor-a-tidb-cluster.md) - [通过 TidbMonitor 监控 TiDB 集群](monitor-using-tidbmonitor.md) @@ -32,20 +33,20 @@ - [销毁 TiDB 集群](destroy-a-tidb-cluster.md) - [重启 TiDB 集群](restart-a-tidb-cluster.md) - [维护 TiDB 集群所在节点](maintain-a-kubernetes-node.md) - + 备份与恢复 - - [基于 Helm Charts 的备份恢复](backup-and-restore-using-helm-charts.md) - + 基于 CRD 的备份恢复 - - [使用 Mydumper 备份 TiDB 集群到 GCS](backup-to-gcs.md) - - [使用 Loader 恢复 GCS 上的备份数据](restore-from-gcs.md) - - [使用 Mydumper 备份 TiDB 集群到兼容 S3 的存储](backup-to-s3.md) - - [使用 Loader 恢复 S3 兼容存储上的备份数据](restore-from-s3.md) - - [使用 BR 备份 TiDB 集群到兼容 S3 的存储](backup-to-aws-s3-using-br.md) - - [使用 BR 恢复 S3 兼容存储上的备份数据](restore-from-aws-s3-using-br.md) - - [使用 TiDB Lightning 恢复集群数据](restore-data-using-tidb-lightning.md) - [收集日志](collect-tidb-binlogs.md) - [TiDB Binlog 运维](maintain-tidb-binlog.md) - [集群故障自动转移](use-auto-failover.md) - [扩缩容](scale-a-tidb-cluster.md) ++ 备份与恢复 + - [基于 Helm Charts 的备份恢复](backup-and-restore-using-helm-charts.md) + + 基于 CRD 的备份恢复 + - [使用 Mydumper 备份 TiDB 集群到 GCS](backup-to-gcs.md) + - [使用 Loader 恢复 GCS 上的备份数据](restore-from-gcs.md) + - [使用 Mydumper 备份 TiDB 集群到兼容 S3 的存储](backup-to-s3.md) + - [使用 Loader 恢复 S3 兼容存储上的备份数据](restore-from-s3.md) + - [使用 BR 备份 TiDB 集群到兼容 S3 的存储](backup-to-aws-s3-using-br.md) + - [使用 BR 恢复 S3 兼容存储上的备份数据](restore-from-aws-s3-using-br.md) + - [使用 TiDB Lightning 恢复集群数据](restore-data-using-tidb-lightning.md) + 升级 - [TiDB 集群](upgrade-a-tidb-cluster.md) - [TiDB Operator](upgrade-tidb-operator.md) diff --git a/zh/access-tidb.md b/zh/access-tidb.md index 7f98324a0d9..cefc9add382 100644 --- a/zh/access-tidb.md +++ b/zh/access-tidb.md @@ -6,17 +6,21 @@ category: how-to # 访问 Kubernetes 上的 TiDB 集群 -在 Kubernetes 集群内访问 TiDB 时，使用 TiDB service 域名 `-tidb.` 即可。若需要在集群外访问，则需将 TiDB 服务端口暴露出去。在 `tidb-cluster` Helm chart 中，通过 `values.yaml` 文件中的 `tidb.service` 字段进行配置： +在 Kubernetes 集群内访问 TiDB 时，使用 TiDB service 域名 `-tidb.` 即可。 + +若需要在集群外访问，则需将 TiDB 服务端口暴露出去。在 `TidbCluster` CR 中，通过 `spec.tidb.service` 字段进行配置： {{< copyable "" >}} ```yaml -tidb: +spec: + ... + tidb: service: type: NodePort # externalTrafficPolicy: Cluster # annotations: - # cloud.google.com/load-balancer-type: Internal + # cloud.google.com/load-balancer-type: Internal ``` ## NodePort @@ -42,7 +46,7 @@ tidb: {{< copyable "shell-regular" >}} ```shell -kubectl -n get svc -tidb -ojsonpath="{.spec.ports[?(@.name=='mysql-client')].nodePort}{'\n'}" +kubectl -n get svc -tidb -ojsonpath="{.spec.ports[?(@.name=='mysql-client')].nodePort}{'\n'}" ``` 查看可通过哪些节点的 IP 访问 TiDB 服务，有两种情况： @@ -53,7 +57,7 @@ kubectl -n get svc -tidb -ojsonpath="{.spec.ports[?(@. {{< copyable "shell-regular" >}} ```shell - kubectl -n get pods -l "app.kubernetes.io/component=tidb,app.kubernetes.io/instance=" -ojsonpath="{range .items[*]}{.spec.nodeName}{'\n'}{end}" + kubectl -n get pods -l "app.kubernetes.io/component=tidb,app.kubernetes.io/instance=" -ojsonpath="{range .items[*]}{.spec.nodeName}{'\n'}{end}" ``` ## LoadBalancer diff --git a/zh/backup-and-restore-using-helm-charts.md b/zh/backup-and-restore-using-helm-charts.md index 6b390882263..c385e089225 100644 --- a/zh/backup-and-restore-using-helm-charts.md +++ b/zh/backup-and-restore-using-helm-charts.md @@ -9,12 +9,16 @@ aliases: ['/docs-cn/devmaintain/backup-and-store/'] 本文详细描述了如何对 Kubernetes 上的 TiDB 集群进行数据备份和数据恢复。本文使用的备份恢复方式是基于 Helm Charts 实现的。 -TiDB Operator 1.1 及以上版本推荐使用基于 CustomResourceDefinition (CRD) 实现的备份恢复方式实现，详情可参阅以下文档： - -- [备份 TiDB 集群到 GCS](backup-to-gcs.md) -- [恢复 GCS 上的备份数据](restore-from-gcs.md) -- [备份 TiDB 集群到兼容 S3 的存储](backup-to-s3.md) -- [恢复 S3 兼容存储上的备份数据](restore-from-s3.md) +TiDB Operator 1.1 及以上版本推荐使用基于 CustomResourceDefinition (CRD) 实现的备份恢复方式实现： + ++ 如果 TiDB 集群版本 < v3.1，可以参考以下文档： + - [使用 Mydumper 备份 TiDB 集群到 GCS](backup-to-gcs.md) + - [使用 Loader 恢复 GCS 上的备份数据](restore-from-gcs.md) + - [使用 Mydumper 备份 TiDB 集群到兼容 S3 的存储](backup-to-s3.md) + - [使用 Loader 恢复 S3 兼容存储上的备份数据](restore-from-s3.md) ++ 如果 TiDB 集群版本 >= v3.1，可以参考以下文档： + - [使用 BR 备份 TiDB 集群到兼容 S3 的存储](backup-to-aws-s3-using-br.md) + - [使用 BR 恢复 S3 兼容存储上的备份数据](restore-from-aws-s3-using-br.md) Kubernetes 上的 TiDB 集群支持两种备份策略： diff --git a/zh/configure-a-tidb-cluster.md b/zh/configure-a-tidb-cluster.md index 337c7504fe3..92391354634 100644 --- a/zh/configure-a-tidb-cluster.md +++ b/zh/configure-a-tidb-cluster.md @@ -1,120 +1,12 @@ --- -title: Kubernetes 上的 TiDB 集群配置 -summary: 介绍 Kubernetes 上 TiDB 集群的配置。 +title: Kubernetes 上的 TiDB 集群的资源配置以及容灾配置 +summary: 介绍 Kubernetes 上 TiDB 集群的的资源配置以及容灾配置。 category: reference --- -# Kubernetes 上的 TiDB 集群配置 - -本文介绍 Kubernetes 上 TiDB 集群的配置参数、资源配置，以及容灾配置。 - -## 配置参数 - -TiDB Operator 使用 Helm 部署和管理 TiDB 集群。通过 Helm 获取的配置文件默认提供了基本的配置，通过这个基本配置，可以快速启动一个 TiDB 集群。但是如果用户需要特殊配置或是用于生产环境，则需要根据以下配置参数列表手动配置对应的配置项。 - -> **注意：** -> -> 下文用 `values.yaml` 指代要修改的 TiDB 集群配置文件。 - -| 参数名 | 说明 | 默认值 | -| :----- | :---- | :----- | -| `rbac.create` | 是否启用 Kubernetes 的 RBAC | `true` | -| `clusterName` | TiDB 集群名，默认不设置该变量，`tidb-cluster` 会直接用执行安装时的 `ReleaseName` 代替 | `nil` | -| `extraLabels` | 添加额外的 labels 到 `TidbCluster` 对象 (CRD) 上，参考：[labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) | `{}` | -| `schedulerName` | TiDB 集群使用的调度器 | `tidb-scheduler` | -| `timezone` | TiDB 集群默认时区 | `UTC` | -| `pvReclaimPolicy` | TiDB 集群使用的 PV (Persistent Volume)的 reclaim policy | `Retain` | -| `services[0].name` | TiDB 集群对外暴露服务的名字 | `nil` | -| `services[0].type` | TiDB 集群对外暴露服务的类型，(从 `ClusterIP`、`NodePort`、`LoadBalancer` 中选择) | `nil` | -| `discovery.image` | TiDB 集群 PD 服务发现组件的镜像，该组件用于在 PD 集群第一次启动时，为各个 PD 实例提供服务发现功能以协调启动顺序 | `pingcap/tidb-operator:v1.0.0-beta.3` | -| `discovery.imagePullPolicy` | PD 服务发现组件镜像的拉取策略 | `IfNotPresent` | -| `discovery.resources.limits.cpu` | PD 服务发现组件的 CPU 资源限额 | `250m` | -| `discovery.resources.limits.memory` | PD 服务发现组件的内存资源限额 | `150Mi` | -| `discovery.resources.requests.cpu` | PD 服务发现组件的 CPU 资源请求 | `80m` | -| `discovery.resources.requests.memory` | PD 服务发现组件的内存资源请求 | `50Mi` | -| `enableConfigMapRollout` | 是否开启 TiDB 集群自动滚动更新。如果启用，则 TiDB 集群的 ConfigMap 变更时，TiDB 集群自动更新对应组件。该配置只在 tidb-operator v1.0 及以上版本才支持 | `false` | -| `pd.config` | 配置文件格式的 PD 的配置，请参考 [`pd/conf/config.toml`](https://github.com/pingcap/pd/blob/master/conf/config.toml) 查看默认 PD 配置文件（选择对应 PD 版本的 tag），可以参考 [PD 配置文件描述](https://pingcap.com/docs-cn/stable/reference/configuration/pd-server/configuration-file)查看配置参数的具体介绍（请选择对应的文档版本），这里只需要**按照配置文件中的格式修改配置** | TiDB Operator 版本 <= v1.0.0-beta.3，默认值为：
`nil`
TiDB Operator 版本 > v1.0.0-beta.3，默认值为：
`[log]`
`level = "info"`
`[replication]`
`location-labels = ["region", "zone", "rack", "host"]`
配置示例：
  `config:` \|
    `[log]`
    `level = "info"`
    `[replication]`
    `location-labels = ["region", "zone", "rack", "host"]` | -| `pd.replicas` | PD 的 Pod 数 | `3` | -| `pd.image` | PD 镜像 | `pingcap/pd:v3.0.0-rc.1` | -| `pd.imagePullPolicy` | PD 镜像的拉取策略 | `IfNotPresent` | -| `pd.logLevel` | PD 日志级别
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `pd.config` 配置：
`[log]`
`level = "info"` | `info` | -| `pd.storageClassName` | PD 使用的 storageClass，storageClassName 指代一种由 Kubernetes 集群提供的存储类型，不同的类可能映射到服务质量级别、备份策略或集群管理员确定的任意策略。详细参考：[storage-classes](https://kubernetes.io/docs/concepts/storage/storage-classes) | `local-storage` | -| `pd.maxStoreDownTime` | `pd.maxStoreDownTime` 指一个 store 节点断开连接多长时间后状态会被标记为 `down`，当状态变为 `down` 后，store 节点开始迁移数据到其它 store 节点
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `pd.config` 配置：
`[schedule]`
`max-store-down-time = "30m"` | `30m` | -| `pd.maxReplicas` | `pd.maxReplicas` 是 TiDB 集群的数据的副本数
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `pd.config` 配置：
`[replication]`
`max-replicas = 3` | `3` | -| `pd.resources.limits.cpu` | 每个 PD Pod 的 CPU 资源限额 | `nil` | -| `pd.resources.limits.memory` | 每个 PD Pod 的内存资源限额 | `nil` | -| `pd.resources.limits.storage` | 每个 PD Pod 的存储容量限额 | `nil` | -| `pd.resources.requests.cpu` | 每个 PD Pod 的 CPU 资源请求 | `nil` | -| `pd.resources.requests.memory` | 每个 PD Pod 的内存资源请求 | `nil` | -| `pd.resources.requests.storage` | 每个 PD Pod 的存储容量请求 | `1Gi` | -| `pd.affinity` | `pd.affinity` 定义 PD 的调度规则和偏好，详细请参考：[affinity-and-anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#affinity-and-anti-affinity) | `{}` | -| `pd.nodeSelector` | `pd.nodeSelector` 确保 PD Pods 只调度到以该键值对作为标签的节点，详情参考：[nodeselector](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#nodeselector) | `{}` | -| `pd.tolerations` | `pd.tolerations` 应用于 PD Pods，允许 PD Pods 调度到含有指定 taints 的节点上，详情参考：[taint-and-toleration](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration) | `{}` | -| `pd.annotations` | 为 PD Pods 添加特定的 `annotations` | `{}` | -| `tikv.config` | 配置文件格式的 TiKV 的配置，请参考 [`tikv/etc/config-template.toml`](https://github.com/tikv/tikv/blob/master/etc/config-template.toml) 查看默认 TiKV 配置文件（选择对应 TiKV 版本的 tag），可以参考 [TiKV 配置文件描述](https://pingcap.com/docs-cn/v3.0/reference/configuration/tikv-server/configuration-file/)查看配置参数的具体介绍（请选择对应的文档版本），这里只需要**按照配置文件中的格式修改配置**

以下两个配置项需要显式配置：

`[storage.block-cache]`
  `shared = true`
  `capacity = "1GB"`
推荐设置：`capacity` 设置为 `tikv.resources.limits.memory` 的 50%

`[readpool.coprocessor]`
  `high-concurrency = 8`
  `normal-concurrency = 8`
  `low-concurrency = 8`
推荐设置：设置为 `tikv.resources.limits.cpu` 的 80%| TiDB Operator 版本 <= v1.0.0-beta.3，默认值为：
`nil`
TiDB Operator 版本 > v1.0.0-beta.3，默认值为：
`log-level = "info"`
配置示例：
  `config:` \|
    `log-level = "info"` | -| `tikv.replicas` | TiKV 的 Pod 数 | `3` | -| `tikv.image` | TiKV 的镜像 | `pingcap/tikv:v3.0.0-rc.1` | -| `tikv.imagePullPolicy` | TiKV 镜像的拉取策略 | `IfNotPresent` | -| `tikv.logLevel` | TiKV 的日志级别
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`log-level = "info"` | `info` | -| `tikv.storageClassName` | TiKV 使用的 storageClass，storageClassName 指代一种由 Kubernetes 集群提供的存储类型，不同的类可能映射到服务质量级别、备份策略或集群管理员确定的任意策略。详细参考：[storage-classes](https://kubernetes.io/docs/concepts/storage/storage-classes) | `local-storage` | -| `tikv.syncLog` | syncLog 指是否启用 raft 日志同步功能，启用该功能能保证在断电时数据不丢失
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[raftstore]`
`sync-log = true` | `true` | -| `tikv.grpcConcurrency` | 配置 gRPC server 线程池大小
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[server]`
`grpc-concurrency = 4` | `4` | -| `tikv.resources.limits.cpu` | 每个 TiKV Pod 的 CPU 资源限额 | `nil` | -| `tikv.resources.limits.memory` | 每个 TiKV Pod 的内存资源限额 | `nil` | -| `tikv.resources.limits.storage` | 每个 TiKV Pod 的存储容量限额 | `nil` | -| `tikv.resources.requests.cpu` | 每个 TiKV Pod 的 CPU 资源请求 | `nil` | -| `tikv.resources.requests.memory` | 每个 TiKV Pod 的内存资源请求 | `nil` | -| `tikv.resources.requests.storage` | 每个 TiKV Pod 的存储容量请求 | `10Gi` | -| `tikv.affinity` | `tikv.affinity` 定义 TiKV 的调度规则和偏好，详细请参考：[affinity-and-anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#affinity-and-anti-affinity) | `{}` | -| `tikv.nodeSelector` | `tikv.nodeSelector`确保 TiKV Pods 只调度到以该键值对作为标签的节点，详情参考：[nodeselector](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#nodeselector) | `{}` | -| `tikv.tolerations` | `tikv.tolerations` 应用于 TiKV Pods，允许 TiKV Pods 调度到含有指定 taints 的节点上，详情参考：[taint-and-toleration](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration) | `{}` | -| `tikv.annotations` | 为 TiKV Pods 添加特定的 `annotations` | `{}` | -| `tikv.defaultcfBlockCacheSize` | 指定 block 缓存大小，block 缓存用于缓存未压缩的 block，较大的 block 缓存设置可以加快读取速度。一般推荐设置为 `tikv.resources.limits.memory` 的 30%-50%
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[rocksdb.defaultcf]`
`block-cache-size = "1GB"`
从 TiKV v3.0.0 开始，不再需要配置 `[rocksdb.defaultcf].block-cache-size` 和 `[rocksdb.writecf].block-cache-size`，改为配置 `[storage.block-cache].capacity` | `1GB` | -| `tikv.writecfBlockCacheSize` | 指定 writecf 的 block 缓存大小，一般推荐设置为 `tikv.resources.limits.memory` 的 10%-30%
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[rocksdb.writecf]`
`block-cache-size = "256MB"`
从 TiKV v3.0.0 开始，不再需要配置 `[rocksdb.defaultcf].block-cache-size` 和 `[rocksdb.writecf].block-cache-size`，改为配置 `[storage.block-cache].capacity` | `256MB` | -| `tikv.readpoolStorageConcurrency` | TiKV 存储的高优先级/普通优先级/低优先级操作的线程池大小
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[readpool.storage]`
`high-concurrency = 4`
`normal-concurrency = 4`
`low-concurrency = 4` | `4` | -| `tikv.readpoolCoprocessorConcurrency` | 一般如果 `tikv.resources.limits.cpu` > 8，则 `tikv.readpoolCoprocessorConcurrency` 设置为`tikv.resources.limits.cpu` * 0.8
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[readpool.coprocessor]`
`high-concurrency = 8`
`normal-concurrency = 8`
`low-concurrency = 8` | `8` | -| `tikv.storageSchedulerWorkerPoolSize` | TiKV 调度程序的工作池大小，应在重写情况下增加，同时应小于总 CPU 核心
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[storage]`
`scheduler-worker-pool-size = 4` | `4` | -| `tidb.config` | 配置文件格式的 TiDB 的配置，请参考[配置文件](https://github.com/pingcap/tidb/blob/master/config/config.toml.example)查看默认 TiDB 配置文件（选择对应 TiDB 版本的 tag），可以参考 [TiDB 配置文件描述](https://pingcap.com/docs-cn/stable/reference/configuration/tidb-server/configuration-file)查看配置参数的具体介绍（请选择对应的文档版本）。这里只需要**按照配置文件中的格式修改配置**。

以下配置项需要显式配置：

`[performance]`
  `max-procs = 0`
推荐设置：`max-procs` 设置为 `tidb.resources.limits.cpu` 对应的核心数 | TiDB Operator 版本 <= v1.0.0-beta.3，默认值为：
`nil`
TiDB Operator 版本 > v1.0.0-beta.3，默认值为：
`[log]`
`level = "info"`
配置示例：
  `config:` \|
    `[log]`
    `level = "info"` | -| `tidb.replicas` | TiDB 的 Pod 数 | `2` | -| `tidb.image` | TiDB 的镜像 | `pingcap/tidb:v3.0.0-rc.1` | -| `tidb.imagePullPolicy` | TiDB 镜像的拉取策略 | `IfNotPresent` | -| `tidb.logLevel` | TiDB 的日志级别
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[log]`
`level = "info"` | `info` | -| `tidb.resources.limits.cpu` | 每个 TiDB Pod 的 CPU 资源限额 | `nil` | -| `tidb.resources.limits.memory` | 每个 TiDB Pod 的内存资源限额 | `nil` | -| `tidb.resources.requests.cpu` | 每个 TiDB Pod 的 CPU 资源请求 | `nil` | -| `tidb.resources.requests.memory` | 每个 TiDB Pod 的内存资源请求 | `nil` | -| `tidb.passwordSecretName`| 存放 TiDB 用户名及密码的 Secret 的名字，该 Secret 可以使用以下命令创建机密：`kubectl create secret generic tidb secret--from literal=root=--namespace=`，如果没有设置，则 TiDB 根密码为空 | `nil` | -| `tidb.initSql`| 在 TiDB 集群启动成功后，会执行的初始化脚本 | `nil` | -| `tidb.affinity` | `tidb.affinity` 定义 TiDB 的调度规则和偏好，详细请参考：[affinity-and-anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#affinity-and-anti-affinity) | `{}` | -| `tidb.nodeSelector` | `tidb.nodeSelector`确保 TiDB Pods 只调度到以该键值对作为标签的节点，详情参考：[nodeselector](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#nodeselector) | `{}` | -| `tidb.tolerations` | `tidb.tolerations` 应用于 TiDB Pods，允许 TiDB Pods 调度到含有指定 taints 的节点上，详情参考：[taint-and-toleration](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration) | `{}` | -| `tidb.annotations` | 为 TiDB Pods 添加特定的 `annotations` | `{}` | -| `tidb.maxFailoverCount` | TiDB 最大的故障转移数量，假设为 3 即最多支持同时 3 个 TiDB 实例故障转移 | `3` | -| `tidb.service.type` | TiDB 服务对外暴露类型 | `NodePort` | -| `tidb.service.externalTrafficPolicy` | 表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。有两个可用选项：`Cluster`（默认）和 `Local`。`Cluster` 隐藏了客户端源 IP，可能导致流量需要二次跳转到另一个节点，但具有良好的整体负载分布。`Local` 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务流量的第二次跳转，但存在潜在的不均衡流量传播风险。详细参考：[外部负载均衡器](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) | `nil` | -| `tidb.service.loadBalancerIP` | 指定 tidb 负载均衡 IP，某些云提供程序允许您指定loadBalancerIP。在这些情况下，将使用用户指定的loadBalancerIP创建负载平衡器。如果未指定loadBalancerIP字段，则将使用临时IP地址设置loadBalancer。如果指定loadBalancerIP但云提供程序不支持该功能，则将忽略您设置的loadbalancerIP字段 | `nil` | -| `tidb.service.mysqlNodePort` | TiDB 服务暴露的 mysql NodePort 端口 | | -| `tidb.service.exposeStatus` | TiDB 服务是否暴露状态端口 | `true` | -| `tidb.service.statusNodePort` | 指定 TiDB 服务的状态端口暴露的 `NodePort` | | -| `tidb.separateSlowLog` | 是否以 sidecar 方式运行独立容器输出 TiDB 的 SlowLog | 如果 TiDB Operator 版本 <= v1.0.0-beta.3，默认值为 `false`
如果 TiDB Operator 版本 > v1.0.0-beta.3，默认值为 `true` | -| `tidb.slowLogTailer.image` | TiDB 的 slowLogTailer 的镜像，slowLogTailer 是一个 sidecar 类型的容器，用于输出 TiDB 的 SlowLog，该配置仅在 `tidb.separateSlowLog`=`true` 时生效 | `busybox:1.26.2` | -| `tidb.slowLogTailer.resources.limits.cpu` | 每个 TiDB Pod 的 slowLogTailer 的 CPU 资源限额 | `100m` | -| `tidb.slowLogTailer.resources.limits.memory` | 每个 TiDB Pod 的 slowLogTailer 的内存资源限额 | `50Mi` | -| `tidb.slowLogTailer.resources.requests.cpu` | 每个 TiDB Pod 的 slowLogTailer 的 CPU 资源请求 | `20m` | -| `tidb.slowLogTailer.resources.requests.memory` | 每个 TiDB Pod 的 slowLogTailer 的内存资源请求 | `5Mi` | -| `tidb.plugin.enable` | 是否启用 TiDB 插件功能 | `false` | -| `tidb.plugin.directory` | 指定 TiDB 插件所在的目录 | `/plugins` | -| `tidb.plugin.list` | 指定 TiDB 加载的插件列表，plugin ID 命名规则：插件名-版本，例如：'conn_limit-1' | `[]` | -| `tidb.preparedPlanCacheEnabled` | 是否启用 TiDB 的 prepared plan 缓存
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[prepared-plan-cache]`
`enabled = false` | `false` | -| `tidb.preparedPlanCacheCapacity` | TiDB 的 prepared plan 缓存数量
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[prepared-plan-cache]`
`capacity = 100` | `100` | -| `tidb.txnLocalLatchesEnabled` | 是否启用事务内存锁，当本地事务冲突比较多时建议开启
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[txn-local-latches]`
`enabled = false` | `false` | -| `tidb.txnLocalLatchesCapacity` | 事务内存锁的容量，Hash 对应的 slot 数，会自动向上调整为 2 的指数倍。每个 slot 占 32 Bytes 内存。当写入数据的范围比较广时（如导数据），设置过小会导致变慢，性能下降。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[txn-local-latches]`
`capacity = 10240000` | `10240000` | -| `tidb.tokenLimit` | TiDB 并发执行会话的限制
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`token-limit = 1000` | `1000` | -| `tidb.memQuotaQuery` | TiDB 查询的内存限额，默认 32GB
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`mem-quota-query = 34359738368` | `34359738368` | -| `tidb.checkMb4ValueInUtf8` | 用于控制当字符集为 utf8 时是否检查 mb4 字符
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`check-mb4-value-in-utf8 = true` | `true` | -| `tidb.treatOldVersionUtf8AsUtf8mb4` | 用于升级兼容性。设置为 `true` 将把旧版本的表/列的 `utf8` 字符集视为 `utf8mb4` 字符集
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`treat-old-version-utf8-as-utf8mb4 = true` | `true` | -| `tidb.lease` | `tidb.lease`是 TiDB Schema lease 的期限，对其更改是非常危险的，除非你明确知道可能产生的结果，否则不建议更改。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`lease = "45s"` | `45s` | -| `tidb.maxProcs` | 最大可使用的 CPU 核数，0 代表机器/Pod 上的 CPU 数量
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[performance]`
`max-procs = 0` | `0` | +# Kubernetes 上的 TiDB 集群的资源配置以及容灾配置 + +本文介绍 Kubernetes 上 TiDB 集群的资源配置以及容灾配置。 ## 资源配置说明 @@ -147,7 +39,7 @@ affinity: podAffinityTerm: labelSelector: matchLabels: - app.kubernetes.io/instance: + app.kubernetes.io/instance: app.kubernetes.io/component: "pd" topologyKey: "region" namespaces: @@ -157,7 +49,7 @@ affinity: podAffinityTerm: labelSelector: matchLabels: - app.kubernetes.io/instance: + app.kubernetes.io/instance: app.kubernetes.io/component: "pd" topologyKey: "zone" namespaces: @@ -167,7 +59,7 @@ affinity: podAffinityTerm: labelSelector: matchLabels: - app.kubernetes.io/instance: + app.kubernetes.io/instance: app.kubernetes.io/component: "pd" topologyKey: "rack" namespaces: @@ -177,7 +69,7 @@ affinity: podAffinityTerm: labelSelector: matchLabels: - app.kubernetes.io/instance: + app.kubernetes.io/instance: app.kubernetes.io/component: "pd" topologyKey: "kubernetes.io/hostname" namespaces: @@ -192,11 +84,12 @@ affinity: * 为 PD 设置拓扑位置 Label 集合 + 用 Kubernetes 集群 Node 节点上描述拓扑位置的 Label 集合替换 `pd.config` 配置项中里的 `location-labels` 信息。 + > **注意：** > - > 除 `kubernetes.io/hostname` 外，目前 PD 暂不支持名字中带 `/` 的 Label。 - - 用 Kubernetes 集群 Node 节点上描述拓扑位置的 Label 集合替换 `pd.config` 配置项中里的 `location-labels` 信息。 + > * PD 版本 < v3.0.9 不支持名字中带 `/` 的 Label。 + > * 如果在 `location-labels` 中配置 `hostname`，TiDB Operator 会从 Node Label 中的 `kubernetes.io/hostname` 获取值。 * 为 TiKV 节点设置所在的 Node 节点的拓扑信息 diff --git a/zh/configure-backup.md b/zh/configure-backup.md index 0e6c5a86956..71dcb6cf5c6 100644 --- a/zh/configure-backup.md +++ b/zh/configure-backup.md @@ -1,13 +1,17 @@ --- -title: Kubernetes 上的 TiDB 集群备份配置 -summary: 介绍 Kubernetes 上 TiDB 集群备份 tidb-backup 的配置参数。 +title: tidb-backup chart 配置 +summary: 介绍 tidb-backup chart 配置。 category: reference --- -# Kubernetes 上的 TiDB 集群备份配置 +# tidb-backup chart 配置 `tidb-backup` 是一个用于 Kubernetes 上 TiDB 集群备份和恢复的 Helm Chart。本文详细介绍了 `tidb-backup` 的可配置参数。 +> **注意：** +> +> 对于 TiDBOperator v1.1 及以上版本，不再建议使用 tidb-backup chart 部署、管理 TiDB 集群备份，详细信息请参考 [TiDB Operator v1.1 重要注意事项](notes-tidb-operator-v1.1.md)。 + ## `mode` + 运行模式 diff --git a/zh/deploy-tidb-operator.md b/zh/deploy-tidb-operator.md index dc2f58b68cd..d81ad9c4102 100644 --- a/zh/deploy-tidb-operator.md +++ b/zh/deploy-tidb-operator.md @@ -18,11 +18,6 @@ TiDB Operator 部署前，请确认以下软件需求： * [RBAC](https://kubernetes.io/docs/admin/authorization/rbac) 启用（可选） * [Helm](https://helm.sh) 版本 >= v2.8.2 && < v3.0.0 -> **注意：** -> -> - 尽管 TiDB Operator 可以使用网络卷持久化 TiDB 数据，TiDB 数据自身会存多副本，再走额外的网络卷性能会受到很大影响。强烈建议搭建[本地卷](https://kubernetes.io/docs/concepts/storage/volumes/#local)以提高性能。 -> - 跨多可用区的网络卷需要 Kubernetes v1.12 或者更高版本。在 `tidb-backup` chart 配置中，建议使用网络卷存储备份数据。 - ## 部署 Kubernetes 集群 TiDB Operator 运行在 Kubernetes 集群，你可以使用 [Getting started 页面](https://kubernetes.io/docs/setup/)列出的任何一种方法搭建一套 Kubernetes 集群。只要保证 Kubernetes 版本大于等于 v1.12。如果你使用 AWS、GKE 或者本机，下面是快速上手教程： @@ -31,37 +26,9 @@ TiDB Operator 运行在 Kubernetes 集群，你可以使用 [Getting started 页 * [Google GKE 教程](deploy-tidb-from-kubernetes-gke.md) * [AWS EKS 教程](deploy-on-aws-eks.md) -如果你要使用不同环境，必须在 Kubernetes 集群中安装 DNS 插件。可以根据[官方文档](https://kubernetes.io/docs/tasks/access-application-cluster/configure-dns-cluster/)搭建 DNS 插件。 - -TiDB Operator 使用[持久化卷](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)持久化存储 TiDB 集群数据（包括数据库，监控和备份数据），所以 Kubernetes 集群必须提供至少一种持久化卷。为提高性能，建议使用本地 SSD 盘作为持久化卷。可以根据[这一步](#配置本地持久化卷)自动配置本地持久化卷。 - -Kubernetes 集群建议启用 [RBAC](https://kubernetes.io/docs/admin/authorization/rbac)。否则，需要在 `tidb-operator` 和 `tidb-cluster` chart 的 `values.yaml` 中设置 `rbac.create` 为 `false`。 - -TiDB 默认会使用很多文件描述符，工作节点和上面的 Docker 进程的 `ulimit` 必须设置大于等于 `1048576`： - -* 设置工作节点的 `ulimit` 值，详情可以参考[如何设置 ulimit](https://access.redhat.com/solutions/61334) - - {{< copyable "shell-regular" >}} - - ```shell - sudo vim /etc/security/limits.conf - ``` - - 设置 root 账号的 `soft` 和 `hard` 的 `nofile` 大于等于 `1048576` - -* 设置 Docker 服务的 `ulimit` - - {{< copyable "shell-regular" >}} - - ```shell - sudo vim /etc/systemd/system/docker.service - ``` - - 设置 `LimitNOFILE` 大于等于 `1048576`。 +TiDB Operator 使用[持久化卷](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)持久化存储 TiDB 集群数据（包括数据库，监控和备份数据），所以 Kubernetes 集群必须提供至少一种持久化卷。为提高性能，建议使用本地 SSD 盘作为持久化卷。可以根据[这一步](#配置本地持久化卷)配置本地持久化卷。 -> **注意：** -> -> `LimitNOFILE` 需要显式设置为 `1048576` 或者更大，而不是默认的 `infinity`，由于 `systemd` 的 [bug](https://github.com/systemd/systemd/commit/6385cb31ef443be3e0d6da5ea62a267a49174688#diff-108b33cf1bd0765d116dd401376ca356L1186)，`infinity` 在 `systemd` 某些版本中指的是 `65536`。 +Kubernetes 集群建议启用 [RBAC](https://kubernetes.io/docs/admin/authorization/rbac)。 ## 安装 Helm diff --git a/zh/destroy-a-tidb-cluster.md b/zh/destroy-a-tidb-cluster.md index 6e0f70d74c8..f271d76ddb9 100644 --- a/zh/destroy-a-tidb-cluster.md +++ b/zh/destroy-a-tidb-cluster.md @@ -8,15 +8,37 @@ category: how-to 本文描述了如何销毁 Kubernetes 集群上的 TiDB 集群。 -要销毁 TiDB 集群，执行以下命令： +## 销毁使用 TidbCluster 管理的 TiDB 集群 + +要销毁使用 TidbCluster 管理的 TiDB 集群，执行以下命令： + +{{< copyable "shell-regular" >}} + +```shell +kubectl delete tc -n +``` + +如果集群中通过 `TidbMonitor` 部署了监控，要删除监控组件，，执行以下命令： {{< copyable "shell-regular" >}} ```shell -helm delete --purge +kubectl delete tidbmonitor -n ``` -上述命令只是删除运行的 Pod，数据仍然会保留。如果你不再需要那些数据，可以通过下面命令清除数据： +## 销毁使用 Helm 管理的 TiDB 集群 + +要销毁使用 Helm 管理的 TiDB 集群，执行以下命令： + +{{< copyable "shell-regular" >}} + +```shell +helm delete --purge +``` + +## 清除数据 + +上述销毁集群的命令只是删除运行的 Pod，数据仍然会保留。如果你不再需要那些数据，可以通过下面命令清除数据： > **警告：** > @@ -25,11 +47,11 @@ helm delete --purge {{< copyable "shell-regular" >}} ```shell -kubectl delete pvc -n -l app.kubernetes.io/instance=,app.kubernetes.io/managed-by=tidb-operator +kubectl delete pvc -n -l app.kubernetes.io/instance=,app.kubernetes.io/managed-by=tidb-operator ``` {{< copyable "shell-regular" >}} ```shell -kubectl get pv -l app.kubernetes.io/namespace=,app.kubernetes.io/managed-by=tidb-operator,app.kubernetes.io/instance= -o name | xargs -I {} kubectl patch {} -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}' +kubectl get pv -l app.kubernetes.io/namespace=,app.kubernetes.io/managed-by=tidb-operator,app.kubernetes.io/instance= -o name | xargs -I {} kubectl patch {} -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}' ``` diff --git a/zh/monitor-a-tidb-cluster.md b/zh/monitor-a-tidb-cluster.md index 67e1c8bde65..eaf90f90cdf 100644 --- a/zh/monitor-a-tidb-cluster.md +++ b/zh/monitor-a-tidb-cluster.md @@ -10,9 +10,9 @@ category: how-to ## TiDB 集群的监控 -TiDB 通过 Prometheus 和 Grafana 监控 TiDB 集群。在通过 TiDB Operator 创建新的 TiDB 集群时，对于每个 TiDB 集群，会同时创建、配置一套独立的监控系统，与 TiDB 集群运行在同一 Namespace，包括 Prometheus 和 Grafana 两个组件。 +TiDB 通过 Prometheus 和 Grafana 监控 TiDB 集群。在通过 TiDB Operator 创建新的 TiDB 集群时，可以参考[通过 TidbMonitor 监控 TiDB 集群](monitor-using-tidbmonitor.md)，对于每个 TiDB 集群，创建、配置一套独立的监控系统，与 TiDB 集群运行在同一 Namespace，包括 Prometheus 和 Grafana 两个组件。 -监控数据默认没有持久化，如果由于某些原因监控容器重启，已有的监控数据会丢失。可以在 `values.yaml` 中设置 `monitor.persistent` 为 `true` 来持久化监控数据。开启此选项时应将 `storageClass` 设置为一个当前集群中已有的存储，并且此存储应当支持将数据持久化，否则仍然会存在数据丢失的风险。 +可以在 `TidbMonitor` 中设置 `spec.persistent` 为 `true` 来持久化监控数据。开启此选项时应将 `spec.storageClassName` 设置为一个当前集群中已有的存储，并且此存储应当支持将数据持久化，否则会存在数据丢失的风险。 在 [TiDB 集群监控](https://pingcap.com/docs-cn/stable/how-to/monitor/monitor-a-cluster/)中有一些监控系统配置的细节可供参考。 @@ -23,7 +23,7 @@ TiDB 通过 Prometheus 和 Grafana 监控 TiDB 集群。在通过 TiDB Operator {{< copyable "shell-regular" >}} ```shell -kubectl port-forward -n svc/-grafana 3000:3000 &>/tmp/portforward-grafana.log & +kubectl port-forward -n svc/-grafana 3000:3000 &>/tmp/portforward-grafana.log & ``` 然后在浏览器中打开 [http://localhost:3000](http://localhost:3000)，默认用户名和密码都为 `admin`。 @@ -39,7 +39,7 @@ Grafana 服务默认通过 `NodePort` 暴露，如果 Kubernetes 集群支持负 {{< copyable "shell-regular" >}} ```shell -kubectl port-forward -n svc/-prometheus 9090:9090 &>/tmp/portforward-prometheus.log & +kubectl port-forward -n svc/-prometheus 9090:9090 &>/tmp/portforward-prometheus.log & ``` 然后在浏览器中打开 [http://localhost:9090](http://localhost:9090)，或通过客户端工具访问此地址即可。 diff --git a/zh/notes-tidb-operator-v1.1.md b/zh/notes-tidb-operator-v1.1.md index 05f475d5e27..090742bc937 100644 --- a/zh/notes-tidb-operator-v1.1.md +++ b/zh/notes-tidb-operator-v1.1.md @@ -94,6 +94,28 @@ spec > * BackupSchedule CR mydumper 方式目前只支持备份到 s3、gcs，BR 方式只支持备份到 s3，如果升级之前的定时全量备份是备份到本地 PVC，则升级后不能切换到 CR 方式管理。 > * 如果切换到 CR 方式管理，请删除原有定时全量备份的 Cronjob，以防止重复备份。 +### Ad-hoc 全量备份 + +升级到 TiDB Operator v1.1 之后，可以通过 Backup CR 进行全量备份： + +- 如果 TiDB 集群版本 < v3.1，可以参考 [mydumper Ad-hoc 全量备份](backup-to-s3.md#Ad-hoc-全量备份) +- 如果 TiDB 集群版本 >= v3.1，可以参考 [BR Ad-hoc 全量备份](backup-to-aws-s3-using-br.md#Ad-hoc-全量备份) + +> **注意：** +> +> * Backup CR mydumper 方式目前只支持备份到 s3、gcs，BR 方式只支持备份到 s3，如果升级之前的 Ad-hoc 全量备份是备份到本地 PVC，则不能切换到 CR 方式管理。 + +### 备份恢复 + +升级到 TiDB Operator v1.1 之后，可以通过 Restore CR 进行备份恢复： + +- 如果 TiDB 集群版本 < v3.1，可以参考 [loader 备份恢复](restore-from-s3.md) +- 如果 TiDB 集群版本 >= v3.1，可以参考 [BR 备份恢复](restore-from-aws-s3-using-br.md) + +> **注意：** +> +> * Restore CR loader 方式目前只支持从 s3、gcs 获取备份数据进行恢复，BR 方式只支持从 s3 获取备份数据进行恢复，如果需要从本地 PVC 获取备份数据进行恢复，则不能切换到 CR 方式管理。 + ### Drainer - 如果在升级到 TiDB Operator v1.1 之前，没有部署 Drainer，现在需要新部署，可以参考 [Drainer 部署](maintain-tidb-binlog.md#部署多个-drainer)。 diff --git a/zh/prerequisites.md b/zh/prerequisites.md index 3779f52d8b5..0d6feaddef8 100644 --- a/zh/prerequisites.md +++ b/zh/prerequisites.md @@ -111,6 +111,34 @@ cat /proc/irq//smp_affinity_list 上文所描述的是处理多队列网卡和多核心的场景。单队列网卡和多核的场景则有不同的处理方式。在这种场景下，可以使用 [RPS/RFS](https://www.kernel.org/doc/Documentation/networking/scaling.txt) 在软件层面模拟实现硬件的网卡多队列功能 (RSS)。此时不能使用方法一所述的 irqbalance 服务，而是通过使用方法二提供的脚本来设置 RPS。RFS 的配置可以参考[这里](https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/7/html/performance_tuning_guide/sect-red_hat_enterprise_linux-performance_tuning_guide-networking-configuration_tools#sect-Red_Hat_Enterprise_Linux-Performance_Tuning_Guide-Configuration_tools-Configuring_Receive_Flow_Steering_RFS)。 +## ulimit 设置 + +TiDB 集群默认会使用很多文件描述符，工作节点和上面的 Docker 进程的 `ulimit` 必须设置大于等于 `1048576`： + +* 设置工作节点的 `ulimit` 值，详情可以参考[如何设置 ulimit](https://access.redhat.com/solutions/61334) + + {{< copyable "shell-regular" >}} + + ```shell + sudo vim /etc/security/limits.conf + ``` + + 设置 root 账号的 `soft` 和 `hard` 的 `nofile` 大于等于 `1048576` + +* 设置 Docker 服务的 `ulimit` + + {{< copyable "shell-regular" >}} + + ```shell + sudo vim /etc/systemd/system/docker.service + ``` + + 设置 `LimitNOFILE` 大于等于 `1048576`。 + +> **注意：** +> +> `LimitNOFILE` 需要显式设置为 `1048576` 或者更大，而不是默认的 `infinity`，由于 `systemd` 的 [bug](https://github.com/systemd/systemd/commit/6385cb31ef443be3e0d6da5ea62a267a49174688#diff-108b33cf1bd0765d116dd401376ca356L1186)，`infinity` 在 `systemd` 某些版本中指的是 `65536`。 + ## 硬件和部署要求 与使用 binary 方式部署 TiDB 集群一致，要求选用 Intel x86-64 架构的 64 位通用硬件服务器，使用万兆网卡。关于 TiDB 集群在物理机上的具体部署需求，参考 [TiDB 软件和硬件环境建议配置](https://pingcap.com/docs-cn/stable/how-to/deploy/hardware-recommendations)。 diff --git a/zh/tidb-cluster-chart-config.md b/zh/tidb-cluster-chart-config.md new file mode 100644 index 00000000000..d788b8993d9 --- /dev/null +++ b/zh/tidb-cluster-chart-config.md @@ -0,0 +1,119 @@ +--- +title: tidb-cluster chart 配置 +summary: 介绍 tidb-cluster chart 配置。 +category: reference +--- + +# tidb-cluster chart 配置 + +本文介绍 tidb-cluster chart 配置。 + +> **注意：** +> +> 对于 TiDBOperator v1.1 及以上版本，不再建议使用 tidb-cluster chart 部署、管理 TiDB 集群，详细信息请参考 [TiDB Operator v1.1 重要注意事项](notes-tidb-operator-v1.1.md)。 + +## 配置参数 + +> **注意：** +> +> 下文用 `values.yaml` 指代要修改的 TiDB 集群配置文件。 + +| 参数名 | 说明 | 默认值 | +| :----- | :---- | :----- | +| `rbac.create` | 是否启用 Kubernetes 的 RBAC | `true` | +| `clusterName` | TiDB 集群名，默认不设置该变量，`tidb-cluster` 会直接用执行安装时的 `ReleaseName` 代替 | `nil` | +| `extraLabels` | 添加额外的 labels 到 `TidbCluster` 对象 (CRD) 上，参考：[labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) | `{}` | +| `schedulerName` | TiDB 集群使用的调度器 | `tidb-scheduler` | +| `timezone` | TiDB 集群默认时区 | `UTC` | +| `pvReclaimPolicy` | TiDB 集群使用的 PV (Persistent Volume)的 reclaim policy | `Retain` | +| `services[0].name` | TiDB 集群对外暴露服务的名字 | `nil` | +| `services[0].type` | TiDB 集群对外暴露服务的类型，(从 `ClusterIP`、`NodePort`、`LoadBalancer` 中选择) | `nil` | +| `discovery.image` | TiDB 集群 PD 服务发现组件的镜像，该组件用于在 PD 集群第一次启动时，为各个 PD 实例提供服务发现功能以协调启动顺序 | `pingcap/tidb-operator:v1.0.0-beta.3` | +| `discovery.imagePullPolicy` | PD 服务发现组件镜像的拉取策略 | `IfNotPresent` | +| `discovery.resources.limits.cpu` | PD 服务发现组件的 CPU 资源限额 | `250m` | +| `discovery.resources.limits.memory` | PD 服务发现组件的内存资源限额 | `150Mi` | +| `discovery.resources.requests.cpu` | PD 服务发现组件的 CPU 资源请求 | `80m` | +| `discovery.resources.requests.memory` | PD 服务发现组件的内存资源请求 | `50Mi` | +| `enableConfigMapRollout` | 是否开启 TiDB 集群自动滚动更新。如果启用，则 TiDB 集群的 ConfigMap 变更时，TiDB 集群自动更新对应组件。该配置只在 tidb-operator v1.0 及以上版本才支持 | `false` | +| `pd.config` | 配置文件格式的 PD 的配置，请参考 [`pd/conf/config.toml`](https://github.com/pingcap/pd/blob/master/conf/config.toml) 查看默认 PD 配置文件（选择对应 PD 版本的 tag），可以参考 [PD 配置文件描述](https://pingcap.com/docs-cn/stable/reference/configuration/pd-server/configuration-file)查看配置参数的具体介绍（请选择对应的文档版本），这里只需要**按照配置文件中的格式修改配置** | TiDB Operator 版本 <= v1.0.0-beta.3，默认值为：
`nil`
TiDB Operator 版本 > v1.0.0-beta.3，默认值为：
`[log]`
`level = "info"`
`[replication]`
`location-labels = ["region", "zone", "rack", "host"]`
配置示例：
  `config:` \|
    `[log]`
    `level = "info"`
    `[replication]`
    `location-labels = ["region", "zone", "rack", "host"]` | +| `pd.replicas` | PD 的 Pod 数 | `3` | +| `pd.image` | PD 镜像 | `pingcap/pd:v3.0.0-rc.1` | +| `pd.imagePullPolicy` | PD 镜像的拉取策略 | `IfNotPresent` | +| `pd.logLevel` | PD 日志级别
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `pd.config` 配置：
`[log]`
`level = "info"` | `info` | +| `pd.storageClassName` | PD 使用的 storageClass，storageClassName 指代一种由 Kubernetes 集群提供的存储类型，不同的类可能映射到服务质量级别、备份策略或集群管理员确定的任意策略。详细参考：[storage-classes](https://kubernetes.io/docs/concepts/storage/storage-classes) | `local-storage` | +| `pd.maxStoreDownTime` | `pd.maxStoreDownTime` 指一个 store 节点断开连接多长时间后状态会被标记为 `down`，当状态变为 `down` 后，store 节点开始迁移数据到其它 store 节点
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `pd.config` 配置：
`[schedule]`
`max-store-down-time = "30m"` | `30m` | +| `pd.maxReplicas` | `pd.maxReplicas` 是 TiDB 集群的数据的副本数
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `pd.config` 配置：
`[replication]`
`max-replicas = 3` | `3` | +| `pd.resources.limits.cpu` | 每个 PD Pod 的 CPU 资源限额 | `nil` | +| `pd.resources.limits.memory` | 每个 PD Pod 的内存资源限额 | `nil` | +| `pd.resources.limits.storage` | 每个 PD Pod 的存储容量限额 | `nil` | +| `pd.resources.requests.cpu` | 每个 PD Pod 的 CPU 资源请求 | `nil` | +| `pd.resources.requests.memory` | 每个 PD Pod 的内存资源请求 | `nil` | +| `pd.resources.requests.storage` | 每个 PD Pod 的存储容量请求 | `1Gi` | +| `pd.affinity` | `pd.affinity` 定义 PD 的调度规则和偏好，详细请参考：[affinity-and-anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#affinity-and-anti-affinity) | `{}` | +| `pd.nodeSelector` | `pd.nodeSelector` 确保 PD Pods 只调度到以该键值对作为标签的节点，详情参考：[nodeselector](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#nodeselector) | `{}` | +| `pd.tolerations` | `pd.tolerations` 应用于 PD Pods，允许 PD Pods 调度到含有指定 taints 的节点上，详情参考：[taint-and-toleration](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration) | `{}` | +| `pd.annotations` | 为 PD Pods 添加特定的 `annotations` | `{}` | +| `tikv.config` | 配置文件格式的 TiKV 的配置，请参考 [`tikv/etc/config-template.toml`](https://github.com/tikv/tikv/blob/master/etc/config-template.toml) 查看默认 TiKV 配置文件（选择对应 TiKV 版本的 tag），可以参考 [TiKV 配置文件描述](https://pingcap.com/docs-cn/v3.0/reference/configuration/tikv-server/configuration-file/)查看配置参数的具体介绍（请选择对应的文档版本），这里只需要**按照配置文件中的格式修改配置**

以下两个配置项需要显式配置：

`[storage.block-cache]`
  `shared = true`
  `capacity = "1GB"`
推荐设置：`capacity` 设置为 `tikv.resources.limits.memory` 的 50%

`[readpool.coprocessor]`
  `high-concurrency = 8`
  `normal-concurrency = 8`
  `low-concurrency = 8`
推荐设置：设置为 `tikv.resources.limits.cpu` 的 80%| TiDB Operator 版本 <= v1.0.0-beta.3，默认值为：
`nil`
TiDB Operator 版本 > v1.0.0-beta.3，默认值为：
`log-level = "info"`
配置示例：
  `config:` \|
    `log-level = "info"` | +| `tikv.replicas` | TiKV 的 Pod 数 | `3` | +| `tikv.image` | TiKV 的镜像 | `pingcap/tikv:v3.0.0-rc.1` | +| `tikv.imagePullPolicy` | TiKV 镜像的拉取策略 | `IfNotPresent` | +| `tikv.logLevel` | TiKV 的日志级别
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`log-level = "info"` | `info` | +| `tikv.storageClassName` | TiKV 使用的 storageClass，storageClassName 指代一种由 Kubernetes 集群提供的存储类型，不同的类可能映射到服务质量级别、备份策略或集群管理员确定的任意策略。详细参考：[storage-classes](https://kubernetes.io/docs/concepts/storage/storage-classes) | `local-storage` | +| `tikv.syncLog` | syncLog 指是否启用 raft 日志同步功能，启用该功能能保证在断电时数据不丢失
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[raftstore]`
`sync-log = true` | `true` | +| `tikv.grpcConcurrency` | 配置 gRPC server 线程池大小
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[server]`
`grpc-concurrency = 4` | `4` | +| `tikv.resources.limits.cpu` | 每个 TiKV Pod 的 CPU 资源限额 | `nil` | +| `tikv.resources.limits.memory` | 每个 TiKV Pod 的内存资源限额 | `nil` | +| `tikv.resources.limits.storage` | 每个 TiKV Pod 的存储容量限额 | `nil` | +| `tikv.resources.requests.cpu` | 每个 TiKV Pod 的 CPU 资源请求 | `nil` | +| `tikv.resources.requests.memory` | 每个 TiKV Pod 的内存资源请求 | `nil` | +| `tikv.resources.requests.storage` | 每个 TiKV Pod 的存储容量请求 | `10Gi` | +| `tikv.affinity` | `tikv.affinity` 定义 TiKV 的调度规则和偏好，详细请参考：[affinity-and-anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#affinity-and-anti-affinity) | `{}` | +| `tikv.nodeSelector` | `tikv.nodeSelector`确保 TiKV Pods 只调度到以该键值对作为标签的节点，详情参考：[nodeselector](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#nodeselector) | `{}` | +| `tikv.tolerations` | `tikv.tolerations` 应用于 TiKV Pods，允许 TiKV Pods 调度到含有指定 taints 的节点上，详情参考：[taint-and-toleration](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration) | `{}` | +| `tikv.annotations` | 为 TiKV Pods 添加特定的 `annotations` | `{}` | +| `tikv.defaultcfBlockCacheSize` | 指定 block 缓存大小，block 缓存用于缓存未压缩的 block，较大的 block 缓存设置可以加快读取速度。一般推荐设置为 `tikv.resources.limits.memory` 的 30%-50%
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[rocksdb.defaultcf]`
`block-cache-size = "1GB"`
从 TiKV v3.0.0 开始，不再需要配置 `[rocksdb.defaultcf].block-cache-size` 和 `[rocksdb.writecf].block-cache-size`，改为配置 `[storage.block-cache].capacity` | `1GB` | +| `tikv.writecfBlockCacheSize` | 指定 writecf 的 block 缓存大小，一般推荐设置为 `tikv.resources.limits.memory` 的 10%-30%
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[rocksdb.writecf]`
`block-cache-size = "256MB"`
从 TiKV v3.0.0 开始，不再需要配置 `[rocksdb.defaultcf].block-cache-size` 和 `[rocksdb.writecf].block-cache-size`，改为配置 `[storage.block-cache].capacity` | `256MB` | +| `tikv.readpoolStorageConcurrency` | TiKV 存储的高优先级/普通优先级/低优先级操作的线程池大小
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[readpool.storage]`
`high-concurrency = 4`
`normal-concurrency = 4`
`low-concurrency = 4` | `4` | +| `tikv.readpoolCoprocessorConcurrency` | 一般如果 `tikv.resources.limits.cpu` > 8，则 `tikv.readpoolCoprocessorConcurrency` 设置为`tikv.resources.limits.cpu` * 0.8
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[readpool.coprocessor]`
`high-concurrency = 8`
`normal-concurrency = 8`
`low-concurrency = 8` | `8` | +| `tikv.storageSchedulerWorkerPoolSize` | TiKV 调度程序的工作池大小，应在重写情况下增加，同时应小于总 CPU 核心
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[storage]`
`scheduler-worker-pool-size = 4` | `4` | +| `tidb.config` | 配置文件格式的 TiDB 的配置，请参考[配置文件](https://github.com/pingcap/tidb/blob/master/config/config.toml.example)查看默认 TiDB 配置文件（选择对应 TiDB 版本的 tag），可以参考 [TiDB 配置文件描述](https://pingcap.com/docs-cn/stable/reference/configuration/tidb-server/configuration-file)查看配置参数的具体介绍（请选择对应的文档版本）。这里只需要**按照配置文件中的格式修改配置**。

以下配置项需要显式配置：

`[performance]`
  `max-procs = 0`
推荐设置：`max-procs` 设置为 `tidb.resources.limits.cpu` 对应的核心数 | TiDB Operator 版本 <= v1.0.0-beta.3，默认值为：
`nil`
TiDB Operator 版本 > v1.0.0-beta.3，默认值为：
`[log]`
`level = "info"`
配置示例：
  `config:` \|
    `[log]`
    `level = "info"` | +| `tidb.replicas` | TiDB 的 Pod 数 | `2` | +| `tidb.image` | TiDB 的镜像 | `pingcap/tidb:v3.0.0-rc.1` | +| `tidb.imagePullPolicy` | TiDB 镜像的拉取策略 | `IfNotPresent` | +| `tidb.logLevel` | TiDB 的日志级别
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[log]`
`level = "info"` | `info` | +| `tidb.resources.limits.cpu` | 每个 TiDB Pod 的 CPU 资源限额 | `nil` | +| `tidb.resources.limits.memory` | 每个 TiDB Pod 的内存资源限额 | `nil` | +| `tidb.resources.requests.cpu` | 每个 TiDB Pod 的 CPU 资源请求 | `nil` | +| `tidb.resources.requests.memory` | 每个 TiDB Pod 的内存资源请求 | `nil` | +| `tidb.passwordSecretName`| 存放 TiDB 用户名及密码的 Secret 的名字，该 Secret 可以使用以下命令创建机密：`kubectl create secret generic tidb secret--from literal=root=--namespace=`，如果没有设置，则 TiDB 根密码为空 | `nil` | +| `tidb.initSql`| 在 TiDB 集群启动成功后，会执行的初始化脚本 | `nil` | +| `tidb.affinity` | `tidb.affinity` 定义 TiDB 的调度规则和偏好，详细请参考：[affinity-and-anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#affinity-and-anti-affinity) | `{}` | +| `tidb.nodeSelector` | `tidb.nodeSelector`确保 TiDB Pods 只调度到以该键值对作为标签的节点，详情参考：[nodeselector](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#nodeselector) | `{}` | +| `tidb.tolerations` | `tidb.tolerations` 应用于 TiDB Pods，允许 TiDB Pods 调度到含有指定 taints 的节点上，详情参考：[taint-and-toleration](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration) | `{}` | +| `tidb.annotations` | 为 TiDB Pods 添加特定的 `annotations` | `{}` | +| `tidb.maxFailoverCount` | TiDB 最大的故障转移数量，假设为 3 即最多支持同时 3 个 TiDB 实例故障转移 | `3` | +| `tidb.service.type` | TiDB 服务对外暴露类型 | `NodePort` | +| `tidb.service.externalTrafficPolicy` | 表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。有两个可用选项：`Cluster`（默认）和 `Local`。`Cluster` 隐藏了客户端源 IP，可能导致流量需要二次跳转到另一个节点，但具有良好的整体负载分布。`Local` 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务流量的第二次跳转，但存在潜在的不均衡流量传播风险。详细参考：[外部负载均衡器](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) | `nil` | +| `tidb.service.loadBalancerIP` | 指定 tidb 负载均衡 IP，某些云提供程序允许您指定loadBalancerIP。在这些情况下，将使用用户指定的loadBalancerIP创建负载平衡器。如果未指定loadBalancerIP字段，则将使用临时IP地址设置loadBalancer。如果指定loadBalancerIP但云提供程序不支持该功能，则将忽略您设置的loadbalancerIP字段 | `nil` | +| `tidb.service.mysqlNodePort` | TiDB 服务暴露的 mysql NodePort 端口 | | +| `tidb.service.exposeStatus` | TiDB 服务是否暴露状态端口 | `true` | +| `tidb.service.statusNodePort` | 指定 TiDB 服务的状态端口暴露的 `NodePort` | | +| `tidb.separateSlowLog` | 是否以 sidecar 方式运行独立容器输出 TiDB 的 SlowLog | 如果 TiDB Operator 版本 <= v1.0.0-beta.3，默认值为 `false`
如果 TiDB Operator 版本 > v1.0.0-beta.3，默认值为 `true` | +| `tidb.slowLogTailer.image` | TiDB 的 slowLogTailer 的镜像，slowLogTailer 是一个 sidecar 类型的容器，用于输出 TiDB 的 SlowLog，该配置仅在 `tidb.separateSlowLog`=`true` 时生效 | `busybox:1.26.2` | +| `tidb.slowLogTailer.resources.limits.cpu` | 每个 TiDB Pod 的 slowLogTailer 的 CPU 资源限额 | `100m` | +| `tidb.slowLogTailer.resources.limits.memory` | 每个 TiDB Pod 的 slowLogTailer 的内存资源限额 | `50Mi` | +| `tidb.slowLogTailer.resources.requests.cpu` | 每个 TiDB Pod 的 slowLogTailer 的 CPU 资源请求 | `20m` | +| `tidb.slowLogTailer.resources.requests.memory` | 每个 TiDB Pod 的 slowLogTailer 的内存资源请求 | `5Mi` | +| `tidb.plugin.enable` | 是否启用 TiDB 插件功能 | `false` | +| `tidb.plugin.directory` | 指定 TiDB 插件所在的目录 | `/plugins` | +| `tidb.plugin.list` | 指定 TiDB 加载的插件列表，plugin ID 命名规则：插件名-版本，例如：'conn_limit-1' | `[]` | +| `tidb.preparedPlanCacheEnabled` | 是否启用 TiDB 的 prepared plan 缓存
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[prepared-plan-cache]`
`enabled = false` | `false` | +| `tidb.preparedPlanCacheCapacity` | TiDB 的 prepared plan 缓存数量
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[prepared-plan-cache]`
`capacity = 100` | `100` | +| `tidb.txnLocalLatchesEnabled` | 是否启用事务内存锁，当本地事务冲突比较多时建议开启
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[txn-local-latches]`
`enabled = false` | `false` | +| `tidb.txnLocalLatchesCapacity` | 事务内存锁的容量，Hash 对应的 slot 数，会自动向上调整为 2 的指数倍。每个 slot 占 32 Bytes 内存。当写入数据的范围比较广时（如导数据），设置过小会导致变慢，性能下降。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[txn-local-latches]`
`capacity = 10240000` | `10240000` | +| `tidb.tokenLimit` | TiDB 并发执行会话的限制
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`token-limit = 1000` | `1000` | +| `tidb.memQuotaQuery` | TiDB 查询的内存限额，默认 32GB
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`mem-quota-query = 34359738368` | `34359738368` | +| `tidb.checkMb4ValueInUtf8` | 用于控制当字符集为 utf8 时是否检查 mb4 字符
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`check-mb4-value-in-utf8 = true` | `true` | +| `tidb.treatOldVersionUtf8AsUtf8mb4` | 用于升级兼容性。设置为 `true` 将把旧版本的表/列的 `utf8` 字符集视为 `utf8mb4` 字符集
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`treat-old-version-utf8-as-utf8mb4 = true` | `true` | +| `tidb.lease` | `tidb.lease`是 TiDB Schema lease 的期限，对其更改是非常危险的，除非你明确知道可能产生的结果，否则不建议更改。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`lease = "45s"` | `45s` | +| `tidb.maxProcs` | 最大可使用的 CPU 核数，0 代表机器/Pod 上的 CPU 数量
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[performance]`
`max-procs = 0` | `0` | From a0c1b3445fee7abe8dd034e8d810347763cfa573 Mon Sep 17 00:00:00 2001 From: DanielZhangQD Date: Tue, 24 Mar 2020 20:15:44 +0800 Subject: [PATCH 2/3] address comments --- zh/destroy-a-tidb-cluster.md | 2 +- zh/tidb-cluster-chart-config.md | 44 +++++++++++++++------------------ 2 files changed, 21 insertions(+), 25 deletions(-) diff --git a/zh/destroy-a-tidb-cluster.md b/zh/destroy-a-tidb-cluster.md index f271d76ddb9..a57fb0b0719 100644 --- a/zh/destroy-a-tidb-cluster.md +++ b/zh/destroy-a-tidb-cluster.md @@ -18,7 +18,7 @@ category: how-to kubectl delete tc -n ``` -如果集群中通过 `TidbMonitor` 部署了监控，要删除监控组件，，执行以下命令： +如果集群中通过 `TidbMonitor` 部署了监控，要删除监控组件，可以执行以下命令： {{< copyable "shell-regular" >}} diff --git a/zh/tidb-cluster-chart-config.md b/zh/tidb-cluster-chart-config.md index d788b8993d9..bab33b4f464 100644 --- a/zh/tidb-cluster-chart-config.md +++ b/zh/tidb-cluster-chart-config.md @@ -14,10 +14,6 @@ category: reference ## 配置参数 -> **注意：** -> -> 下文用 `values.yaml` 指代要修改的 TiDB 集群配置文件。 - | 参数名 | 说明 | 默认值 | | :----- | :---- | :----- | | `rbac.create` | 是否启用 Kubernetes 的 RBAC | `true` | @@ -25,24 +21,24 @@ category: reference | `extraLabels` | 添加额外的 labels 到 `TidbCluster` 对象 (CRD) 上，参考：[labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) | `{}` | | `schedulerName` | TiDB 集群使用的调度器 | `tidb-scheduler` | | `timezone` | TiDB 集群默认时区 | `UTC` | -| `pvReclaimPolicy` | TiDB 集群使用的 PV (Persistent Volume)的 reclaim policy | `Retain` | +| `pvReclaimPolicy` | TiDB 集群使用的 PV (Persistent Volume) 的 reclaim policy | `Retain` | | `services[0].name` | TiDB 集群对外暴露服务的名字 | `nil` | -| `services[0].type` | TiDB 集群对外暴露服务的类型，(从 `ClusterIP`、`NodePort`、`LoadBalancer` 中选择) | `nil` | +| `services[0].type` | TiDB 集群对外暴露服务的类型，（从 `ClusterIP`、`NodePort`、`LoadBalancer` 中选择） | `nil` | | `discovery.image` | TiDB 集群 PD 服务发现组件的镜像，该组件用于在 PD 集群第一次启动时，为各个 PD 实例提供服务发现功能以协调启动顺序 | `pingcap/tidb-operator:v1.0.0-beta.3` | | `discovery.imagePullPolicy` | PD 服务发现组件镜像的拉取策略 | `IfNotPresent` | | `discovery.resources.limits.cpu` | PD 服务发现组件的 CPU 资源限额 | `250m` | | `discovery.resources.limits.memory` | PD 服务发现组件的内存资源限额 | `150Mi` | | `discovery.resources.requests.cpu` | PD 服务发现组件的 CPU 资源请求 | `80m` | | `discovery.resources.requests.memory` | PD 服务发现组件的内存资源请求 | `50Mi` | -| `enableConfigMapRollout` | 是否开启 TiDB 集群自动滚动更新。如果启用，则 TiDB 集群的 ConfigMap 变更时，TiDB 集群自动更新对应组件。该配置只在 tidb-operator v1.0 及以上版本才支持 | `false` | +| `enableConfigMapRollout` | 是否开启 TiDB 集群自动滚动更新。如果启用，则 TiDB 集群的 ConfigMap 变更时，TiDB 集群自动更新对应组件。该配置只在 TiDB Operator v1.0 及以上版本才支持 | `false` | | `pd.config` | 配置文件格式的 PD 的配置，请参考 [`pd/conf/config.toml`](https://github.com/pingcap/pd/blob/master/conf/config.toml) 查看默认 PD 配置文件（选择对应 PD 版本的 tag），可以参考 [PD 配置文件描述](https://pingcap.com/docs-cn/stable/reference/configuration/pd-server/configuration-file)查看配置参数的具体介绍（请选择对应的文档版本），这里只需要**按照配置文件中的格式修改配置** | TiDB Operator 版本 <= v1.0.0-beta.3，默认值为：
`nil`
TiDB Operator 版本 > v1.0.0-beta.3，默认值为：
`[log]`
`level = "info"`
`[replication]`
`location-labels = ["region", "zone", "rack", "host"]`
配置示例：
  `config:` \|
    `[log]`
    `level = "info"`
    `[replication]`
    `location-labels = ["region", "zone", "rack", "host"]` | | `pd.replicas` | PD 的 Pod 数 | `3` | | `pd.image` | PD 镜像 | `pingcap/pd:v3.0.0-rc.1` | | `pd.imagePullPolicy` | PD 镜像的拉取策略 | `IfNotPresent` | -| `pd.logLevel` | PD 日志级别
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `pd.config` 配置：
`[log]`
`level = "info"` | `info` | +| `pd.logLevel` | PD 日志级别。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `pd.config` 配置：
`[log]`
`level = "info"` | `info` | | `pd.storageClassName` | PD 使用的 storageClass，storageClassName 指代一种由 Kubernetes 集群提供的存储类型，不同的类可能映射到服务质量级别、备份策略或集群管理员确定的任意策略。详细参考：[storage-classes](https://kubernetes.io/docs/concepts/storage/storage-classes) | `local-storage` | | `pd.maxStoreDownTime` | `pd.maxStoreDownTime` 指一个 store 节点断开连接多长时间后状态会被标记为 `down`，当状态变为 `down` 后，store 节点开始迁移数据到其它 store 节点
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `pd.config` 配置：
`[schedule]`
`max-store-down-time = "30m"` | `30m` | -| `pd.maxReplicas` | `pd.maxReplicas` 是 TiDB 集群的数据的副本数
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `pd.config` 配置：
`[replication]`
`max-replicas = 3` | `3` | +| `pd.maxReplicas` | `pd.maxReplicas` 是 TiDB 集群的数据的副本数。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `pd.config` 配置：
`[replication]`
`max-replicas = 3` | `3` | | `pd.resources.limits.cpu` | 每个 PD Pod 的 CPU 资源限额 | `nil` | | `pd.resources.limits.memory` | 每个 PD Pod 的内存资源限额 | `nil` | | `pd.resources.limits.storage` | 每个 PD Pod 的存储容量限额 | `nil` | @@ -53,14 +49,14 @@ category: reference | `pd.nodeSelector` | `pd.nodeSelector` 确保 PD Pods 只调度到以该键值对作为标签的节点，详情参考：[nodeselector](https://kubernetes.io/docs/concepts/configuration/assign-Pod-node/#nodeselector) | `{}` | | `pd.tolerations` | `pd.tolerations` 应用于 PD Pods，允许 PD Pods 调度到含有指定 taints 的节点上，详情参考：[taint-and-toleration](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration) | `{}` | | `pd.annotations` | 为 PD Pods 添加特定的 `annotations` | `{}` | -| `tikv.config` | 配置文件格式的 TiKV 的配置，请参考 [`tikv/etc/config-template.toml`](https://github.com/tikv/tikv/blob/master/etc/config-template.toml) 查看默认 TiKV 配置文件（选择对应 TiKV 版本的 tag），可以参考 [TiKV 配置文件描述](https://pingcap.com/docs-cn/v3.0/reference/configuration/tikv-server/configuration-file/)查看配置参数的具体介绍（请选择对应的文档版本），这里只需要**按照配置文件中的格式修改配置**

以下两个配置项需要显式配置：

`[storage.block-cache]`
  `shared = true`
  `capacity = "1GB"`
推荐设置：`capacity` 设置为 `tikv.resources.limits.memory` 的 50%

`[readpool.coprocessor]`
  `high-concurrency = 8`
  `normal-concurrency = 8`
  `low-concurrency = 8`
推荐设置：设置为 `tikv.resources.limits.cpu` 的 80%| TiDB Operator 版本 <= v1.0.0-beta.3，默认值为：
`nil`
TiDB Operator 版本 > v1.0.0-beta.3，默认值为：
`log-level = "info"`
配置示例：
  `config:` \|
    `log-level = "info"` | +| `tikv.config` | 配置文件格式的 TiKV 的配置，请参考 [`tikv/etc/config-template.toml`](https://github.com/tikv/tikv/blob/master/etc/config-template.toml) 查看默认 TiKV 配置文件（选择对应 TiKV 版本的 tag），可以参考 [TiKV 配置文件描述](https://pingcap.com/docs-cn/v3.0/reference/configuration/tikv-server/configuration-file/)查看配置参数的具体介绍（请选择对应的文档版本），这里只需要**按照配置文件中的格式修改配置**。

以下两个配置项需要显式配置：

`[storage.block-cache]`
  `shared = true`
  `capacity = "1GB"`
推荐设置：`capacity` 设置为 `tikv.resources.limits.memory` 的 50%

`[readpool.coprocessor]`
  `high-concurrency = 8`
  `normal-concurrency = 8`
  `low-concurrency = 8`
推荐设置：设置为 `tikv.resources.limits.cpu` 的 80%| TiDB Operator 版本 <= v1.0.0-beta.3，默认值为：
`nil`
TiDB Operator 版本 > v1.0.0-beta.3，默认值为：
`log-level = "info"`
配置示例：
  `config:` \|
    `log-level = "info"` | | `tikv.replicas` | TiKV 的 Pod 数 | `3` | | `tikv.image` | TiKV 的镜像 | `pingcap/tikv:v3.0.0-rc.1` | | `tikv.imagePullPolicy` | TiKV 镜像的拉取策略 | `IfNotPresent` | | `tikv.logLevel` | TiKV 的日志级别
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`log-level = "info"` | `info` | | `tikv.storageClassName` | TiKV 使用的 storageClass，storageClassName 指代一种由 Kubernetes 集群提供的存储类型，不同的类可能映射到服务质量级别、备份策略或集群管理员确定的任意策略。详细参考：[storage-classes](https://kubernetes.io/docs/concepts/storage/storage-classes) | `local-storage` | -| `tikv.syncLog` | syncLog 指是否启用 raft 日志同步功能，启用该功能能保证在断电时数据不丢失
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[raftstore]`
`sync-log = true` | `true` | -| `tikv.grpcConcurrency` | 配置 gRPC server 线程池大小
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[server]`
`grpc-concurrency = 4` | `4` | +| `tikv.syncLog` | syncLog 指是否启用 raft 日志同步功能，启用该功能能保证在断电时数据不丢失。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[raftstore]`
`sync-log = true` | `true` | +| `tikv.grpcConcurrency` | 配置 gRPC server 线程池大小。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[server]`
`grpc-concurrency = 4` | `4` | | `tikv.resources.limits.cpu` | 每个 TiKV Pod 的 CPU 资源限额 | `nil` | | `tikv.resources.limits.memory` | 每个 TiKV Pod 的内存资源限额 | `nil` | | `tikv.resources.limits.storage` | 每个 TiKV Pod 的存储容量限额 | `nil` | @@ -75,12 +71,12 @@ category: reference | `tikv.writecfBlockCacheSize` | 指定 writecf 的 block 缓存大小，一般推荐设置为 `tikv.resources.limits.memory` 的 10%-30%
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[rocksdb.writecf]`
`block-cache-size = "256MB"`
从 TiKV v3.0.0 开始，不再需要配置 `[rocksdb.defaultcf].block-cache-size` 和 `[rocksdb.writecf].block-cache-size`，改为配置 `[storage.block-cache].capacity` | `256MB` | | `tikv.readpoolStorageConcurrency` | TiKV 存储的高优先级/普通优先级/低优先级操作的线程池大小
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[readpool.storage]`
`high-concurrency = 4`
`normal-concurrency = 4`
`low-concurrency = 4` | `4` | | `tikv.readpoolCoprocessorConcurrency` | 一般如果 `tikv.resources.limits.cpu` > 8，则 `tikv.readpoolCoprocessorConcurrency` 设置为`tikv.resources.limits.cpu` * 0.8
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[readpool.coprocessor]`
`high-concurrency = 8`
`normal-concurrency = 8`
`low-concurrency = 8` | `8` | -| `tikv.storageSchedulerWorkerPoolSize` | TiKV 调度程序的工作池大小，应在重写情况下增加，同时应小于总 CPU 核心
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[storage]`
`scheduler-worker-pool-size = 4` | `4` | +| `tikv.storageSchedulerWorkerPoolSize` | TiKV 调度程序的工作池大小，应在重写情况下增加，同时应小于总 CPU 核心。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tikv.config` 配置：
`[storage]`
`scheduler-worker-pool-size = 4` | `4` | | `tidb.config` | 配置文件格式的 TiDB 的配置，请参考[配置文件](https://github.com/pingcap/tidb/blob/master/config/config.toml.example)查看默认 TiDB 配置文件（选择对应 TiDB 版本的 tag），可以参考 [TiDB 配置文件描述](https://pingcap.com/docs-cn/stable/reference/configuration/tidb-server/configuration-file)查看配置参数的具体介绍（请选择对应的文档版本）。这里只需要**按照配置文件中的格式修改配置**。

以下配置项需要显式配置：

`[performance]`
  `max-procs = 0`
推荐设置：`max-procs` 设置为 `tidb.resources.limits.cpu` 对应的核心数 | TiDB Operator 版本 <= v1.0.0-beta.3，默认值为：
`nil`
TiDB Operator 版本 > v1.0.0-beta.3，默认值为：
`[log]`
`level = "info"`
配置示例：
  `config:` \|
    `[log]`
    `level = "info"` | | `tidb.replicas` | TiDB 的 Pod 数 | `2` | | `tidb.image` | TiDB 的镜像 | `pingcap/tidb:v3.0.0-rc.1` | | `tidb.imagePullPolicy` | TiDB 镜像的拉取策略 | `IfNotPresent` | -| `tidb.logLevel` | TiDB 的日志级别
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[log]`
`level = "info"` | `info` | +| `tidb.logLevel` | TiDB 的日志级别。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[log]`
`level = "info"` | `info` | | `tidb.resources.limits.cpu` | 每个 TiDB Pod 的 CPU 资源限额 | `nil` | | `tidb.resources.limits.memory` | 每个 TiDB Pod 的内存资源限额 | `nil` | | `tidb.resources.requests.cpu` | 每个 TiDB Pod 的 CPU 资源请求 | `nil` | @@ -94,11 +90,11 @@ category: reference | `tidb.maxFailoverCount` | TiDB 最大的故障转移数量，假设为 3 即最多支持同时 3 个 TiDB 实例故障转移 | `3` | | `tidb.service.type` | TiDB 服务对外暴露类型 | `NodePort` | | `tidb.service.externalTrafficPolicy` | 表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。有两个可用选项：`Cluster`（默认）和 `Local`。`Cluster` 隐藏了客户端源 IP，可能导致流量需要二次跳转到另一个节点，但具有良好的整体负载分布。`Local` 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务流量的第二次跳转，但存在潜在的不均衡流量传播风险。详细参考：[外部负载均衡器](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) | `nil` | -| `tidb.service.loadBalancerIP` | 指定 tidb 负载均衡 IP，某些云提供程序允许您指定loadBalancerIP。在这些情况下，将使用用户指定的loadBalancerIP创建负载平衡器。如果未指定loadBalancerIP字段，则将使用临时IP地址设置loadBalancer。如果指定loadBalancerIP但云提供程序不支持该功能，则将忽略您设置的loadbalancerIP字段 | `nil` | +| `tidb.service.loadBalancerIP` | 指定 TIDB 负载均衡 IP，某些云提供程序允许您指定 loadBalancerIP。在这些情况下，将使用用户指定的 loadBalancerIP 创建负载平衡器。如果未指定 loadBalancerIP 字段，则将使用临时 IP 地址设置 loadBalancer。如果指定 loadBalancerIP 但云提供程序不支持该功能，则将忽略您设置的 loadbalancerIP 字段 | `nil` | | `tidb.service.mysqlNodePort` | TiDB 服务暴露的 mysql NodePort 端口 | | | `tidb.service.exposeStatus` | TiDB 服务是否暴露状态端口 | `true` | | `tidb.service.statusNodePort` | 指定 TiDB 服务的状态端口暴露的 `NodePort` | | -| `tidb.separateSlowLog` | 是否以 sidecar 方式运行独立容器输出 TiDB 的 SlowLog | 如果 TiDB Operator 版本 <= v1.0.0-beta.3，默认值为 `false`
如果 TiDB Operator 版本 > v1.0.0-beta.3，默认值为 `true` | +| `tidb.separateSlowLog` | 是否以 sidecar 方式运行独立容器输出 TiDB 的 SlowLog | 如果 TiDB Operator 版本 <= v1.0.0-beta.3，默认值为 `false`。
如果 TiDB Operator 版本 > v1.0.0-beta.3，默认值为 `true` | | `tidb.slowLogTailer.image` | TiDB 的 slowLogTailer 的镜像，slowLogTailer 是一个 sidecar 类型的容器，用于输出 TiDB 的 SlowLog，该配置仅在 `tidb.separateSlowLog`=`true` 时生效 | `busybox:1.26.2` | | `tidb.slowLogTailer.resources.limits.cpu` | 每个 TiDB Pod 的 slowLogTailer 的 CPU 资源限额 | `100m` | | `tidb.slowLogTailer.resources.limits.memory` | 每个 TiDB Pod 的 slowLogTailer 的内存资源限额 | `50Mi` | @@ -107,13 +103,13 @@ category: reference | `tidb.plugin.enable` | 是否启用 TiDB 插件功能 | `false` | | `tidb.plugin.directory` | 指定 TiDB 插件所在的目录 | `/plugins` | | `tidb.plugin.list` | 指定 TiDB 加载的插件列表，plugin ID 命名规则：插件名-版本，例如：'conn_limit-1' | `[]` | -| `tidb.preparedPlanCacheEnabled` | 是否启用 TiDB 的 prepared plan 缓存
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[prepared-plan-cache]`
`enabled = false` | `false` | -| `tidb.preparedPlanCacheCapacity` | TiDB 的 prepared plan 缓存数量
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[prepared-plan-cache]`
`capacity = 100` | `100` | -| `tidb.txnLocalLatchesEnabled` | 是否启用事务内存锁，当本地事务冲突比较多时建议开启
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[txn-local-latches]`
`enabled = false` | `false` | -| `tidb.txnLocalLatchesCapacity` | 事务内存锁的容量，Hash 对应的 slot 数，会自动向上调整为 2 的指数倍。每个 slot 占 32 Bytes 内存。当写入数据的范围比较广时（如导数据），设置过小会导致变慢，性能下降。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[txn-local-latches]`
`capacity = 10240000` | `10240000` | -| `tidb.tokenLimit` | TiDB 并发执行会话的限制
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`token-limit = 1000` | `1000` | -| `tidb.memQuotaQuery` | TiDB 查询的内存限额，默认 32GB
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`mem-quota-query = 34359738368` | `34359738368` | -| `tidb.checkMb4ValueInUtf8` | 用于控制当字符集为 utf8 时是否检查 mb4 字符
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`check-mb4-value-in-utf8 = true` | `true` | +| `tidb.preparedPlanCacheEnabled` | 是否启用 TiDB 的 prepared plan 缓存。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[prepared-plan-cache]`
`enabled = false` | `false` | +| `tidb.preparedPlanCacheCapacity` | TiDB 的 prepared plan 缓存数量。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[prepared-plan-cache]`
`capacity = 100` | `100` | +| `tidb.txnLocalLatchesEnabled` | 是否启用事务内存锁，当本地事务冲突比较多时建议开启。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[txn-local-latches]`
`enabled = false` | `false` | +| `tidb.txnLocalLatchesCapacity` | 事务内存锁的容量，Hash 对应的 slot 数，会自动向上调整为 2 的指数倍。每个 slot 占 32 Bytes 内存。当写入数据的范围比较广时（如导数据），设置过小会导致变慢，性能下降。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[txn-local-latches]`
`capacity = 10240000` | `10240000` | +| `tidb.tokenLimit` | TiDB 并发执行会话的限制。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`token-limit = 1000` | `1000` | +| `tidb.memQuotaQuery` | TiDB 查询的内存限额，默认 32GB。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`mem-quota-query = 34359738368` | `34359738368` | +| `tidb.checkMb4ValueInUtf8` | 用于控制当字符集为 utf8 时是否检查 mb4 字符。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`check-mb4-value-in-utf8 = true` | `true` | | `tidb.treatOldVersionUtf8AsUtf8mb4` | 用于升级兼容性。设置为 `true` 将把旧版本的表/列的 `utf8` 字符集视为 `utf8mb4` 字符集
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`treat-old-version-utf8-as-utf8mb4 = true` | `true` | | `tidb.lease` | `tidb.lease`是 TiDB Schema lease 的期限，对其更改是非常危险的，除非你明确知道可能产生的结果，否则不建议更改。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`lease = "45s"` | `45s` | -| `tidb.maxProcs` | 最大可使用的 CPU 核数，0 代表机器/Pod 上的 CPU 数量
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[performance]`
`max-procs = 0` | `0` | +| `tidb.maxProcs` | 最大可使用的 CPU 核数，0 代表机器/Pod 上的 CPU 数量。
如果 TiDB Operator 版本 > v1.0.0-beta.3，请通过 `tidb.config` 配置：
`[performance]`
`max-procs = 0` | `0` | From 7f57466d74630a866e5ef296991c01bbf944e97e Mon Sep 17 00:00:00 2001 From: DanielZhangQD <36026334+DanielZhangQD@users.noreply.github.com> Date: Wed, 25 Mar 2020 09:08:10 +0800 Subject: [PATCH 3/3] Update zh/tidb-cluster-chart-config.md Co-Authored-By: Ran --- zh/tidb-cluster-chart-config.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/tidb-cluster-chart-config.md b/zh/tidb-cluster-chart-config.md index bab33b4f464..29799723b99 100644 --- a/zh/tidb-cluster-chart-config.md +++ b/zh/tidb-cluster-chart-config.md @@ -90,7 +90,7 @@ category: reference | `tidb.maxFailoverCount` | TiDB 最大的故障转移数量，假设为 3 即最多支持同时 3 个 TiDB 实例故障转移 | `3` | | `tidb.service.type` | TiDB 服务对外暴露类型 | `NodePort` | | `tidb.service.externalTrafficPolicy` | 表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。有两个可用选项：`Cluster`（默认）和 `Local`。`Cluster` 隐藏了客户端源 IP，可能导致流量需要二次跳转到另一个节点，但具有良好的整体负载分布。`Local` 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务流量的第二次跳转，但存在潜在的不均衡流量传播风险。详细参考：[外部负载均衡器](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) | `nil` | -| `tidb.service.loadBalancerIP` | 指定 TIDB 负载均衡 IP，某些云提供程序允许您指定 loadBalancerIP。在这些情况下，将使用用户指定的 loadBalancerIP 创建负载平衡器。如果未指定 loadBalancerIP 字段，则将使用临时 IP 地址设置 loadBalancer。如果指定 loadBalancerIP 但云提供程序不支持该功能，则将忽略您设置的 loadbalancerIP 字段 | `nil` | +| `tidb.service.loadBalancerIP` | 指定 TiDB 负载均衡 IP，某些云提供程序允许您指定 loadBalancerIP。在这些情况下，将使用用户指定的 loadBalancerIP 创建负载平衡器。如果未指定 loadBalancerIP 字段，则将使用临时 IP 地址设置 loadBalancer。如果指定 loadBalancerIP 但云提供程序不支持该功能，则将忽略您设置的 loadbalancerIP 字段 | `nil` | | `tidb.service.mysqlNodePort` | TiDB 服务暴露的 mysql NodePort 端口 | | | `tidb.service.exposeStatus` | TiDB 服务是否暴露状态端口 | `true` | | `tidb.service.statusNodePort` | 指定 TiDB 服务的状态端口暴露的 `NodePort` | |