MariaDB 10 (MySQL DB) 多主复制并实现读写分离

----本文大纲

• 简介

• 资源配置

• 拓扑图

• 实现过程

   

一、简介

MMM 即Master-Master Replication Manager for MySQL（mysql主主复制管理器）关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件（在任何时候只有一个节点可以被写 入），这个套件也能对居于标准的主从配置的任意数量的从服务器进行读负载均衡，所以你可以用它来在一组居于复制的服务器启动虚拟ip，除此之外，它还有实 现数据备份、节点之间重新同步功能的脚本。MySQL本身没有提供replication failover的解决方案，通过MMM方案能实现服务器的故障转移，从而实现mysql的高可用。MMM不仅能提供浮动IP的功能，更可贵的是如果当前 的主服务器挂掉后，会将你后端的从服务器自动转向新的主服务器进行同步复制，不用手工更改同步配置。这个方案是目前比较成熟的解决方案。

优点：安全性、稳定性高，可扩展性好，高可用，当主服务器挂掉以后，另一个主立即接管，其他的从服务器能自动切换，不用人工干预。

缺点：至少三个节点，对主机的数量有要求，需要实现读写分离，对程序来说是个挑战。

主从复制原理：

第一步是在主库上记录二进制日志（稍后介绍如何设置）。在每次准备提交事务完成数 据更新前，主库将数据更新的事件记录到二进制日志中。MySQL会按事务提交的顺序 而非每条语句的执行顺序来记录二进制日志。在记录二进制日志后，主库会告诉存储引 擎可以提交事务了。 _

下一步，备库将主库的二进制日志复制到其本地的中继日志中。首先，备库会启动一个 工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后在主库上启 动一个特殊的二进制转储(binhg dump、线程（该线程没有对应的SQL命令），这个二 进制转储线程会读取主库上二进制日志中的事件。它不会对事件进行轮询。如果该线程 追赶上了主库，它将进入睡眠状态，直到主库发送信号量通知其有新的事件产生时才会 被唤醒，备库I/O线程会将接收到的事件记录到中继日志中。

备库的SQL线程执行最后一步，该线程从中继日志中读取事件并在备库执行，从而实现 备库数据的更新。当SQL线程追赶上I/O线程时，中继日志通常已经在系统缓存中，所 以中继日志的开销很低。SQL线程执行的事件也可以通过配置选项来决定是否写入其自 己的二进制日志中，它对于我们稍后提到的场景非常有用。这种复制架构实现了获取事件和重放事件的解耦，允许这两个过程异步进行。也就是说 I/o线程能够独立于SQL线程之外工作。但这种架构也限制了复制的过程，其中最重要 的一点是在主库上并发运行的査询在备库只能串行化执行，因为只有一个SQL线程来重 放中继日志中的事件。后面我们将会看到，这是很多工作负载的性能瓶颈所在。虽然有 一些针对该问题的解决方案，但大多数用户仍然受制于单线程。

二、资源配置

• 主机属性

• 虚拟ip(VIP)

DB1    192.168.1.109   192.168.1.24

DB2    192.168.1.112    192.168.1.24,192.168.1.22

DB3    192.168.1.113    192.168.1.23

三、拓扑图