MYSQL性能优化之Mysql数据库高可用架构设计之MMM架构设计（上）

高可用性H.A.（High Availability）指的是通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。HA系统是目前企业防止核心计算机系统因故障停机的最有效手段。

使用正常可用时间和全年时间百分比来表示高可用

99999 （365*24*60）*（1-0.99999） = 5.256分钟

严重的主从延迟

主从复制中断

锁引起的大量阻塞

软硬件故障，服务器宕机

成本和高可用性呈正相关，结合业务和成本来考虑

单点故障的解决

IDC机房

网卡……

方法1：共享存储

缺点：共享存储本身就是一个单点，随机IO性能不理想

优点：避免除存储外其他组件

方法2：DRDB磁盘（推荐）

优：数据冗余

缺：故障转移所需时间比较长，备用服务器不能提供服务（包括读），成本高。磁盘文件损坏，主备文件都会损坏





多写集群性能取决于最差的机器

多写集群mysql写入性能肯定比单台性能差

第二种比较完美，但是如果内存不足，NDB集群的性能就会非常差（很少使用到生产环境中）

面临的问题：主服务器的单点问题

MMM架构

通过监控服务器MMM和各个服务器上的监控代理软件交互来完成监控和数据库迁移的

MMM（Master-Master replication manager for MySQL）是一套支持双主故障切换和双主日常管理的脚本程序。MMM使用Perl语言开发，主要用来监控和管理MySQL Master-Master（双主）复制。

虽然叫做双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主主切换时刻备选主的预热，可以说MMM这套脚本程序一方面实现了故障切换的功能，另一方面其内部附加的工具脚本也可以实现多个slave的read负载均衡。

可以看上一篇我写的文章：主备模式的主主复制



MMM提供了自动和手动两种方式移除一组服务器中复制延迟较高的服务器的虚拟ip，同时它还可以备份数据，实现两节点之间的数据同步等。由于MMM无法完全的保证数据一致性，所以MMM适用于对数据的一致性要求不是很高，但是又想最大程度的保证业务可用性的场景。对于那些对数据的一致性要求很高的业务，非常不建议采用MMM这种高可用架构。

MMM功能

- MMM简单的找到主库的当前日志点，然后使所有的从库日志点和该日志点同步。如果在一个繁忙的系统中，很有可能对数据造成丢失的情况

- 写虚拟IP只能在两个主服务器之间切换，读虚拟IP可以在任意服务器之间切换

MMM部署所需资源

两个主服务器配置要尽量相同，否则会引起性能问题

查看MySQL服务器配置信息 mysql> show variables;

查看MySQL服务器运行的各种状态值 mysql> show global status;

server_id肯定不一样

从服务器分担负载，但是不能太多（出现的问题会越来越大）

监控服务器监控主从复制情况和复制链路情。当出现宕机或者主从延迟大于某个阈值时,虚拟IP切换。

一个监控服务器可以监控多个服务器集群，最好使用独立的服务器资源

每一个数据库服务器上都会有两个IP：服务器物理IP，读需IP.主服务器需要一个写需IP

MMM部署步骤

MMM演示拓扑图

MMM演示

建立复制账号

主库备份（复制到备主服务器和从服务器）100

主主同步复制（两个主都需要复制）

备主服务器数据复制101

导入数据库，mysql -uroot -p < all.sql

查看主服务器二进制日志名字和时间点 all.sql

主服务器数据复制100

从服务器数据复制102

导入数据库，mysql -uroot -p < all.sql

查看主服务器二进制日志名字和时间点 all.sql

各个服务器优化yum源及工具安装

下载rpm包

wget http://mirrors.opencas.cn/epel/epel-release-latest-6.noarch.rpm[/code] 


安装rpm

rpm -ivh epel-.....rpm
rpm -ivh remi-.....rpm


编辑配置文件

vim /etc/yum.repos.d/remi.repo




vim /etc/yum.repos.d/epel.repo




安装监控服务
yum search mmm




yum install mysql-mmm-agent.noarch -y 每个服务器都要安装的代理(3个)


安装监控服务器包
yum -y install mysql-mmm*


数据账号主创建->同步到主备，从服务器
监控用户
代理用户（故障转移，主从切换）
复制用户（复制集群时已经创建）


MMM数据库节点配置
vim /etc/mysql-mmm/mmm_common.conf(所有集群节点必须一致)








统一网卡设备号

ips 虚拟IP

拷贝到所有其他服务器



vim /etc/mysql-mmm/mmm_agent.conf 配置各个服务器名（保证不冲突）




MMM数据库监控节点配置（监控服务器102）
vim /etc/mysql-mmm/mmm_mon.conf


ping_ips额外检查所需要的新IP地址,为了防止MMM切换出现脑裂，建议大家把所有的服务器ip，还有网关都写上（仲裁机制）

auto_set_online 主机出现问题，恢复之后在线时间

What does “split-brain” mean?(红帽文档的解释)
“Split brain” is a condition whereby two or more computers or groups of computers lose contact with one another but still act as if the cluster were intact. This is like having two governments trying to rule the same country. If multiple computers are allowed to write to the same file system without knowledge of what the other nodes are doing, it will quickly lead to data corruption and other serious problems.

Split-brain is prevented by enforcing quorum rules (which say that no group of nodes may operate unless they are in contact with a majority of all nodes) and fencing (which makes sure nodes outside of the quorum are prevented from interfering with the cluster).

解决方案：磁盘锁 仲裁机制 或者冗余心跳线等方式来解决



MMM启动
三台服务器(节点) /etc/init.d/mysql-mmm-agent start
监控服务器启动监控服务 /etc/init.d/mysql-mmm-monitor start
查看当前集群的状态 mmm_control show






虚拟IP正确配置（监控服务器）


测试
关闭主服务器
/etc/init.d/mysqld stop


监控服务器查看
mmm_control show




主从关系变化（查看配置）

show slave master 用于提供有关从属服务器线程的关键参数的信息



MMM集群优点
可以使用Prel语言来自己定制

主数据库IP变更后如何通知应用对新的主DB进行连接？->虚拟IP（读和写）。

前端使用的是虚拟IP

主从延迟过高，就会把延迟过高的服务器迁移到没有延迟的服务器上（避免了因数据延迟导致业务逻辑上的错误）

原主和主备是主主同步的关系，故障服务器重新上线可以自动的对主进行同步

可以对多个MMM集群进行监控，节约服务器成本







MMM集群缺点




不支持gtid,多线程。

主从不一致的主要原因是主是多线程的，从是单线程的。并发写压力大时，无法使用多线程同步的配置。MMM会自动把主从延迟大的从服务器读VIP迁移到其他服务器上或者主服务器上。在写并发压力大时，可能会出现读VIP全部集中到主服务器上，进而导致连接数占满或者压宕机

LVS F5

由于mysql是异步的，不能保证日志点都是最近的，所以容易造成事务丢失或者重复提交事务（主从切换没有对比从服务器日志同步点进而选择最新的从服务器，而是主备，就是它）

需要开发MMM监控服务的监控程序