MySQL主主复制技术+Keepalived

MM+keepalived 

简介：

双主配合keepalived这种架构设计，也是基于主从复制的原理而搭建的。

使用MySQL主主复制技术+Keepalived是一种简单、便捷的解决方案，在高可用集群环境中，keepalived使用VIP，使用Keepalived自带的服务监控功能和自定义脚本来实现MySQL故障时自动切换，非常灵活。

应用范围：

一般中小型公司都使用这种架构，搭建比较方便简单；

可以采用主从或者主主模式，在 master 节点发生故障后，利用 keepalived 高可用机制实现快速切换到 slave 节点。原来的从库变成新的主库。

个人建议：

1. 一定要完善好切换脚本，keepalived 的切换机制要合理，避免切换不成功的现象发生。
   

2. 从库的配置尽快要与主库一致，不能太次；避免主库宕机发生切换，新的主库（原来的从库）影响线上业务进行。
   

3. 对于延迟的问题，在这套架构中，也不能避免。可以使用 mysql 5.7 中增强半同步完成。也可以改变架构使用 PXC，完成时时同步功能，基本上没有延迟；
   

4. keepalived 无法解决脑裂的问题，因此在进行服务异常判断时，可以修改我们的判断脚本，通过对第三方节点补充检测来决定是否进行切换，可降低脑裂问题产生的风险。
   

5. 采用 keepalived 这个架构，在设置两节点状态时，都要设置成不抢占模式，都是 backup 状态，通过优先级，来决定谁是主库。避免脑裂，冲突现象发生。
   

6. 安装好 mysql 需要的一些依赖包；建议配置好 yum 源，用 yum 安装 keepalived 即可。

搭建架构之前理清思路：

1. 首先需要装有两台mysql的数据库服务器，两者之间互为主从模式，都可读写。其实就只有一台服务器A负责数据的写入工作，而另一台服务器B作为我们的备用数据库；

2. 安装keepalived的软件包，个人建议使用yum安装就可以，很方便。当然我们要知道yum安装之后的软件路径在什么位置。

3. 整理好keepalived的配置文件，理清keepalived的三种状态信息。还要准备一个监控MySQL的脚本，便于检测到宕机顺利发生切换的过程。

4. 所有提供服务的从服务器与备用服务器B进行主从同步。----双主从库模式

5. 在两台服务器A和B，当配置keepalived的参数文件中，要注意两台机器都要采用backup这种状态，就是nopreempt这种非抢占模式，避免出现冲突，发生脑裂现象。

架构图展示：

实验部署环境介绍：

192.168.56.100 主 ---master1

192.168.56.101 备库---master2

都是干净环境没有任何数据

VIP：192.168.56.111

MySQL数据库版本5.7.14，采用GTID模式搭建主从环境

注意事项：

1. 两台机器的防火墙必须是关闭状态。

2. 两台MySQL数据库配置文件中server-id绝对不能一样，要不会报1593这个主从同步的错误，导致搭建不成功。
   

实战开始：

首先先要搭建两台MySQL数据库为互为主从的架构模式。

添加主从同步账号：

在192.168.56.100：

grant replication slave on *.* to 'bak'@'192.168.56.%' identified by '123456';

flush privileges;

在192.168.56.101：

grant replication slave on *.* to 'bak'@'192.168.56.%' identified by '123456';

flush privileges;

配置同步信息：

先在192.168.56.101上：

CHANGE MASTER TO MASTER_HOST='192.168.56.100',MASTER_USER='bak',MASTER_PASSWORD='123456',master_auto_position=1;

打开主从同步开关：

start slave；

查看主从同步状态：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61

root@db 10:49:  [(none)]> show slave status\G; *************************** 1. row ***************************                 Slave_IO_State: Waiting  for  master to send event                    Master_Host: 192.168.56.100                    Master_User: bak                    Master_Port: 3306                  Connect_Retry: 60                Master_Log_File: mybinlog.000005            Read_Master_Log_Pos: 234                 Relay_Log_File: node2-relay-bin.000010                  Relay_Log_Pos: 365          Relay_Master_Log_File: mybinlog.000005               Slave_IO_Running: Yes              Slave_SQL_Running: Yes                Replicate_Do_DB:             Replicate_Ignore_DB:              Replicate_Do_Table:          Replicate_Ignore_Table:         Replicate_Wild_Do_Table:     Replicate_Wild_Ignore_Table:                      Last_Errno: 0                     Last_Error:                    Skip_Counter: 0            Exec_Master_Log_Pos: 234                Relay_Log_Space: 572                Until_Condition: None                 Until_Log_File:                   Until_Log_Pos: 0             Master_SSL_Allowed: No             Master_SSL_CA_File:              Master_SSL_CA_Path:                 Master_SSL_Cert:               Master_SSL_Cipher:                  Master_SSL_Key:           Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No                  Last_IO_Errno: 0                  Last_IO_Error:                  Last_SQL_Errno: 0                 Last_SQL_Error:     Replicate_Ignore_Server_Ids:                Master_Server_Id: 3306100                    Master_UUID: 913cc1d6-771a-11e7-8fe1-080027f1fd08               Master_Info_File: mysql.slave_master_info                      SQL_Delay: 0            SQL_Remaining_Delay: NULL        Slave_SQL_Running_State: Slave has  read  all relay log; waiting  for  more  updates             Master_Retry_Count: 86400                    Master_Bind:         Last_IO_Error_Timestamp:        Last_SQL_Error_Timestamp:                  Master_SSL_Crl:              Master_SSL_Crlpath: