mysql集群读写分离与主从同步原理

菀星鋶

已于 2024-08-17 20:38:06 修改

阅读量1k

点赞数 28

文章标签： mysql 数据库

于 2024-08-16 16:04:51 首次发布

本文链接：https://blog.csdn.net/2302_78886445/article/details/141259399

版权

一个高可用、高负载、高性能的“三高”MySQL集群，至少需要12个MySQL节点。为什么需要这么多节点呢？下面我带着你从起点开始推导。

1. 数据同步

单节点的MySQL抗风险性很差，就这么一个MySQL，如果遇上故障数据库挂了，咱们开发的软件项目也就没法用了。不管做的是电商、医疗、外卖、出行业务，软件系统全都歇菜了。俗话说鸡蛋不要放在一个篮子里，我们的MySQL要有冗余节点。

既然要添加冗余节点，就必须借助于数据同步，保证两个MySQL节点数据完全一致。这样挂掉任何一个节点，另一个节点都能立即接替工作。MySQL自带了Master-Slave数据同步模式，也被称作主从同步模式。例如MySQL_A节点开启了binlog日志文件之后，MySQL_A上面执行SQL语句（查询语句除外）都会被记录在binlog日志里面。MySQL_B节点通过订阅MySQL_A的binlog文件，能实时下载到这个日志文件，然后在MySQL_B节点上运行这些SQL语句，于是就保证了自己的数据和MySQL_A节点一致。

MySQL_A被称作Master（主节点），MySQL_B被称作Slave（从节点）。需要注意，主从同步模式里面，数据同步是单向的，如果你在MySQL_A上写入数据，可以同步到MySQL_B上面；如果在MySQL_B上面写入数据，是不能同步到MySQL_A节点的。假设MySQL_A挂了，MySQL_B可以接替工作。但是如果MySQL_A经过维修重新上线，MySQL_A应该从MySQL_B上同步数据，所以我们必须要给MySQL_A和MySQL_B设置双向主从同步，也就是互为主从节点。

2. 读写分离

绝大多数Web系统都是读多写少的，比如电商网站，我们都是要货比三家，然后再下单购买。无论MySQL_A还是MySQL_B单独工作的时候，读写操作都由一个节点执行，压力确实很大，所以我们可以给MySQL找帮手。于是搭建MySQL集群的时候，我划定MySQL_1用来处理写任务，MySQL_2和MySQL_3负责处理读请求。原来一个节点的处理所有SQL语句变成三个节点来分担，MySQL集群的读写性能比单节点MySQL是翻倍的，能并发执行的SQL语句条数也翻倍了。

上面的方案是一主两从，其实多配制一些读节点也没问题，毕竟系统的读任务比较多。但是主从同步有个难题，Master和Slave身份是固定，如果MySQL_1宕机，MySQL_2和MySQL_3都不能升级成写节点。那怎么办呢，给MySQL_1加上双向同步的MySQL_4节点。

如果MySQL_1宕机，MySQL_4可以接替MySQL_1的工作。由于MySQL_2和MySQL_3是与MySQL_1同步，所以MySQL_1宕机之后，MySQL_2和MySQL_3的数据也就不能同步了。况且MySQL_2和MySQL_3不能自动切换到与MySQL_4同步。因此我们要给MySQL_4配置上两个读节点：MySQL_5和MySQL_6。也就是说MySQL_4接替MySQL_1的时候，要用自己的两个从节点。相反MySQL_4宕机，MySQL_1也是用自己的两个从节点。说的直白一些，“一朝天子一朝臣”。比如李世民登基的时候，肯定要用自己的领导集团，老爹的那些大臣哪凉快哪去。如果李渊有机会把儿子赶下皇位，自己重新执政，必然要换掉李世民的大臣，重用自己的老臣。所以MySQL主节点的切换，就跟换皇帝很相似。

3. 数据切分

因为MySQL数据库单表数据量如果超过两千万，该表的读写性能会急剧下降，所以我们要做数据切分，俗称分库分表。比如说一个中型电商网站，每天能产生2万笔订单，算下来10年间大概会有7300万条订单记录。单节点MySQL单表保存这么多记录肯定吃不消，所以我们可以用10个MySQL节点共同承担数据存储任务。每个MySQL节点只存储730万条订单记录，压力并不大。

怎么能把7300万条记录切分存储到10个MySQL节点上呢？其实有很多种算法，最简单的是按照主键求余数切分。比如说每个订单记录的主键值对10求余数，余数范围是0~9之间。如果余数是0，这个INSERT语句被MyCat发送给MySQL_1执行；余数是1，INSERT语句被发送给MySQL_2执行，然后以此类推。由于每个MySQL节点可以被称作分片，所以我们可以说成数据被切分到10个分片之中。

4. 数据切分也要满足三高

上面的示意图中，由于每个MySQL节点保存的数据都不相同，所以某个节点如果宕机了是没有冗余节点了。因此每个MySQL节点都要被改造成三高方案才可以。就拿MySQL_1节点来说，如果用上了读写分离和双主同步，至少是6个MySQL节点。

如果每个分片都要用6个MySQL节点，10个分片总共就得用60个MySQL节点。对于一个中型电商网站来说，数据库集群的成本还能接受。也许有的同学担心日积月累，20年之后10个分片肯定也不够用，到时候应该怎么做呢？这个也不复杂，有两个办法。其一是做扩容，比如说再增加10个分片。增加分片就牵扯到数据重新切分，数据迁移的时间成本还是很高的。不到万不得已，一般不添加分片。其二是定期缩表，就是把几年前的数据迁移到MongoDB或者HBase这样的大数据库平台上面，它们保存PB级数据都毫无压力。我们只在MySQL集群中保存最近今年的数据，这样就能缓解数据存储的压力了。

5.为什么使用MySQL5.7版本？

因为MySQL8.0的主从同步功能做的不好，MySQL宕机重新上线之后，数据不能自动同步，需要人工对比日志和维护，才能重新实现数据同步。比如MySQL_1和MySQL_2为双向主从同步，如果MySQL_1宕机了两个小时，经过检查维修之后重新上线，按理说MySQL_1应该自动去同步MySQL_2的数据。但是8.0版本的MySQL偏偏不行，人工对比两个数据库之间日志的差异，然后执行若干的命令才能让MySQL_1成功同步到MySQL_2。如果MySQL_2一直不断的有新数据写入，人工核对日志的速度远远赶不上数据写入的速度，就只能停掉业务系统了。这么看来，一个宕机的MySQL节点想要重新上线，代价就是停掉前后端业务系统，这个成本是不是太高了。我们不应该盲目的追求MySQL新版本，稳定省心的MySQL5.7才是最佳方案，而且MySQL5.7同样支持JSON字段类型，我们可以放心的使用。

6.为什么使用MYCAT管理数据库集群？

管理MySQL集群可以选用很多种中间件方案，比如说MyCat、ShardingSphere、ProxySQL等等。有的人觉得MyCat是很老的中间件产品了，而且版本更新也不是很快，还不如选用ShardingSphere呢。有这种想法也很正常，我不是没有考虑过ShardingSphere方案。我那门《华夏代驾》的实战课用的就是ShardingSphere做数据切分的。但是本课程不需要数据切分，只需要主从同步和读写分离就够了。ShardingSphere恰恰对这两块支持的特别不好，从低到高，每个ShardingSphere版本我都测试过了，无一例外。所以我们还是老老实实的用回MyCat的吧。