MySQL依靠轻量级的复制功能立足于互联网行业的数据库市场,同时依靠binlog可二次开发的能力,也为大数据场景发挥其特有的作用。你对MySQL主从复制了解多少?在当今云市场的猛烈轰击下,作为开发的你是否还需要关心这些底层组件呢?下面我们来了解下MySQL复制的基础架构和原理吧。
一. MySQL复制架构
1.1 binlog文件
事务提交时会生成对应的binlog事件,记录内容依赖于日志格式设置,statement格式会记录原始的SQL语句,row格式会记录所变更行的内容;每个会话拥有独立的binlog cache,单个事务的binlog事件不能拆分保存到不同的binlog文件(如有大事务,像大数据推数,load data等)会产生超过max_binlog_size的文件,同时也会引起从库延迟,需要规避。
binlog写到日志文件后,在主从环境下,主库的dump 线程会将日志发送给从库。
binlog 日志格式支持:
1.2 复制架构
主库为每个从库分配一个dump thread,从库有IO thread和SQL thread,IO线程从主库拉取和接收事件,写入到从库的relay log文件,SQL从relay log读取事件进行应用。
架构如图:
主库上binlog是否在事务提交时写入到磁盘,由参考sync_binlog参数控制:
从库上IO线程拉取binlog的位置点由参数master_info_repository=TABLE控制,SQL线程应用relay log的位置点由参数relay_log_info_repository=TABLE控制,都建议设置为TABLE,提高性能的同时,也能避免写入文件造成的记录位置点跟应用事件位置不一致的问题。
二. MySQL复制的缺陷
基于上述的复制架构来看,如果主库事务量大,或者有大事务操作,从库单线程的SQL线程应用事件会造成从库延迟,同时如果主库在这时出现挂掉问题,将会造成主从数据不一致等问题。
如果因异常操作删除了数据或库表等,怎么做到快速进行数据恢复?同时如何将分库分表等多实例场景的数据聚合到一个实例,实现统计等需求呢?
基于以上的一些问题,从5.5开始进行大量的优化和改造:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。