“Whatever the soul knows how to seek, it cannot fail to obtain. ”
1.为什么需要主从复制
周所周知在服务器开发中,没有什么是可靠的包括网络硬盘等等一系列资源。所以就会出现服务器集群在一台机器出现问题的时候集群里的其他机器还能提供服务
备份
备份很好解释,就是从节点从主节点同步数据,然后只作为备份的功能。但是其实这样做的很少,因为会浪费掉一台机器的资源,所以绝大部分公司都是使用主从做读写分离
读写分离
随着业务量的扩展、如果是单机部署的MySQL,会导致I/O频率过高。采用主从复制、读写分离可以提高数据库的可用性。
因为在很多场景中,都是读多写少的情况,所以可以几台从节点同步一个主节点的信息。大大提升业务系统的效率
2.mysql主从配置的几种方式
主从配置的原理也很简单,就是从节点读取主节点的binlog日志文件,然后在自己的节点上执行。所以主从同步需要开通主节点的binlog日志
2.1异步复制
客户端发送DDL/DML语句给master,master执行完毕立即返回成功信息给客户端,而不管slave是否已经开始复制。这样的复制方式导致的问题是,当master写完了binlog,而slave还没有开始复制或者复制还没完成时,slave上和master上的数据暂时不一致,且此时master突然宕机,slave将会丢失一部分数据。如果此时把slave提升为新的master,那么整个数据库就永久丢失这部分数据。
默认就是异步复制,不安装半同步配置的插件即可
2.2半同步复制
客户端发送DDL/DML语句给master,master执行完毕后还要等待一个slave写完relay log并返回确认信息给master,master才认为此次DDL/DML语句是成功的,然后才会发送成功信息给客户端。半同步复制只需等待一个slave的回应,且等待的超时时间可以设置,超时后会自动降级为异步复制,所以在局域网内(网络延迟很小)使用半同步复制是可行的。
2.2.1开启插件
使用INSTALL语句在master上安装 semisync_master.so 插件。
1 | install plugin rpl_semi_sync_master soname 'semisync_master.so'; |
安装插件后,应该使用show plugins
来查看插件是否真的激活。
1 | mysql> show plugins; |
或者查看information_schema.plugins
表获取更详细的信息。
1 | mysql> select * from information_schema.plugins where plugin_name like "%semi%"\G |
插件装载完成后,半同步功能还未开启,需要手动设置它们启动,或者写入配置文件永久生效。
1 | # 开启master的半同步 |
2.2.2MySQL Server的配置文件
以下是master的配置文件。
1 | [mysqld] |
以下是slave1的配置文件,注意slave1同时还充当着slave2和slave3的master的角色。
1 | [mysqld] |
以下是slave2和slave3的配置文件,它们配置文件除了server-id外都一致。
1 | [mysqld] |
2.2.3启动复制线程
现在master上创建一个专门用于复制的用户。
1 | mysql> create user repl@'192.168.100.%' identified by 'P@ssword1!'; |
因为master和所有的slave都是全新的实例,所以slave上指定的binlog坐标可以从任意位置开始。不过刚才master上创建了一个用户,也会写binlog,所以建议还是从master的第一个binlog的position=4开始。
以下是slave1上的change master to
参数:
1 | mysql> change master to |
以下是slave2和slave3的change master to
参数:
1 | mysql> change master to |
启动各slave上的两个SQL线程。
1 | mysql> start slave; |
一切就绪后,剩下的事情就是测试。在master上对数据做一番修改,然后查看是否会同步到slave1、slave2、slave3上。
- 注意如果出现错误,请先查看日志文件名称和日志位点是否正确!!!
同步复制
客户端发送DDL/DML语句给master,master执行完毕后还需要等待所有的slave都写完了relay log才认为此次DDL/DML成功,然后才会返回成功信息给客户端。同步复制的问题是master必须等待,所以延迟较大,在MySQL中不使用这种复制方式。
- 使用Mysql Cluster
未来展望
现如今来说,已经有mysql集群的强一致性方案了
官方的 MySQL官方的 Group Replication (MGR)方案,通过 Paxos 协议提供数据库集群节点数据强一致保证,超越了传统的主从架构
meta公司也宣布了基于raft协议实现的mysql的强一致性方案
另外,现如今分布式数据库也是大厂都在研究的,推出了很多云服务,例如:AWS aurora,snowflake等所以在未来一定会有越来越多的解决方案,而不仅仅局限于mysql
参考链接
https://www.cnblogs.com/f-ck-need-u/p/9155003.html
https://engineering.fb.com/2023/05/16/data-infrastructure/mysql-raft-meta/