TiDB之rawkv升级之路v5.0.4--＆gt;v6.1.0

作者： cchouqiang 原文来源：https://tidb.net/blog/be21457b

背景

数据库集群为rawkv，没有tidb节点，版本为v5.0.4，计划升级到v6.1.0，利用现有的集群机器进行升级，没有额外的机器可用，还要考虑回退时间最短。

升级原因：

由于v5.0.4版本使用的灾备是基于learner角色来实现的，本身还处于一个集群；想用TiCDC来实现容灾功能，只能升级到v6.1.0版本。

环境准备

v6.1.0软件下载地址：

https://pingcap.com/zh/product-community

升级步骤

1）停止业务访问现有RawKV集群（记为：A集群）

观察grpc没有连接，并更新 javaclient 3.3版本（由于没有tidb节点，访问tikv时用javaclient）

2）备份现有集群（A集群）数据（使用v5.0.4版本br备份）

br backup raw --pd $PD_ADDR \    -s "local:///nas \    --ratelimit 128 \    --format hex \    --cf default

3）关闭A集群

tiup cluster stop $cluster_name

4）创建一套v5.0.4集群记为B集群

B集群的pd、tikv、监控等组件部署目录跟原集群不一致，端口保持一致，与A集群的拓扑保持一致

部署拓扑文件deploy.yaml：

global:  user: "tidb"  ssh_port: 22  deploy_dir: "/home/tidb_deploy"  data_dir: "/home/tidb_data"  os: linux  arch: amd64monitored:  node_exporter_port: 9100  blackbox_exporter_port: 9115  deploy_dir: "/home/tidb_deploy/monitored-9100"  data_dir: "/home/tidb_data/monitored-9100"  log_dir: "/home/tidb_deploy/monitored-9100/log"server_configs:  tidb: {}  tikv:    pd.enable-forwarding: true    raftdb.defaultcf.hard-pending-compaction-bytes-limit: 4096GB    raftdb.defaultcf.compression-per-level: ["lz4","lz4","lz4","lz4","lz4","lz4","lz4"]    raftdb.defaultcf.soft-pending-compaction-bytes-limit: 4096GB    raftdb.defaultcf.level0-slowdown-writes-trigger: 32    raftdb.defaultcf.level0-stop-writes-trigger: 1024    raftdb.defaultcf.max-write-buffer-number: 16    raftdb.defaultcf.write-buffer-size: 256MB    raftdb.max-background-jobs: 4    raftdb.max-sub-compactions: 2    raftdb.use-direct-io-for-flush-and-compaction: true    raftstore.apply-pool-size: 6    raftstore.hibernate-regions: false    raftstore.pd-heartbeat-tick-interval: 5s    raftstore.raft-base-tick-interval: 200ms    raftstore.raft-election-timeout-ticks: 5    raftstore.raft-heartbeat-ticks: 1    raftstore.raft-max-inflight-msgs: 2048    raftstore.raft-store-max-leader-lease: 800ms    raftstore.store-pool-size: 4    readpool.storage.use-unified-pool: true    readpool.unified.max-thread-count: 10    rocksdb.defaultcf.block-size: 8KB    rocksdb.defaultcf.hard-pending-compaction-bytes-limit: 4096GB    rocksdb.defaultcf.max-bytes-for-level-base: 1GB    rocksdb.defaultcf.soft-pending-compaction-bytes-limit: 4096GB    rocksdb.defaultcf.level0-slowdown-writes-trigger: 32    rocksdb.defaultcf.level0-stop-writes-trigger: 1024    rocksdb.defaultcf.max-write-buffer-number: 16    rocksdb.defaultcf.write-buffer-size: 1024MB    rocksdb.defaultcf.compression-per-level: ["lz4","lz4","lz4","lz4","lz4","lz4","lz4"]    rocksdb.max-background-jobs: 16    rocksdb.max-sub-compactions: 4    rocksdb.rate-bytes-per-sec: 500MB    rocksdb.use-direct-io-for-flush-and-compaction: true    server.grpc-raft-conn-num: 3    storage.enable-ttl: true    storage.ttl-check-poll-interval: 24h    log-level: info    readpool.unified.max-thread-count: 20    storage.block-cache.capacity: "100GB"    server.grpc-concurrency: 4  pd:    election-interval: 1s    lease: 1    tick-interval: 200ms    max-replicas: 5    replication.location-labels: ["zone","rack","host"]  pd_servers:- host: xx.xx.xx.xx  ssh_port: 22  name: pd_ip-6  client_port: 2379  peer_port: 2380  deploy_dir: /home/tidb_deploy/pd-2379  data_dir: /home/tidb_data/pd-2379  log_dir: /home/tidb_deploy/pd-2379/log  arch: amd64  os: linuxtikv_servers:  - host: xx.xx.xx.xx    port: 20160    status_port: 20180    deploy_dir: "/home/tidb_deploy/tikv-20160"    data_dir: "/home/tidb_data/tikv-20160"    log_dir: "/home/tidb_deploy/tikv-20160/log"    config:      server.labels:        rack: az1        host: ip-7    arch: amd64    os: linux  - host: xx.xx.xx.xx    port: 20161    status_port: 20181    deploy_dir: "/home/tidb_deploy/tikv-20160"    data_dir: "/home/tidb_data/tikv-20160"    log_dir: "/home/tidb_deploy/tikv-20160/log"    config:      server.labels:        rack: az1        host: ip-8    arch: amd64    os: linux          - host: xx.xx.xx.xx    port: 20160    status_port: 20180    deploy_dir: "/home/tidb_deploy/tikv-20160"    data_dir: "/home/tidb_data/tikv-20160"    log_dir: "/home/tidb_deploy/tikv-20160/log"    config:      server.labels:        rack: az1        host: ip-9    arch: amd64    os: linuxmonitoring_servers:  - host: xx.xx.xx.xx    ssh_port: 22    port: 9090    deploy_dir: "/home/tidb_deploy/prometheus-8249"    data_dir: "/home/tidb_data/prometheus-8249"    log_dir: "/home/tidb_deploy/prometheus-8249/log"    arch: amd64    os: linuxgrafana_servers:  - host: xx.xx.xx.xx    port: 3000    deploy_dir: /home/tidb_deploy/grafana-3000    arch: amd64    os: linux

