写点什么

TiDB 之 rawkv 升级之路 v5.0.4-->v6.1.0

  • 2022 年 7 月 22 日
  • 本文字数:3387 字

    阅读完需:约 11 分钟

作者: 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: amd64
monitored: 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: linux
tikv_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: linux
monitoring_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 tidb@xx.xx.xx.xx:~/.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 语句,也不会有全表扫描之类的。


发布于: 6 小时前阅读数: 16
用户头像

TiDB 社区官网:https://tidb.net/ 2021.12.15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
TiDB之rawkv升级之路v5.0.4-->v6.1.0_迁移_TiDB 社区干货传送门_InfoQ写作社区