UDB高可用数据库内核深度优化
【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》
UDB是UCloud提供的云数据库,支持实例级别的高可用。UCloud数据库团队在数据库原生复制的多个方面进行了深度优化,提升UDB高可用数据库的功能和性能。
一、UDB高可用数据库架构
UDB高可用数据库产品以虚拟IP、HAProxy、单节点UDB数据库搭建双节点高可用架构:
- 双节点的UDB数据库保证数据库数据的全量冗余,同时保证数据库的可用性;
- HAProxy在同一时间只连接一个UDB节点,避免多点写入带来的数据冲突问题;
- 双节点HAProxy保证Proxy的可用性;
- 虚拟IP在HAProxy发生宕机时通过IP漂移的方式对HAProxy进行切换,用户不需要再次修改IP。
在上述架构中,从节点UDB的数据是否完整、是否与主库保证数据一致性是整个高可用架构的关键,所以用于数据传输的半同步复制起着至关重要的作用。针对原生的半同步复制,UDB数据库作了内核层面的深度优化。
二、UDB数据库深度优化
UDB数据库产品是以开源数据库MySQL Community Server 5.7.16为基线版本,围绕高可用架构做内核深度优化。
复制流程,如上图所示,主要经过如下几个步骤:
- MySQL Server执行SQL成功后,记录binlog;
- Dump线程读取binlog后,发送到从机IO线程;
- IO线程将接收到的binlog记录到relay log中,同时记录接收进度到master.info中;
- SQL读取relay log中的日志内容进行复现,同时记录复制日志的进度到relay-log.info中。
我们在原生复制的基础上做了内核的深度优化,针对上述流程中的部分步骤,在功能和性能上做了改进,使得 UDB高可用数据库产品更加稳定。
2.1 Relay log文件记录的优化
2.1.1 存在的问题
在MySQL中,binlog是以event为基本单位进行记录,以MySQL 5.7 ROW格式(开启GTID)的binlog为例,一个DML(insert)会以5个event的格式记录到binlog中(其他操作均以一个或者多个event组成,不再一一罗列),分别为:
- GTID_EVENT:记录当前事务的GTID
- QUERY_EVENT:事务开始
- TABLE_MAP_EVENT:操作对应的表
- WRITE_ROW_EVENT:插入记录
- XID_EVENT:提交事务
全部event组成一个完整的事务,完整的事务才会被SQL线程正确复现到从库上。当前IO线程接收binlog时,是以event为单位进行接收,即接收到一个event,记录到relay log中后再继续接收下一个。这种做法是低效的,也没有充分利用到MySQL本身的文件缓存。
2.1.2 优化方案
优化IO线程记录relay log的方式,将以event为单位记录,修改为以事务为单位进行记录。合并IO线程小的IO操作,提高IO性能。
将单个的event写操作合并为多个event统一写操作,将小的IO操作合并成较大的IO操作,提高IO性能。
2.2 Master.info文件记录的优化
2.2.1 存在的问题
Master.info文件在搭建复制时,记录主库IP、PORT等连接主库的相关信息,在复制过程中,记录IO线程从主库接收到的binlog的文件名和位置,文件和位置会在每次记录relay log成功后更新。
在基于GTID搭建复制后,master.info中记录的binlog文件和位置不再作为复制的依据,所以master.info中记录的binlog的文件和位置不再是有效的数据,也就没有必要每次进行更新。
2.2.2 优化方案
在IO线程记录relay log成功后,更新master.info文件之前,添加判断。如果开启了GTID并且使用GTID作为复制的依据(auto_position=1),那么不再更新master.info中binlog的文件和位置。
其它的master.info操作仍然保留,如change master、shutdown等操作。
2.3 Relay log锁的优化
2.3.1 存在的问题
在IO线程和SQL线程复制进度相似的情况下,在操作relay log时,会使用同一块文件缓存,在读写文件缓存时,需要加锁来保证操作的正确性。而IO线程和SQL线程需要频繁地读写这块公共内存,就需要对同一把锁频繁的竞争,从而导致性能下降。
2.3.2 优化方案
将IO线程和SQL线程对relay log的操作拆分开来,不再使用同一块文件缓存。虽然这样做会导致SQL线程增加一次读IO操作。但是消除了对锁的竞争,大大地提高了IO线程和SQL线程整体的性能。
三、总结
优化后的复制流程图如下:
数据库原生复制流程中包括记录binlog、记录relay log、记录master.info、relay-log.info等,针对上述流程中的部分步骤以及其他未列出的优化,在功能和性能上进行改进,UDB高可用数据库在功能和性能上均得到了明显的提升,UDB高可用数据库可以提供更加可靠、高效的服务。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
腾讯云+未来峰会北京开幕,腾讯云助力政企实现真正上云
【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》 今日,腾讯“云+未来”峰会于北京正式召开。本次峰会是在今年6月深圳站成功举办的基础之上,腾讯云围绕数字经济时代的云端探索与各界进行的又一次深入交流。大会议程包含面向政府和企业的主峰会以及面对开发者分设的专题论坛,主要涉及云业务进展、腾讯云在助推政企数字化转型方面的核心优势以及***行业解决方案等内容。 中共北京市海淀区委常委、区政府党组副书记、常务副区长孟景伟、深圳市公安局指挥部副指挥长林长平、云南省投资控股集团总裁助理温培斌、高能网***能源官周滢垭、东鹏集团副总裁林木港、富力环贸港副总经理周欣等政府机关、快消、能源、智能出行、房地产领域众多高管,以及IEEE标准协会中国战略合作负责人王亮迪、德勤大中华区云服务业务总裁刘俊龙等行业领军人物悉数到场;腾讯公司副总裁、腾讯云总裁邱跃鹏、腾讯研究院副院长兼***经济学家孟昭莉等高层领导及专家出席,腾讯内部包括微信、腾讯地图等核心业务生态圈的多名资深研究员齐聚一堂,共同研讨数字化转型浪潮中云计算、大数据、人工智能等前沿技术的行业实践。 回溯6月腾讯“云+未来”峰会深圳站,...
- 下一篇
无服务器计算或将给Google Cloud Platform带来毁灭?
【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》 【51CTO.com快译】长久以来生存在AWS与微软Azure阴影之下的谷歌,赫然发现自己又迎来了新一波生存威胁——源头正是无服务器计算的崛起。尽管Google Cloud Platform(简称GCP)的营收水平远无法与AWS或者Azure相匹敌,但凭借着在AI与容器基础设施(Kubernetes)领域的优势,谷歌依然在云市场上占据着可靠的地位。 然而,这一切很可能随着无服务器技术的发展而土崩瓦解。 事实上,谷歌公司在无服务器计算领域远远落后于竞争对手。尽管在不断推出新功能,但GCP的创新速度根本不能同AWS或Azure相提并论。简言之,除非谷歌能够快速建立起无服务器体系,否则将会很快失去过去一年中辛苦积累起的“家底”。 多年以来,AWS已经在IaaS市场上建立起统治地位。微软虽然进度相对落后,但却凭借着自身传统业务与CIO间的紧密关联而成为一位严肃的市场竞争参与者。这意味着谷歌方面被迫屈服第三位: 根据Gartner的统计,GCP“主要吸引到云原生企业以及那些希望‘如谷歌般运营’的客户。”遗憾的是,大多数企业根...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7设置SWAP分区,小内存服务器的救世主
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Red5直播服务器,属于Java语言的直播服务器