加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程 > 正文

分布式数据库TiDB在商业银行的设计与实践

发布时间:2018-10-17 11:14:00 所属栏目:编程 来源:王旭丛 刘洋
导读:【51CTO技术沙龙】10月27日,让我们共同探索AI场景化应用实现之道 关系型数据库的发展经历了漫长岁月,这些数据库大家都非常熟悉,包括交易型、分析型的很多数据库产品和技术。TiDB 分布式数据库是新一代开源分布式 NewSQL 数据库,整个产品的结构非常清晰

TiDB集群使用开源时序数据库 Prometheus 作为监控和性能指标信息存储方案,使用 Grafana 可视化组件对监控数据进行展示。告警渠道有两个,一个是我行自主研发的一体化监控平台,一个是AlertManager。监控组件安装在监控服务器上,Prometheus产生的监控数据也存储在这里。

监控与告警总体架构如下图所示:

分布式数据库TiDB在商业银行的设计与实践

集群的TiDB/PD/TiKV组件分别向Prometheus Pushgateway推送数据,统一供 Prometheus server抓取;通过定制Grafana展示模板对Prometheus中的监控数据进行展示。

当监控的数值超过我们指定的阈值时,就会触发告警,告警信息通过AlertManager或一体化监控平台,以邮件和短信的方式通知管理员。根据故障发生的严重程度,告警被划分为3个级别:warning、critical、emergency,其中emergency级别最高,表示故障最严重。根据业务要求和信息系统安全性要求,我们分别定制了不同的告警策略。

(2)旁路监控

旁路监控是对prometheus监控的补充,一方面检测prometheus的模块是否正常,另一方面也会直接监控 TiDB 的关键服务工作状态,针对异常产生告警。下图是旁路监控示意图:

分布式数据库TiDB在商业银行的设计与实践

(3)mocha监控

监控数据库级别的运行状况。

4、备份与恢复

虽然TiDB集群的多副本策略可以避免故障发生时数据的丢失,但我们仍然需要制定完善的数据备份与恢复策略,进一步加强数据安全性。

通过全量备份工具(Mydumper)与增量备份组件(binlog),对 TiDB 集群数据库的任意时间点的状态进行保存;当需要恢复数据到某一个时间点时,首先使用全量数据恢复工具(Loader)恢复该时间点之前的最后一个全量备份,确认全量导入无误后,使用增量恢复工具(Reparo)恢复PB文件形式的binlog 增量数据到所要求的恢复时间点。

(1)备份

所有的备份组件都安装在备份服务器上,我们编写了自动备份脚本,全量备份和增量数据文件都先存储在本地,再转储至磁带上。

备份策略:

每周一次全备份,选在业务量少的夜间进行;

每天实时备份增量数据。

备份特性:

支持按表恢复数据;

TiDB 的备份数据可以恢复到 TiDB 集群或 MySQL(5.7.x)中;

TiDB 增量备份是贯穿于数据库整个生命周期的,它以PB文件的形式存在,PB文件由 Drainer 解析 binlog 生成。

备份示意图如下:

分布式数据库TiDB在商业银行的设计与实践

(2)恢复

任意一台安装有mysql实例的服务器均可用来恢复数据,也可将备份的生产数据经过脱敏处理后用于测试环境的TiDB集群。

5、日常运维方案

(1)产品升级策略

TiDB作为开源软件,其产品迭代速度快,常使用补丁式更新,一旦发现错误可马上更新,这与银行业要求的稳定性存在一定差异,且不符合监管要求的变更流程。因此,我们目前的升级策略是待其新发布的大版本稳定后再安排变更升级,对于补丁式小版本,在不影响业务的情况下,暂缓升级。

(2)集群日常巡检

除了24小时实时监控外,我行要求每日对数据库进行定时巡检。这部分我们编写了自动巡检脚本,通过邮件方式推送数据库运行状态。

(3)集群扩容缩容方案

TiDB 集群可以在不影响线上服务的情况下动态进行扩容和缩容,实现在线灵活可扩展特性。扩容缩容也分为TiDB、TiKV、PD三种情况,具体操作在PingCAP官网都有清晰地描述,这里不再赘述。

需要特别说明的是扩容PD时,需滚动升级集群,升级过程中会导致TiDB连接断开,影响业务,待升级完成即可恢复,因此,最好选择业务量少的时段进行。

6、灾备方案

除了生产主集群,我行的TiDB集群还增加了从集群的设计,目的是为了实现异地灾备。因此,我们也制定了完善的主从集群灾备切换方案。

下图是一个简单的主从集群部署示意图,主从集群通过binlog进行数据同步:

分布式数据库TiDB在商业银行的设计与实践

切换时,主从集群架构不变,仅仅是主从同步数据流改变方向。切换流程如下:

1)停业务,等待主从同步完成;

2)关闭主集群 Drainer, 停止主从同步;

3)关闭主集群,记录当前时间戳;

4)将业务数据库连接切换到从集群;

5)启动主集群;

6)从集群运行 Drainer,向主机群同步。

7、应用适配和优化

(1)检查和优化库/表/索引等内部对象

TiDB 优化器会根据统计信息来选择最优的SQL执行计划。

统计信息收集了表级别和列级别的信息,存储在stats_meta、tats_histograms、stats_buckets这三个表里。除了系统自动更新外,我们还编写了手动更新统计信息的脚本,每日定期执行ANALYZE语句来收集统计信息。

SQL执行计划由一系列的 operator 构成,TiDB提供了EXPLAIN语句,可以查看SQL语句的执行详细信息。

当数据库中的对象需要优化时,我们会综合分析统计信息、执行计划,然后给出优化方案。

(2)性能检查和判断

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读