Kubernetes 上的 TiDB 集群配置

本文介绍 Kubernetes 上 TiDB 集群的配置参数、资源配置,以及容灾配置。

配置参数

TiDB Operator 使用 Helm 部署和管理 TiDB 集群。通过 Helm 获取的配置文件默认提供了基本的配置,通过这个基本配置,可以快速启动一个 TiDB 集群。但是如果用户需要特殊配置或是用于生产环境,则需要根据以下配置参数列表手动配置对应的配置项。

注意:

下文用 values.yaml 指代要修改的 TiDB 集群配置文件。

参数名说明默认值
rbac.create是否启用 Kubernetes 的 RBACtrue
clusterNameTiDB 集群名,默认不设置该变量,tidb-cluster 会直接用执行安装时的 ReleaseName 代替nil
extraLabels添加额外的 labels 到 TidbCluster 对象 (CRD) 上,参考:labels{}
schedulerNameTiDB 集群使用的调度器tidb-scheduler
timezoneTiDB 集群默认时区UTC
pvReclaimPolicyTiDB 集群使用的 PV (Persistent Volume)的 reclaim policyRetain
services[0].nameTiDB 集群对外暴露服务的名字nil
services[0].typeTiDB 集群对外暴露服务的类型,(从 ClusterIPNodePortLoadBalancer 中选择)nil
discovery.imageTiDB 集群 PD 服务发现组件的镜像,该组件用于在 PD 集群第一次启动时,为各个 PD 实例提供服务发现功能以协调启动顺序pingcap/tidb-operator:v1.0.0-beta.3
discovery.imagePullPolicyPD 服务发现组件镜像的拉取策略IfNotPresent
discovery.resources.limits.cpuPD 服务发现组件的 CPU 资源限额250m
discovery.resources.limits.memoryPD 服务发现组件的内存资源限额150Mi
discovery.resources.requests.cpuPD 服务发现组件的 CPU 资源请求80m
discovery.resources.requests.memoryPD 服务发现组件的内存资源请求50Mi
enableConfigMapRollout是否开启 TiDB 集群自动滚动更新。如果启用,则 TiDB 集群的 ConfigMap 变更时,TiDB 集群自动更新对应组件。该配置只在 tidb-operator v1.0 及以上版本才支持false
pd.config配置文件格式的 PD 的配置,请参考 pd/conf/config.toml 查看默认 PD 配置文件(选择对应 PD 版本的 tag),可以参考 PD 配置文件描述查看配置参数的具体介绍(请选择对应的文档版本),这里只需要按照配置文件中的格式修改配置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.replicasPD 的 Pod 数3
pd.imagePD 镜像pingcap/pd:v3.0.0-rc.1
pd.imagePullPolicyPD 镜像的拉取策略IfNotPresent
pd.logLevelPD 日志级别
如果 TiDB Operator 版本 > v1.0.0-beta.3,请通过 pd.config 配置:
[log]
level = "info"
info
pd.storageClassNamePD 使用的 storageClass,storageClassName 指代一种由 Kubernetes 集群提供的存储类型,不同的类可能映射到服务质量级别、备份策略或集群管理员确定的任意策略。详细参考:storage-classeslocal-storage
pd.maxStoreDownTimepd.maxStoreDownTime 指一个 store 节点断开连接多长时间后状态会被标记为 down,当状态变为 down 后,store 节点开始迁移数据到其它 store 节点
如果 TiDB Operator 版本 > v1.0.0-beta.3,请通过 pd.config 配置:
[schedule]
max-store-down-time = "30m"
30m
pd.maxReplicaspd.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.affinitypd.affinity 定义 PD 的调度规则和偏好,详细请参考:affinity-and-anti-affinity{}
pd.nodeSelectorpd.nodeSelector 确保 PD Pods 只调度到以该键值对作为标签的节点,详情参考:nodeselector{}
pd.tolerationspd.tolerations 应用于 PD Pods,允许 PD Pods 调度到含有指定 taints 的节点上,详情参考:taint-and-toleration{}
pd.annotations为 PD Pods 添加特定的 annotations{}
tikv.config配置文件格式的 TiKV 的配置,请参考 tikv/etc/config-template.toml 查看默认 TiKV 配置文件(选择对应 TiKV 版本的 tag),可以参考 TiKV 配置文件描述查看配置参数的具体介绍(请选择对应的文档版本),这里只需要按照配置文件中的格式修改配置

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

