MySQL复制策略

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/loongshawn/article/details/87991438

随着访问量的不断增加,单库压力越来越大,马上就要达到能力瓶颈,数据库的架构不得不再次进行变更,这时可以使用MySQL的replication(复制)策略来对系统进行扩展。

核心关注点:

  • 开启Master库Binary log;
  • 复制颗粒度,statement level和row level;
  • 同步过程框架;
  • 读写分离,Master-Slaves复制架构;
  • 单点故障;
  • Dual-Master架构。
  • Dual-Master架构,重复同步
  • Dual-Master架构,停机维护

MySQL的Master与Slave数据同步过程

在这里插入图片描述

MySQL主从配置,参考文章mysql主从同步配置-https://www.cnblogs.com/zhoujie/p/mysql1.html,这篇文章记录的比较详细,更多的是进行一个/etc/my.cnf的文件配置。

复制颗粒度

主从同步的核心就是数据库数据变更后产生的Binary log文件,从库通过copy一份该文件副本,解析文件中的变更记录,然后到从库中执行一条语句(statement level),或者基于一条记录(row level)来达到复制的目的。

复制颗粒度 说明 备注
statement level 基于SQL语句的复制 与SQL语句上下文相关,仅记录变更的SQL语句。减少了Binary log日志量,节约了IO成本。
row level 基于一条记录的复制 与SQL语句上下文无关,仅记录数据变更的内容。但缺点是基于行的复制可能会产生大量的日志内容,IO成本比较高

读写分离,Master-Slaves复制架构

大部分场景是读比写更密集,可以采用读写分离的构架来减轻单库压力,提升整体读写性能。
在这里插入图片描述

Master-Slaves复制架构存在一个隐患,即写依赖,这是一个单点故障,一旦Master服务器down掉了,系统将无法写入,影响整个前端应用的体验。还有一种场景-Master停机维护,以便进行系统维护、升级、优化等,由于Master没有备用机器,一旦停机,与单点故障带来的影响一个样。

Dual-Master架构

正是由于存在单点故障,所以引入了Dual-Master架构,配备两个Master,其中一个Master作为stand by。两个Master间做双向同步配置,Master与Slaves间配置主从同步。
在这里插入图片描述

双Master构架经常被问到的是“重复同步”(因为理所当然的想到数据变更会被记录到Binary log中,Slave库完成同步,需要更新数据库,更新会产生数据日志;反过来Master库又识别到Slave库的Binary log,形成重复同步),首先明确不会存在这种情况,因为Slave库执行的同步变更不会被记录到Binary log中,也就不存在这种重复同步的情况,MySQL不至于那么不智能。

Dual-Master架构的两个Master库通常情况下,也是仅开启一台Master写入,另一台仅仅作为stand by开放,来应对主机维护时,切换写入库。

Dual-Master架构,停机维护

构架已经清楚了,停机维护的流程如下:

  • 1、停止当前Master的所有写操作;
  • 2、在Master上设置只读,set global read_only=1,同时更新MySQL配置文件中的设置,my.cnf配置文件中read_only=1,避免重启失效;
  • 3、在Master上执行show Master status,记录Binary log坐标;
  • 4、使用Master上的Binary log坐标,在stand by的Master上执行select Master_pos_wait(),等待stand by的Master的Binary log跟上Master的Binary log;
  • 5、在stand by的Master开启写入,设置read_only=0;
  • 6、修改app配置,使其写入到新的DB。

假如Master宕机了,即不能执行写操作,此时的处理过程麻烦一点,但需要严格执行,因为Master与stand by此时数据不一定同步,需要将Master上没有同步的Binary log拷贝到stand by,执行replay,直至两者之间Binary log同步,才能开启写入,否则就会导致数据不一致。

真实案例:记得几年前遇到过这种场景,当时是草根投资的用户,他们的数据库宕机了,导致app或web平台的数据查询、充值、提现等操作均出现异常,当时吓得一身冷汗,因为在这个平台上投了点钱,想着不会是跑路了吧(因为当年很多P2P平台出现过跑路、倒闭等问题)。咨询其客服反馈PE正在修复数据库,同时完成数据同步。

备注

文中的图片是通过OmniGraffle软件绘制,如果需要文中原图的话,留言即可。

OmniGraffle是Mac平台上的一款绘图工具,请移步Mac流程图工具OmniGraffle介绍-https://blog.csdn.net/loongshawn/article/details/52282547了解,早些时候可以以优惠价购买授权,目前渠道已经被封了,因此不想花钱的话,只能使用破解版本。

在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/loongshawn/article/details/87991438