机器学习和AI的时代来了

参考：https://code.google.com/p/mysql-master-ha/wiki/Overview

一、官网场景—— 一主多从

1.主要使用场景：提供master容灾，在master宕机之后，以最短的时间自动将slave提升为master。

工作方式：在master dead之后，自动选择一个slave（可以配置一个优先slave）接管master业务。并配置其他slave切换replication到新的master。

2.除此之外还有：在线master切换（0.5s-2s的不可写时间）。

二、难点——当然也就是MHA试图解决的问题

以下是手工打造时的难点，而MHA进行了解决。

1.选最新的slave接管master。

最新不好检查及选择。

2.其他不是最新的slave的一致性问题。

其他slave切换到新master，会丢失与原master的transaction，造成binary log event不一致。

手工检查binlog是一件很复杂且不易操作的事情。

三、官网wiki提供的其他各种solution

参考：https://code.google.com/p/mysql-master-ha/wiki/Other_HA_Solutions#Master,_one_candidate_master,_and_multiple_slaves

待续…

一、编写MHA配置文件

1.全局配置文件

编辑：/etc/masterha_default.cnf

2.应用配置文件

每个slaver的配置文件单独编写。而且需要为多个app单独编写配置文件，并在配置文件中使用不同的物理路径。

app1

app2

二、其他配置

参考：https://code.google.com/p/mysql-master-ha/wiki/Requirements

运行masterha_manager来检查配置是否有缺漏。

1.ssh 免密码登陆

检查：

注： masterha_check_ssh 不加配置文件则会报错：

2.关闭自动清除relay log^[1]

关闭原因：By default, relay logs on slave servers are automatically removed if SQL threads have finished executing them. But such relay logs might still be needed for recovering other slaves.

^{什么是relay log： relay-log日志记录的是从服务器I/O线程将主服务器的二进制日志读取过来记录到从服务器本地文件，然后SQL线程会读取relay-log日志的内容并应用到从服务器。}

配置方法：

关闭之后要手工进行relay log文件的清理，使用Linux自己的cron。周期可以根据磁盘及文件保留期情况自行安排。

三、测试使用

1.测试master 不存在

关闭master

可以查看日志：

 

登陆slave机

可以代替master的功能接收数据。

2.重新启动原master

 

【注1】原master起来以后有个问题，就是其全局可写。如果这时有数据插进来，会造成新老master数据不一致。因此应该在重启原master后首先设置global read_only=1。然后将原master切为slave，从新master上同步所有数据。

【注2】同步数据时，原master会等到新master有一次数据操作时，统一将所有数据变化同步过来。这个时刻不是在配完slave后就完成，需等新master。

切换主从的blog：http://bananalighter.com/change-slaver2master/

参考：http://ylw6006.blog.51cto.com/470441/890360/