TiDB监控节点扩缩容操作(是否保留历史数据)
作者: Liuhaoao 原文来源:https://tidb.net/blog/adb8242d
最近在扒官方文档的时候,发现只有扩缩容tikv/pd/tidb/tiflash/ticdc的步骤,并没有讲扩缩容Prometheus/alertmanger/grafana的操作步骤,就想到凭借自己的经验写一篇文章出来,供大家参考。由于本人学识浅薄,难免会有疏漏或错误的地方,还望各位路过的大佬不吝赐教(抱拳!)
缩容监控节点,会涉及到一个问题:是否保留监控数据。至于监控数据存存放位置、怎么保留这部分内容我先单独拿出来讲讲,以防后续在看具体操作步骤的时候会有很凌乱的感觉。
1、监控数据存放位置查看方法:
数据存放位置(因为我集群是默认部署,所以存放位置也是默认位置。如果自定义部署目录的话,数据存放位置也会变,不同的集群会有很大的区别,所以这里主要是讲方法):
1.1、查看Prometheus部署路径:
tiup cluster display test1

1.2、进入Prometheus部署目录,可以看到一个scripts目录,存放了Prometheus启动脚本:
cd /tidb-deploy/prometheus-9090/
1.3、查看脚本,可以看到其中有--storage.tsdb.path这一项,对应的目录就是监控数据存放地址:
cat run_prometheus.sh
还有一种方法也可以查看监控历史数据存放位置:
在进程中查看
ps -ef |grep prometheus|grep "storage.tsdb.path"
对应目录为监控历史数据存放位置
2、备份历史数据
2.1、进入该目录(这一步也是决定缩容监控节点后历史监控数据是否保留的操作),备份历史监控数据:
cd /tidb-data/prometheus-9090/
2.2、因历史数据量较大(默认保留30天的历史数据:--storage.tsdb.retention="30d",因为我的测试集群新搭建不久,也没什么数据量,所以数据并不是很多),所以进行压缩:
tar -zcvf prometheus-9090.tar.gz prometheus-9090/
2.3、将压缩文件拷贝到备份目录,至此完成Prometheus历史数据备份:
mv prometheus-9090.tar.gz /root/backup/
---------------------------------------------------------------割-------------------------------------------------------------
上边完成了Prometheus历史数据存放位置及备份的讲解,接下来就该进入正题:缩容监控节点操作
1、查看集群现有节点,确认需要缩容节点(自己部署用于测试的小集群,受限于硬件资源,只能单节点部署):
tiup cluster display test1
2、确认需缩容的节点信息:
172.21.0.8:9093、172.21.0.8:3000、172.21.0.8:9090三个节点
3、缩容前备份数据(参考文章开头的操作步骤)(如无需保留历史数据,则忽略这一步操作)
4、执行缩容操作:
tiup cluster scale-in test1 -N 172.21.0.8:9093,172.21.0.8:3000,172.21.0.8:9090
5、查看缩容后集群节点信息,尝试访问grafana,确认缩容符合预期:
tiup cluster display test1
可以看到集群中现在只有tidb、tikv、pd节点,监控节点已经缩容掉
尝试访问grafana:
可以看到grafana已经无法访问,至此缩容操作完成
---------------------------------------------------------------割-------------------------------------------------------------
至于扩容集群监控节点,与其他扩容操作步骤类似,区别就在于多了导入监控数据这一步
扩容集群监控节点:
1、编辑扩容文件:
vim scale.yaml
monitoring_servers: - host: 172.21.0.8 ssh_port: 22 port: 9090 deploy_dir: "/tidb-deploy/prometheus-8249" data_dir: "/tidb-data/prometheus-8249" log_dir: "/tidb-deploy/prometheus-8249/log" grafana_servers: - host: 172.21.0.8 port: 3000 deploy_dir: /tidb-deploy/grafana-3000 alertmanager_servers: - host: 172.21.0.8 ssh_port: 22 web_port: 9093 cluster_port: 9094 deploy_dir: "/tidb-deploy/alertmanager-9093" data_dir: "/tidb-data/alertmanager-9093" log_dir: "/tidb-deploy/alertmanager-9093/log"
2、执行扩容命令:
tiup cluster scale-out test1 scale.yaml
3、扩容已经完成,查看集群扩容后节点信息:
监控节点已扩容完成
尝试访问grafana:
grafana已经能够访问,但是只有集群监控节点扩容完成后的监控数据,并没有历史监控数据,这时候就需要我们文章开头备份的集群历史监控数据了
4、将备份的集群历史数据导入新部署的集群监控:
因为我们只需要集群的历史数据,所以将备份中历史数据文件导入新集群的监控数据存放目录即可
4.1、将备份历史数据解压缩:
tar -xvf prometheus-9090.tar.gz
4.2、将数据文件拷贝到新集群的监控数据存放目录
cp 01G* /tidb-data/prometheus-8249/
5、reload集群,使新集群加载导入的历史数据文件
tiup cluster reload test1
6、尝试访问grafana监控,时间选择7day,检验历史数据文件导入是否生效
历史数据导入成功,至此扩容集群监控节点及历史数据导入完成
回顾整个缩容过程,最容易出现问题的步骤就是不会考虑到保留历史数据,这一步其实是很重要重要的,比如说集群需要调整new_collations_enabled_on_first_bootstrap这个参数,只能考虑重新部署集群(version<=6.0),这时候就需要在销毁集群前将历史监控数据备份,集群重新部署完成后将历史监控数据再恢复,如果没有备份历史监控数据,就可能会有问题。就备份历史数据而言,其实操作起来很容易,只需将数据备份,导入到监控数据存放目录,然后reload即可。
以上就是缩容监控节点及历史监控数据备份恢复的操作步骤,希望对大家有所帮助。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
SerenityOS 作者新作品:跨平台 Web 浏览器 Ladybird
SerenityOS 系统的作者 Andreas Kling 近日介绍了他开源的跨平台浏览器项目: Ladybird。 Ladybird 浏览器于今年 7 月 4 日诞生,最初 Ladybird 的开发是作为 SerenityOS 系统的 “ LibWeb” 浏览器引擎调试工具,随后 Andreas 想给它构建一个简单的 GUI 。随着 Ladybird 的不断完善,两个月后,Andreas 发现自己完成了一个 Web 浏览器的大部分开发工作, Ladybird 已经算是一个跨平台的 Web 浏览器。 (Ladybird 浏览器视觉效果) Ladybird 浏览器基于 SerenityOS 的 LibWeb 和 LibJS 引擎,LibWeb 于 2019 年开始开发,当时被称为 LibHTML ,其 JavaScript 引擎 LibJS 则于 2020 年开发。 基本架构 LibWeb 和 LibJS 都是新的引擎。作者有 Qt 和 WebKit 项目的开发历史,所以从中得到了一些灵感,但所有的代码都是新的,浏览器和库用则 C++ 编写。 这是当前浏览器堆栈的粗略细分: Lad...
- 下一篇
弱隔离级别 & 事务并发问题
介绍弱隔离级别 为什么要有弱隔离级别 如果两个事务操作的是不同的数据, 即不存在数据依赖关系, 则它们可以安全地并行执行。但是当出现某个事务修改数据而另一个事务同时要读取该数据, 或者两个事务同时修改相同数据时, 就会出现并发问题。 在应用程序的开发中,我们通常会利用锁进行并发控制,确保临界区的资源不会出现多个线程同时进行读写的情况,这其实就对应了事务的最高隔离级别:可串行化。可串行化隔离意味着数据库保证事务的最终执行结果与串行 (即一次一个, 没有任何并发) 执行结果相同。 那么为什么应用程序中可以提供可串行化的隔离级别,而数据库却不能呢?其实根本原因就是应用程序对临界区大多是内存操作,而数据库要保证持久性(Durability),需要把临界区的数据持久化到磁盘,可是磁盘操作比内存操作要慢好几个数量级,一次随机访问内存、 固态硬盘 和 机械硬盘,对应的操作时间分别为几十纳秒、几十微秒和几十毫秒,这会导致持有锁的时间变长,对临界区资源的竞争将会变得异常激烈,数据库的性能则会大大降低。 所以,数据库的研究者就对事务定义了隔离级别这个概念,也就是在高性能与正确性之间做一个权衡,相当于明确地...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS7设置SWAP分区,小内存服务器的救世主
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS8编译安装MySQL8.0.19