Zer0e's Blog

【架构之路7】tidb集群搭建

编程 架构 运维 从0.5开始的运维架构之路
字数统计: 1.8k阅读时长: 7 min
2024/07/22 Share

前言

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

上家公司没有使用分库分表，而是直接采用TiDB社区版来替代。目前使用上没什么大的问题。这里我就来搭建一个。

TiDB的架构说明如下：

  • TiDB Server：SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 TiProxy、LVS、HAProxy、ProxySQL 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。
  • PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。
  • 存储节点
    • TiKV Server：负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
    • TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

这里我们采用在k8s集群上搭建TiDB.文档在这

正文

安装TiDB Operator

TiDB Operator 是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。

TiDB Operator安装共两步，分别为：

  1. 安装 TiDB Operator CRDs
  2. 安装 TiDB Operator

TiDB Operator 包含许多实现 TiDB 集群不同组件的自定义资源类型 (CRD)。简单来说就是扩展了k8s的yaml配置。

1
kubectl create -f https://raw.githubusercontent.com/pingcap/tidb-operator/v1.6.0/manifests/crd.yaml

使用helm安装TiDB Operator。

1
2
3
helm repo add pingcap https://charts.pingcap.org/
kubectl create namespace tidb-admin
helm install --namespace tidb-admin tidb-operator pingcap/tidb-operator --version v1.6.0

等待tidb-controller-manager启动完成即可。这里提一下和网上教程不一样的是， tidb-scheduler在1.19以上的k8s集群上不是必须的，所以它不会自动部署tidb-scheduler。

部署集群和监控

部署集群

先创建命名空间

1
kubectl create namespace tidb-cluster

这里我们需要的是生产可用的集群，因此不能使用basic-example里面的yaml。即https://raw.githubusercontent.com/pingcap/tidb-operator/v1.6.0/examples/basic/tidb-cluster.yaml

我们使用advanced的tidb-cluster。https://raw.githubusercontent.com/pingcap/tidb-operator/blob/v1.6.0/examples/advanced/tidb-cluster.yaml

先把yaml下载下来删除一下无用注释，再改造一下。包括增加pv挂载，还有一些额外参数。

搭了快两小时，终于成功了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
apiVersion: pingcap.com/v1alpha1
kind: TidbCluster
metadata:
  name: advanced-tidb
  namespace: tidb-cluster

spec:

  version: "v8.1.0"

  timezone: UTC


  configUpdateStrategy: RollingUpdate

  
  helper:
    image: alpine:3.16.0
  
  pvReclaimPolicy: Retain

  
  enableDynamicConfiguration: true

  
  pd:
    baseImage: pingcap/pd
    config: |
      client-urls = "http://0.0.0.0:2379"
      peer-urls = "http://0.0.0.0:2380"
      data-dir = "/pd/data"
      [log.file]
        filename = "/pd/log/pd.log"
      [dashboard]
        internal-proxy = true

    
    replicas: 3

    maxFailoverCount: 0

    requests:
    #   cpu: 1000m
    #   memory: 1Gi
      storage: 10Gi
    # limits:
    #   cpu: 2000m
    #   memory: 2Gi

   
    mountClusterClientSecret: true

    
    storageClassName: "csi-rbd-sc"

    
    storageVolumes:
      - name: data
        storageSize: 2Gi
        mountPath: /pd/data
      - name: log
        storageSize: 2Gi
        mountPath: /pd/log

  tidb:

    baseImage: pingcap/tidb

   
    config: |
      path = "/tidb/data"
      [performance]
        tcp-keep-alive = true
      [log.file]
        filename = "/tidb/log/tidb.log"


    replicas: 3

    maxFailoverCount: 0

    service:
      type: LoadBalancer
      externalTrafficPolicy: Local
   
  

    storageClassName: "csi-rbd-sc"


    storageVolumes:
      - name: data
        storageSize: 1Gi
        mountPath: /tidb/data
      - name: log
        storageSize: 1Gi
        mountPath: /tidb/log

  tikv:
    baseImage: pingcap/tikv

    config: |
      log-level = "info"
      [rocksdb]
        wal-dir = "/data/tikv/wal"
      [titan]
        dirname = "/data/titan/data"

    replicas: 3

    
    maxFailoverCount: 0

    
    requests:
    #   cpu: 1000m
    #   memory: 1Gi
      storage: 100Gi
    # limits:
    #   cpu: 2000m
    #   memory: 2Gi
    #   # settings `storage` here will add `--capacity` arg to tikv-server
    #   storage: 10Gi

   
    mountClusterClientSecret: true

    storageClassName: "csi-rbd-sc"

    storageVolumes:
      - name: wal
        storageSize: "2Gi"
        mountPath: "/data/tikv/wal"
      - name: titan
        storageSize: "2Gi"
        mountPath: "/data/titan/data"

1
kubectl -n tidb-cluster apply -f tidb-cluster.yaml

部署dashboard，pd中内置了dashboard，并且配置了internal-proxy = true，因此只需要把指定端口映射出来即可.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: v1
kind: Service
metadata:
  name: access-dashboard
  namespace: tidb-cluster
spec:
  ports:
  - name: dashboard
    port: 10262
  type: LoadBalancer
  selector:
    app.kubernetes.io/component: discovery
    app.kubernetes.io/instance: advanced-tidb
    app.kubernetes.io/name: tidb-cluster

注意app.kubernetes.io/instance为上一步所搭建集群的名称，即metadata.name

然后部署监控，光有dashboard但是没有prometheus和Grafana也不行

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: pingcap.com/v1alpha1
kind: TidbMonitor
metadata:
  name: monitor
spec:
  clusters:
    - name: advanced-tidb
  persistent: true
  storageClassName: "csi-rbd-sc"
  storage: 5G
  prometheus:
    baseImage: prom/prometheus
    version: v2.27.1
    service:
      type: LoadBalancer
  grafana:
    baseImage: grafana/grafana
    version: 7.5.11
    service:
      type: LoadBalancer
  initializer:
    baseImage: pingcap/tidb-monitor-initializer
    version: v8.1.0
  reloader:
    baseImage: pingcap/tidb-monitor-reloader
    version: v1.0.1
  prometheusReloader:
    baseImage: quay.io/prometheus-operator/prometheus-config-reloader
    version: v0.49.0
  imagePullPolicy: IfNotPresent

获取dashboard的地址

1
kubectl get svc -n tidb-cluster |grep dashboard

接下来就是登录tidb，修改root密码。这里便不再赘述。

总结

至此我们就搭建了一个初步生产可用的tidb集群，后期如果需要扩容的话可以扩展副本数即可，还是比较简单的。

当然也还有许多配置我们没有用到，这些就得根据文档去增加config了。

最后我们清理下环境，不得不说在自己电脑上搭建tidb集群还是比较消耗性能的，搭建过程中先后扩容了节点的CPU和内存。

1
kubectl delete namespace tidb-cluster

原文作者：Zer0e

原文链接：https://re0.top/2024/07/22/devops7/

发表日期：July 22nd 2024, 9:30:00 pm

更新日期：July 23rd 2024, 1:06:42 pm

版权声明：本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可

CATALOG
  1. 1. 前言
  2. 2. 正文
    1. 2.1. 安装TiDB Operator
    2. 2.2. 部署集群和监控
  3. 3. 总结
Total : 110
2024
2022
2021
2020
2019
2018
随笔 编程 随想 Python 架构 设计模式 Java Spring 算法 Android 数据库 web 自动化测试 linux CTF misc Mysql 分布式 运维 从0.5开始的运维架构之路 面经