DDR爱好者之家 Design By 杰米

一主多从复制架构

在主库读取请求压力非常大的场景下,可以通过配置一主多从复制架构实现读写分离,把大量的对实时性要求不是特别高的读请求通过负载均衡分部到多个从库上(对于实时性要求很高的读请求可以让从主库去读),降低主库的读取压力,如下图所示。

在主库出现异常宕机的情况下,可以把一个从库切换为主库继续提供服务。

在主从复制场景下会出现主从延迟,想想该怎么解决?

MySQL 4种常用的主从复制架构

多级复制架构

一主多从的架构能够解决大部分读请求压力特别大的的场景的需求,考虑到MySQL的复制需要主库发送BINLOG日志到从库的I/O线程,主库的I/O压力和网络压力会随着从库的增加而增长(每个从库都会在主库上有一个独立的BINLOG Dump线程来发送事件),而多级复制架构解决了一主多从场景下的,主库额外的I/O和网络压力。MySQL的多级复制架构如下图所示。

MySQL 4种常用的主从复制架构

对比一主多从的架构,多级复制仅仅是在主库Master1复制到从库Slave1、Slave2、Slave3的中间增加了一个二级主库Master2,这样,主库Master1只需要给一个从库Master2发送BINLOG日志即可,减轻了主库Master1的压力。二级主库Master2再发送BINLOG日志给所有的从库Slave1、Slave2和Slave3的I/O线程。

多级复制解决了一主多从场景下,主库的I/O负载和网络压力,当然也有缺点:MySQL的传统复制是异步的,多级复制场景下主库的数据是经历两次复制才到达从库Slave1、Slave2、Slave3的,期间的延迟要比一主多从复制场景下只经历一次复制的还大。

可以通过在二级主库Master2上选择表引擎为BLACKHOLE来降低多级复制的延迟。顾名思义,BLACKHOLE引擎是一个“黑洞”引擎,写入BLACKHOLE表的数据并不会写会到磁盘上,BLACKHOLE表永远都是空表,INSERT、UPDATE、DELETE操作仅仅在BINLOG中记录事件。

CREATE TABLE `user` (
	`id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
	`name` varchar(255) NOT NULL DEFAULT '',
	`age` tinyint unsigned NOT NULL DEFAULT 0
)ENGINE=BLACKHOLE charset=utf8mb4;
INSERT INTO `user` (`name`,`age`) values("itbsl", "26");
SELECT * FROM `user`;

MySQL 4种常用的主从复制架构

可以看到,存储引擎为BLACKHOLE的user表里没有数据。

BLACKHOLE引擎非常适合二级主库Masger2的场景:Master2并不承担读写请求,仅仅负责将BINLOG日志尽快传送给从库。

双主(Dual Master)复制架构

双主(Dual Master)复制架构适用于DBA做维护时需要主从切换的场景,通过双主复制架构避免了重复搭建从库的麻烦,双主复制架构如下图所示。

MySQL 4种常用的主从复制架构

主库Master1和Master互为主从,所有Web Client的写请求都访问主库Master1或Master2。加入,DBA需要做日常维护操作,为了避免影响服务,需进行一下操作。

  • 首先,在Master1库上停止Slave线程(STOP SLAVE),避免后续对Master2库的维护操作操作被实时复制到Master1库上对服务造成影响。
  • 其次,在Master2库上停止Slave线程(STOP SLAVE),开始日常维护操作,例如修改varchar字段从长度10增加到200。
  • 然后,在Master2库上完成维护操作之后,打开Master2库上的Slave线程(STRART SLAVE),让Master2的数据和Master1库同步,同步完成后,把应用的写操作切换到Master2库上。
  • 最后,确认Master1库上没有应用访问后,打开Master1的Slave线程(START SLAVE)即可。

通过双主复制架构能够大大减轻一主多从架构下对主库进行维护带来的额外搭建从库的工作。

当然双主架构还能和主从复制联合起来使用:在Master2库下配置从库Slave1、Slave2等,这样既可通过从库Slave1等来分担读取压力,同时在DBA做维护的同时,避免了重建从库的额外工作,但需要注意从库的复制延迟。MySQL双主多级复制架构如下所示。

MySQL 4种常用的主从复制架构

多源(Multi-Source)复制架构

多源(Multi-Source)复制架构适用于复杂的业务需求,既可以支撑OLTP(联机事务处理),也可以满足OLAP(联机分析处理)。MySQL的多源复制架构我就暂时不画啦,等有空再画好补充上(画图也是个体力活呀)。有兴趣的可以看《深入浅出MySQL数据库开发、优化与管理维护》这本书。

如何优化主从延迟问题?

  • 优化网络环境
  • 在MySQL5.5~MySQL5.6中,使用半同步复制
  • 在MySQL5.7中,可以使用增强半同步复制(也称为无损复制)

关于MySQL主从延迟的具体信息,可以看我的另一篇文章聊聊MySQL主从复制的几种复制方式。

整理自:

《深入浅出MySQL数据库开发、优化与管理维护》这本书。

以上就是MySQL 4种常用的主从复制架构的详细内容,更多关于MySQL 主从复制架构的资料请关注其它相关文章!

DDR爱好者之家 Design By 杰米
广告合作:本站广告合作请联系QQ:858582 申请时备注:广告合作(否则不回)
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
DDR爱好者之家 Design By 杰米

《魔兽世界》大逃杀!60人新游玩模式《强袭风暴》3月21日上线

暴雪近日发布了《魔兽世界》10.2.6 更新内容,新游玩模式《强袭风暴》即将于3月21 日在亚服上线,届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。

艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕,并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时,他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中,玩家将会进入一个全新的海盗主题大逃杀式限时活动,其中包含极高的风险和史诗级的奖励。

《强袭风暴》不是普通的战场,作为一个独立于主游戏之外的活动,玩家可以用大逃杀的风格来体验《魔兽世界》,不分职业、不分装备(除了你在赛局中捡到的),光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式,玩家在加入海盗主题的预赛大厅区域前,可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹,《巨龙崛起》和《魔兽世界:巫妖王之怒 经典版》的玩家都可以获得奖励。