利用Mysql5.7的新特性实现多机房高可用架构【转】

时间:2024-07-14 12:33:32

再牛逼的架构也敌不过挖掘机,无论单机房内你的架构多么的高可用,多么的完善,当挖掘机挖下去那一瞬间,都是扯蛋,楼主所在的公司也被挖掘机挖断过光纤、电力线。

为什么大家都在谈论服务冗余,缓存击穿等高可用时,很少人谈到数据库的高可用呢?这是因为数据库是有状态的。服务可以部署到多个机房,并且同时提供服务,但是数据库却只能有一个机房做主服务,如果多机房,每个机房都有自己的主服务,那么多主同时写造成的数据冲突,同步问题所耗费的人力,物力将会得不偿失,而单主带来的问题是: mysql5.6/mysql5.5的同步模板是after-commit,也就是主服务器会保证主上binlog已经落盘,并且异步发送给slave,这个时候用户已经在主服务器上能看到提交的事务,假如此时出现网络问题,另外一个机房的slave变成主时,用户会发现刚才做的操作都回滚了,也就是事务不见了。

为了解决这个问题,mysql5.7引入了after-sync模式,这个模式下,master必须等待salve已经把binlog落盘,才会把事务提交到存储层,并且返回给客户端成功。

这个时候我们可以在同城搭建三个机房A、B、C,其中A、B机房做为冗余部署,服务,数据库都各部署一套,而C机房只部署数据库,做为数据库的日志机房。我们开启Mysql的半同步模式after-sync, 这个时候他可以保证在返回给客户端事务提交成功时,日志肯定已经同步给B、C中的任意机房,当某一天A的断电的时候,这个时候,我们只需要DBA对比B、C的日志文件,如果发现B比C多,那么直接把B做为主,C做为备,将所有流量切到B机房即可;如果发现C机房日志比B机房多,这种情况发生在,断电的瞬间,A和B之间的网络先断开,部分事务成功发送到C,这个时候,由DBA手动将C多出的日志同步到B,再开启B做为主服务,所有流量切到B机房,这个操作可以在半小时内完成。虽然此架构不能保证A断电的情况,B能立即提供服务,但是这个方案能保证不丢失数据,并且能在极短的时间内恢复。

架构图如下:

利用Mysql5.7的新特性实现多机房高可用架构【转】

转自

https://www.toutiao.com/i6497872566609248781/