11月15日,我参与了2019年Gdevops全球敏捷运维峰会的年度收官盛会(广州站),收获颇多。
会议的主要内容包括了云架构,数据库,智慧运维等方向。其中我印象比较深刻的主要有腾讯云数据库的《云数据库研发和运维的挑战与实践》,中国电信甜橙金融的《分布式数据库及数据中间件能力验证与实践》,以及爱可生的《金融行业MySQL高可用实践》。下面列出腾讯云数据库遇到的问题及挑战。
一. 腾讯云数据库的《云数据库研发和运维的挑战与实践》
丁奇在这个主题中,首先分析了一个数据库系统应具有的基本要求:可靠性,可用性,安全性,性能,成本,易用性。然后针对云数据库在研发和运维过程中,云DBA的日常纠结,提出了对应的解决方案。
1. 例行变更
例行变更是指在对云数据库进行版本升级等变更操作中,存在客户不理解,影响不可控,时间不一致等问题。主要原因是在变更中,这种版本升级操作后,需要重启数据库,会造成客户的数据库连接中断。如果客户的应用程序没有对数据库连接进行重连,会对业务过程造成影响。
因此,应用程序对数据库连接进行重连的操作,应该由云数据库提供方来完成,解决方案为:让客户应用程序连接到Proxy上,在版本升级等例行变更操作后,由Proxy进行自动重连,这样子就屏蔽了变更操作,使这种变化对于客户来说是无感知的。
2. 业务容量扩容
对于业务容量扩容的问题,在云数据库中存在的问题是:
<1> 对于客户的数据没有预估,客户数据量可能很大,也可能很少。对于大数据量的用户,其扩容成本大,扩容时需要复制大量数据到新的机器,时间代价和成本代价大。
<2> 没有通知。客户在扩容前并不是提前通知,而是在某个时间点突然通知云数据库提供方,进行扩容。
因此,针对以上问题,需要一种快速有效的扩容方案。这里,腾讯云数据库的思路是:因为数据库每增加一个从库时,如果是传统方式,而且客户数据量很大时,需要很久的时间才能完成扩容。原因是数据的复制,那么,如果不复制数据的话,那么扩容时间就可以极大缩短。
如上图所示的架构,主库都从库都直接连同一份数据,需要扩容的时候,只需要新增上面的从库进程即可,数据并不会复制多一份。这样子就解决了扩容时间长,代价大的问题。
3. SQL审计
在SQL审计的过程中,由于不同客户的SQL规范不同,而且一般项目上线都不通知,导致SQL审计的难度加大。在这个场景中,腾讯云数据库提出的解决方案是:通过审计日志来解决。数据库定期将SQL日志记录采集到日志存储系统中。并由另一个日志分析服务进行日志分析,最终得出诊断报告,发送给用户。这种就避免了人工的介入,提高了审计效率。
4. 问题排查
最后是问题排查。这个场景的主要特点是:
<1> 无现场。客户在发送问题后,往往不是马上发现,而是需要一段反应时间。此时没有保存现场信息,就难以追溯。
<2> 难复现。某些特殊情况,很难复现问题场景。
针对上述特点,腾讯云数据库给出的解决方案是:及时保存现场。通过定期的健康状态打分,如果某个时间点,打分达到了某个阈值,就保存现场,并进行自动诊断,最后给出一份检测报告。在客户提出问题时,将检测报告交给客户即可。
另外,因为保存了现场,所以可以在测试环境进行客户问题重现。
二. 个人总结
听完一天的峰会后,我的感悟如下:
1. 一个学识丰富,且善于表达的人,即使PPT内容简洁,讲完也能使人醍醐灌顶;而某些PPT架构师,虽然PPT内容很多,但是由于肚子的笔墨不够,讲出来就十分生硬。
2. 知识要学以致用,如果没有具体的使用场景中,很容易纸上谈兵。
3. 关于数据库的感悟:
<1> 数据库是企业的命脉,数据安全,数据高可用,数据库性能都是需要关心的问题;
<2> 数据库问题,绝大部分问题都是慢SQL问题。谁都能写SQL,但不是谁都能写好SQL;
<3> 保持对数据库更新动态的关注。未来可能是分布式数据库的天下,也可能是图数据库的天下;
三. 参考资料
全球敏捷运维峰会官网:https://gdevops.com/
《丁奇-云数据库研发和运维的挑战与实践》