[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.replicasTiKV 的 Pod 数3
tikv.imageTiKV 的镜像pingcap/tikv:v3.0.0-rc.1
tikv.imagePullPolicyTiKV 镜像的拉取策略IfNotPresent
tikv.logLevelTiKV 的日志级别
如果 TiDB Operator 版本 > v1.0.0-beta.3,请通过 tikv.config 配置:
log-level = "info"
info
tikv.storageClassNameTiKV 使用的 storageClass,storageClassName 指代一种由 Kubernetes 集群提供的存储类型,不同的类可能映射到服务质量级别、备份策略或集群管理员确定的任意策略。详细参考:storage-classeslocal-storage
tikv.syncLogsyncLog 指是否启用 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.affinitytikv.affinity 定义 TiKV 的调度规则和偏好,详细请参考:affinity-and-anti-affinity{}
tikv.nodeSelectortikv.nodeSelector确保 TiKV Pods 只调度到以该键值对作为标签的节点,详情参考:nodeselector{}
tikv.tolerationstikv.tolerations 应用于 TiKV Pods,允许 TiKV Pods 调度到含有指定 taints 的节点上,详情参考: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.readpoolStorageConcurrencyTiKV 存储的高优先级/普通优先级/低优先级操作的线程池大小
如果 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.storageSchedulerWorkerPoolSizeTiKV 调度程序的工作池大小,应在重写情况下增加,同时应小于总 CPU 核心
如果 TiDB Operator 版本 > v1.0.0-beta.3,请通过 tikv.config 配置:
[storage]
scheduler-worker-pool-size = 4
4
tidb.config配置文件格式的 TiDB 的配置,请参考配置文件查看默认 TiDB 配置文件(选择对应 TiDB 版本的 tag),可以参考 TiDB 配置文件描述查看配置参数的具体介绍(请选择对应的文档版本)。这里只需要按照配置文件中的格式修改配置

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

[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.replicasTiDB 的 Pod 数2
tidb.imageTiDB 的镜像pingcap/tidb:v3.0.0-rc.1
tidb.imagePullPolicyTiDB 镜像的拉取策略IfNotPresent
tidb.logLevelTiDB 的日志级别
如果 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=<root password>--namespace=<namespace>,如果没有设置,则 TiDB 根密码为空nil
tidb.initSql在 TiDB 集群启动成功后,会执行的初始化脚本nil
tidb.affinitytidb.affinity 定义 TiDB 的调度规则和偏好,详细请参考:affinity-and-anti-affinity{}
tidb.nodeSelectortidb.nodeSelector确保 TiDB Pods 只调度到以该键值对作为标签的节点,详情参考:nodeselector{}
tidb.tolerationstidb.tolerations 应用于 TiDB Pods,允许 TiDB Pods 调度到含有指定 taints 的节点上,详情参考:taint-and-toleration{}
tidb.annotations为 TiDB Pods 添加特定的 annotations{}
tidb.maxFailoverCountTiDB 最大的故障转移数量,假设为 3 即最多支持同时 3 个 TiDB 实例故障转移3
tidb.service.typeTiDB 服务对外暴露类型NodePort
tidb.service.externalTrafficPolicy表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。有两个可用选项:Cluster(默认)和 LocalCluster 隐藏了客户端源 IP,可能导致流量需要二次跳转到另一个节点,但具有良好的整体负载分布。Local 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务流量的第二次跳转,但存在潜在的不均衡流量传播风险。详细参考:外部负载均衡器nil
tidb.service.loadBalancerIP指定 tidb 负载均衡 IP,某些云提供程序允许您指定loadBalancerIP。在这些情况下,将使用用户指定的loadBalancerIP创建负载平衡器。如果未指定loadBalancerIP字段,则将使用临时IP地址设置loadBalancer。如果指定loadBalancerIP但云提供程序不支持该功能,则将忽略您设置的loadbalancerIP字段nil
tidb.service.mysqlNodePortTiDB 服务暴露的 mysql NodePort 端口
tidb.service.exposeStatusTiDB 服务是否暴露状态端口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.imageTiDB 的 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.preparedPlanCacheCapacityTiDB 的 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.tokenLimitTiDB 并发执行会话的限制
如果 TiDB Operator 版本 > v1.0.0-beta.3,请通过 tidb.config 配置:
token-limit = 1000
1000
tidb.memQuotaQueryTiDB 查询的内存限额,默认 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.leasetidb.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 集群各个组件配置资源,其中 PD、TiKV、TiDB 是 TiDB 集群的核心服务组件,在生产环境下它们的资源配置还需要按组件要求指定,具体参考:资源配置推荐

为了保证 TiDB 集群的组件在 Kubernetes 中合理的调度和稳定的运行,建议为其设置 Guaranteed 级别的 QoS,通过在配置资源时让 limits 等于 requests 来实现, 具体参考:配置 QoS

如果使用 NUMA 架构的 CPU,为了获得更好的性能,需要在节点上开启 Static 的 CPU 管理策略。为了 TiDB 集群组件能独占相应的 CPU 资源,除了为其设置上述 Guaranteed 级别的 QoS 外,还需要保证 CPU 的配额必须是大于或等于 1 的整数。具体参考: CPU 管理策略

容灾配置说明

TiDB 是分布式数据库,它的容灾需要做到在任一个物理拓扑节点发生故障时,不仅服务不受影响,还要保证数据也是完整和可用。下面分别具体说明这两种容灾的配置。

TiDB 服务的容灾

TiDB 服务容灾本质上基于 Kubernetes 的调度功能来实现的,为了优化调度,TiDB Operator 提供了自定义的调度器,该调度器通过指定的调度算法能在 host 层面,保证 TiDB 服务的容灾,而且目前 TiDB Cluster 使用该调度器作为默认调度器,设置项是上述列表中的 schedulerName 配置项。

其它层面的容灾(例如 rack,zone,region)是通过 Affinity 的 PodAntiAffinity 来保证,通过 PodAntiAffinity 能尽量避免同一组件的不同实例部署到同一个物理拓扑节点上,从而达到容灾的目的,Affinity 的使用参考:Affinity & AntiAffinity

下面是一个典型的容灾设置例子:

affinity:
 podAntiAffinity:
   preferredDuringSchedulingIgnoredDuringExecution:
   # this term works when the nodes have the label named region
   - weight: 10
     podAffinityTerm:
       labelSelector:
         matchLabels:
           app.kubernetes.io/instance: <release name>
           app.kubernetes.io/component: "pd"
       topologyKey: "region"
       namespaces:
       - <helm namespace>
   # this term works when the nodes have the label named zone
   - weight: 20
     podAffinityTerm:
       labelSelector:
         matchLabels:
           app.kubernetes.io/instance: <release name>
           app.kubernetes.io/component: "pd"
       topologyKey: "zone"
       namespaces:
       - <helm namespace>
   # this term works when the nodes have the label named rack
   - weight: 40
     podAffinityTerm:
       labelSelector:
         matchLabels:
           app.kubernetes.io/instance: <release name>
           app.kubernetes.io/component: "pd"
       topologyKey: "rack"
       namespaces:
       - <helm namespace>
   # this term works when the nodes have the label named kubernetes.io/hostname
   - weight: 80
     podAffinityTerm:
       labelSelector:
         matchLabels:
           app.kubernetes.io/instance: <release name>
           app.kubernetes.io/component: "pd"
       topologyKey: "kubernetes.io/hostname"
       namespaces:
       - <helm namespace>

数据的容灾

在开始数据容灾配置前,首先请阅读集群拓扑信息配置。该文档描述了 TiDB 集群数据容灾的实现原理。

在 Kubernetes 上支持数据容灾的功能,需要如下操作:

  • 为 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 节点的拓扑信息

    TiDB Operator 会自动为 TiKV 获取其所在 Node 节点的拓扑信息,并调用 PD 接口将这些信息设置为 TiKV 的 store labels 信息,这样 TiDB 集群就能基于这些信息来调度数据副本。

    如果当前 Kubernetes 集群的 Node 节点没有表示拓扑位置的 Label,或者已有的拓扑 Label 名字中带有 /,可以通过下面的命令手动给 Node 增加标签:

    kubectl label node <nodeName> region=<regionName> zone=<zoneName> rack=<rackName> kubernetes.io/hostname=<hostName>

    其中 regionzonerackkubernetes.io/hostname 只是举例,要添加的 Label 名字和数量可以任意定义,只要符合规范且和 pd.config 里的 location-labels 设置的 Labels 保持一致即可。