部署集群，需要在一台无tiup的机器上安装tiup工具，因为同一个tiup是无法创建相同端口的集群

$ scp -r ~/.tiup [email protected]:~/.tiup$ tiup cluster deploy backup v5.0.4 ./deploy.yaml --user tidb -p -i /home/tidb/.ssh/id_rsa$ tiup cluster start backup

5）将A集群的备份数据恢复至B集群

br restore raw \    --pd "${PDIP}:2379" \    --storage "local:///nas" \    --ratelimit 128 \    --format hex --log-file restore.log

6）将B集群升级至RawKV 6.1

#先更新tiup组件、TiUP Cluster 组件版本tar xzvf tidb-community-server-v6.1.0-linux-amd64.tar.gzsh tidb-community-server-v6.1.0-linux-amd64/local_install.shsource /home/tidb/.bash_profiletiup update cluster#检查tiup升级后的版本tiup --versiontiup cluster --version#进行停机升级，首先需要将整个集群关停。$ tiup cluster stop backup#通过 upgrade 命令添加 --offline 参数来进行停机升级。$ tiup cluster upgrade backup v6.1.0 --offline#升级完成后集群不会自动启动，需要使用 start 命令来启动集群。$ tiup cluster start backup

7）升级完后，最好重启下集群，并检查下tikv版本

tiup ctl:v6.1.0 pd -u xx.xx.xx.xx:23791 store｜grep version

8）启动业务访问B集群

让业务进行验证

9）验证集群正常使用后清理A集群

业务验证正常后，将A集群进行清理：

tiup cluster destroy tidb-clustertiup cluster reload backuptiup cluster rename backup tidb-v6

回退方案

如果发生了其他原因，导致需要回退，则采用以下回退方案：

1. 停止现有业务访问；

<!---->

1. 销毁RawKV 6.1集群（即B集群）；

<!---->

1. 启动原RawKV 5.0.4集群（即A集群）；

若启动报错，缺少services文件时，可以使用 tiup cluster enable tidb-cluster解决。

4. 启动应用访问集群（A集群）

总结和思考

数据库升级时，首先要考虑数据安全，还要保障停机时间最短；

利用现有机器进行升级时，要保证回退时间最短，在停机窗口内完成回退；

升级前做好充足的测试；

跨大版本升级还未发现新问题，rawkv使用的接口相对简单，put、get、delete，不涉及SQL语句，也不会有全表扫描之类的。