关系型数据库的发展经历了漫长岁月,这些数据库大家都非常熟悉,包括交易型、分析型的很多数据库产品和技术。TiDB 分布式数据库是新一代开源分布式 NewSQL 数据库,整个产品的结构非常清晰,计算跟数据存储层分离,这是现代大部分分布式数据处理系统通常都会倾向和考虑采用的架构:
我们在设计TiDB分布式数据库集群时,需要考虑多方面的需求,因此,制定了以下内容,作为项目的设计目标。
模块 | 设计目标 |
---|---|
架构设计 | 1.TiDB两地三中心多活架构设计;2.规划 TiDB 软硬件配置以及基础环境;3.设计和制定 TiDB 部署运行方案;4.确定 TiDB 实例的运行参数(性能/容量/事务日志等)。 |
高可用方案 | 为实现 TiDB 高可用性,分别设计单机级、Rack级、数据中心级的高可用方案。 |
存储方案 | 设计 TiDB 集群的存储方案,包括业务数据、数据库日志、备份数据的存储等。 |
监控与告警 | 1.设计TiDB集群的监控方案,选择监控项与监控指标,制定指标阈值; 2.制定告警规则,并根据告警接口和告警方式进行定制。 |
备份与恢复 | 制定备份策略,设计备份方案,选择备份与恢复工具。 |
日常运维方案 | 1.制定 TiDB 软件及补丁的升级策略;2.制定TiDB集群日常巡检手册;3.制定TiDB集群扩容缩容方案。 |
灾备方案 | 1.规划主集群、从集群部署架构;2.制定主从集群灾备切换方案。 |
应用适配和优化 | 1.检查和优化 TiDB 库/表/索引等内部对象设计;2.应用到 TiDB 的性能检查和判断(常规性能,及热点检查)。 |
我们设计的TiDB分布式数据库集群在一期计划承载一套业务系统,该系统为我行核心支付交易系统。在采购设备之前,我们根据业务的发展规模进行了合理估算,得出了预期日交易量、数据规模、数据增长率等信息。
设备需求按照第一年的数据量和日交易量进行规划,并综合考虑了数据副本数和磁盘空间可用率,因此需要规划足够的冗余存储容量。此外,TiDB集群还需要中控机对集群进行统一管理、需要监控机进行集群监控、需要服务器进行数据备份,因此,还要考虑这些服务器的规划。
除了生产集群,我们还设计了从集群,作为异地灾备使用。生产集群和灾备集群之间通过binlog同步数据,我们选用了Kafka作为binlog同步工具,因此,需要考虑Kafka服务器的配置规划。
至此,我行的TiDB集群所需的设备均已规划完毕,详情如下:
设备角色 |
---|
生产集群TiKV |
生产集群TiDB/PD |
中控机 |
监控机 |
备份服务器 |
Kafka服务器 |
从集群服务器 |
我们的TiDB集群为两地三中心多活架构,并且设计了主从集群的灾备部署,本章节我们将详细介绍架构设计。
(1)IDC1、IDC2各配置两个机柜,均用于部署生产主集群,IDC3一个机柜用于部署生产主集群,另一个机柜用于部署灾备从集群。
(2)每个IDC配置两台万兆交换机(以主备模式部署),主集群各台机器内部通信、从集群各台机器内部通信、主从集群之间都是使用万兆网络。
(3)全局DNS下挂载三个IDC的负载均衡,各IDC种负载均衡挂载各自中心内部的TiDB服务器,以千兆网环境对外提供业务服务。
高可用是 TiDB 数据库的特性之一,TiDB/TiKV/PD 这三个组件都能容忍部分实例失效,不影响整个集群的可用性。我行的TiDB生产集群,由生产中心、同城灾备中心、异地灾备中心共同实现两地三中心多活高可用部署方案。下面,我们将从不同的维度来分析集群的高可用性。
(1)从服务器角色的角度
集群中的服务器有三个角色:TiDB、TiKV、PD,我们从这三个角色来分析集群的高可用性。
TiDB 是无状态的,以实例为单位通过前端的负载均衡设备对外提供服务。当单个TiDB实例失效时,仅仅会影响当前实例上进行的会话,应用服务出现单次请求失败的情况,应用重新连接至其他TiDB实例后即可继续获得服务,此时可以先摘除这个实例进行故障解决或者重新部署一个新的实例。
TiKV 以集群方式部署,通过 Raft 协议保持多副本情况下的数据一致性,并通过 PD 进行数据层面的负载均衡调度。单个TiKV节点失效时,会影响这个节点上存储的所有Region。对于 Region 中的Leader 结点,会中断服务,等待其他TiKV上的Region重新选举Leader,待Leader选出了可继续对外提供服务;对于Region 中的Follower节点,不会影响服务。当某个 TiKV 节点失效,并且在一段时间内(默认 30 分钟)无法恢复,PD 会将其上的数据迁移到其他的 TiKV 节点上。
PD 同样以集群方式部署,通过 Raft 协议保持数据的一致性。单个实例失效时,如果不是leader,那么服务完全不受影响;如果是leader,那么PD集群会重新选出新的leader,自动恢复服务。
(2)从宕机规模的角度
我行的TiDB数据库集群可容忍单机级、Rack级、数据中心级的故障,从而实现高可用。
单机服务器故障,分为TiDB、TiKV、PD三个角色,参考上一小节的阐述。
我们将集群所有服务器分散放置在各个Rack里,根据Raft协议大多数原则,单个Rack出现故障,不会影响集群对外提供服务。我行的架构允许集群中两个Rack同时出现故障。
任何一个数据中心发生故障,根据Raft协议大多数原则,剩余的两个数据中心仍可对外提供服务。
TiDB 集群数据库集群的数据包括业务数据、数据库日志、数据库运行状况数据,综合考虑硬盘的容量、I/O读写速率等因素后,我们选用了SAS盘+SSD盘作为服务器硬盘存储。需要注意的是,在规划容量时,要考虑数据多副本的特点,从而规划出足够的存储容量。
数据库日志分为TiDB日志、TiKV日志、PD日志,分别存储在各自的实例节点上。
数据库运行状况相关数据存放集群默认库里,也分散存储在所有TiKV节点上,通过定期执行analyze操作进行更新。
我行的TiDB数据库监控分三个模块:数据库运行状况实时监控、旁路监控、mocha监控,告警也分别由这三个模块各自触发。
(1)数据库运行状况实时监控
这部分是最多、最重要的监控内容。
TiDB集群使用开源时序数据库 Prometheus 作为监控和性能指标信息存储方案,使用 Grafana 可视化组件对监控数据进行展示。告警渠道有两个,一个是我行自主研发的一体化监控平台,一个是AlertManager。监控组件安装在监控服务器上,Prometheus产生的监控数据也存储在这里。
监控与告警总体架构如下图所示:
虽然TiDB集群的多副本策略可以避免故障发生时数据的丢失,但我们仍然需要制定完善的数据备份与恢复策略,进一步加强数据安全性。
通过全量备份工具(Mydumper)与增量备份组件(binlog),对 TiDB 集群数据库的任意时间点的状态进行保存;当需要恢复数据到某一个时间点时,首先使用全量数据恢复工具(Loader)恢复该时间点之前的最后一个全量备份,确认全量导入无误后,使用增量恢复工具(Reparo)恢复PB文件形式的binlog 增量数据到所要求的恢复时间点。
(1)备份
所有的备份组件都安装在备份服务器上,我们编写了自动备份脚本,全量备份和增量数据文件都先存储在本地,再转储至磁带上
备份策略:
每周一次全备份,选在业务量少的夜间进行;
每天实时备份增量数据。
备份特性:
支持按表恢复数据;
TiDB 的备份数据可以恢复到 TiDB 集群或 MySQL(5.7.x)中;
TiDB 增量备份是贯穿于数据库整个生命周期的,它以PB文件的形式存在,PB文件由 Drainer 解析 binlog 生成。
备份示意图如下:
(1)产品升级策略
TiDB作为开源软件,其产品迭代速度快,常使用补丁式更新,一旦发现错误可马上更新,这与银行业要求的稳定性存在一定差异,且不符合监管要求的变更流程。因此,我们目前的升级策略是待其新发布的大版本稳定后再安排变更升级,对于补丁式小版本,在不影响业务的情况下,暂缓升级。
(2)集群日常巡检
除了24小时实时监控外,我行要求每日对数据库进行定时巡检。这部分我们编写了自动巡检脚本,通过邮件方式推送数据库运行状态。
(3)集群扩容缩容方案
TiDB 集群可以在不影响线上服务的情况下动态进行扩容和缩容,实现在线灵活可扩展特性。扩容缩容也分为TiDB、TiKV、PD三种情况,具体操作在PingCAP官网都有清晰地描述,这里不再赘述。
需要特别说明的是扩容PD时,需滚动升级集群,升级过程中会导致TiDB连接断开,影响业务,待升级完成即可恢复,因此,最好选择业务量少的时段进行。
除了生产主集群,我行的TiDB集群还增加了从集群的设计,目的是为了实现异地灾备。因此,我们也制定了完善的主从集群灾备切换方案。
下图是一个简单的主从集群部署示意图,主从集群通过binlog进行数据同步:
(1)检查和优化库/表/索引等内部对象
TiDB 优化器会根据统计信息来选择最优的SQL执行计划。
统计信息收集了表级别和列级别的信息,存储在stats_meta、tats_histograms、stats_buckets这三个表里。除了系统自动更新外,我们还编写了手动更新统计信息的脚本,每日定期执行ANALYZE语句来收集统计信息。
SQL执行计划由一系列的 operator 构成,TiDB提供了EXPLAIN语句,可以查看SQL语句的执行详细信息。
当数据库中的对象需要优化时,我们会综合分析统计信息、执行计划,然后给出优化方案。
(2)性能检查和判断
应用连接 TiDB 数据库后,需要着重检查几个指标:QPS、TPS、响应时间、业务库大小、业务表增长率、数据库连接会话数、热点盘等。目前我们会通过监控、巡检、日志三方面综合进行指标分析,从而判断数据库的性能。
综上即为我行分布式数据库TiDB两地三中心多活架构的方案设计与具体实践,并且结合涵盖了日常运维管理的各个方面,包括监控告警、集群调优、备份恢复、灾备切换、扩容缩容等。今后我行会尝试将更多的业务场景迁移到分布式数据库上,以探索更多的实践领域。同时也希望将我行的实践经验分享给大家,互相学习、共同进步,欢迎各位提出宝贵建议!
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞17
添加新评论7 条评论
2020-12-09 16:46
2019-11-11 15:40
2019-10-07 10:21
wanglaye: @study123 做了功能测试、性能测试。功能测试大部分在poc阶段都做过了,上线后补充了运维比较关注的功能测试;性能测试使用压测脚本。
2019-10-07 10:20
2018-09-28 16:05
loopwa291: @gaolyang 确实挺厉害
gaolyang: @michael1983 就是生产环境
2018-09-26 19:32
2018-09-26 18:27