环境：

三台percona server：210, 211, 227。

210为M——master，211为M2——candidate master ，227为S——slave。

整体架构为：

M(读写)  —  M2(只读)
|
S(只读)

实际配置上，M2与S是两个平行的slave（从机）。

唯一区别：在master HA的配置中，配置M2为candidate master。当master宕机时，优先将M2升级为新master。

 

一、配master

可以参考主从配置的blog：http://bananalighter.com/mysql-master-slaver-replication/

dump出数据供slave建库使用。

二、配candidate master和slave(注意只读)

1.candidate master（211机器，已经在主从模式中配置过my.cnf，不赘述）

 

2.slave

（1）创建数据库

（2）导入前述步骤导出的数据库数据。

 

（3）配置my.cnf

重启数据库

（4）新建同步用户，配权限及master

（5）在这里有个问题，困扰我一下午。

show slave status\G报错：

Last_Error: Error ‘Duplicate entry ‘7’ for key ‘PRIMARY” on query. Default database: ‘test’. Query: ‘insert into test (id,value) values (7,77)’

我理解，这是由于slave同步到了不够新的relay log，有些重做的sql数据其实已经dump出来了，就不能再插一次。思路是清一清master的log。

不过下文的哥们通过让slave跳过这些sql绕开了这些问题。

参考：http://blog.sina.com.cn/s/blog_502c8cc401010p4b.html

注：只读的概念参见文章：http://bananalighter.com/mysql-variables-read-only/

（6）三个服务器的同步测试

在master插入一条数据，两个从机同步更新，不赘述。

三、配置master HA

（1）编辑master HA 配置文件/etc/masterha/test_MMS.cnf

注：

candidate_master
You might use different kinds of machines between slaves, and want to promote the most reliable machine to the new master (i.e. promoting a RAID1+0 slave rather than RAID0 slaves).
By setting candidate_master to 1, the server is prioritized to the new master, as long as it meets conditions to be the new master (i.e. binary log is enabled, it does not delay replication significantly, etc). So candidate_master=1 does not mean that the specified host always becomes new master when the current master crashes, but is helpful to set priority.
If you set candidate_master=1 on multiple servers, priority is decided by sort order by block name ([server_xxx]). [server_1] will have higher priority than [server_2].
no_master
By setting no_master=1 on the target server, the server never becomes the new master. This is useful if you have some servers that should not become the new master. For example, you may want to set no_master=1 when you run slaves on unreliable (RAID0) machine, or when you run a slave at a remote data center. Note that if none of the slaves can be new master, MHA aborts and does not start monitoring/failover.

（2）配各个机器的hosts文件和ssh免密登陆

（3）检查并运行masterHA

各种mysql同步的错误和状态解释： http://www.jb51.net/article/27221.htm

卧槽，MHA就没生效啊！ 啊啊啊！尼玛

反复检查了好多遍，费了两天时间，终于知道为啥了。

原因是在masterha的默认配置文件中添加了master_ip_failover_script的配置（抄的官网），但是并没有编写对应的脚本。所以调用出错。太脑残了。

注释掉相关配置就好啦。

以下是测试，还特么的有错：

检查slave机的mysql日志：

被这个问题刷屏了。搜索发现大部分人报告的问题是server_id相同导致的master端识别slave混乱。但我的是不同的。

再深度搜索，终于被一文章救命了：http://www.2cto.com/database/201405/305269.html

还是master对slave的识别混乱问题，不过这次搞相同了的是server_uuid。

查看如下。

修复手段：修改/mysql_data_dir/auto.cnf

重启数据库，重启slave。

done！！！

终于ok了，从部署好至此过了3天。神坑爹。

四、failover测试

场景——M跪，M2起，S挂到M2

以下是各种输入输出：

M（210）：

M2（211）：

S（227）：

明显master切到了211。

五、复原

将M先设为M2 的slave

使用masterHA自带的切换工具masterha_master_switch

注：这里

对于生产系统还是要先把数据刷到盘里的，这里测试就不费劲了。

 

【转载】：http://blog.csdn.net/cindy9902/article/details/5886355

  –read_only         Make all non-temporary tables read-only, with the
exception for replication (slave) threads and users with
the SUPER privilege

SUPER privilege :

The SUPER privilege enables an account to use CHANGE MASTER TO , KILL or mysqladmin kill to kill threads belonging to other accounts (you can always kill your own threads), PURGE BINARY LOGS , configuration changes using SET GLOBAL to modify global system variables, the mysqladmin debug command, enabling or disabling logging, performing updates even if the read_only system variable is enabled, starting and stopping replication on slave servers, specification of any account in the DEFINER attribute of stored programs and views, and enables you to connect (once) even if the connection limit controlled by the max_connections system variable is reached.

To create or alter stored routines if binary logging is enabled, you may also need the SUPER privilege, as described in Section 18.6, “Binary Logging of Stored Programs” .

 

read-only选项：对所有的非临时表进行只读控制。但是有两种情况例外：

1. 对replication threads例外，以保证slave能够正常的进行replication。

2. 对于拥有super权限的用户，可以ignore这个选项。

SUPER 权限 ： 1. 可以有change master to, kill其他用户的线程的权限。

2. Purge binary logs 来删除binary log, set global来动态设置变量的权限。

3. 执行mysqladmin debug命令，开启或者关闭log，在read-only打开时执行update/insert操作。

4. 执行start slave, stop slave.

5. 当连接数已经达到max_connections的最大值时，也可以连接到server。

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

mysql master HA各种解决方案：

手动解决

mysql复制是异步或者半同步的。当master崩溃时，一些slave很有可能尚未接收到最新的relay log事件，这就可能导致slave之间可能处于不同的状态。手动解决一致性问题并不繁杂，但若不解决一致性问题，主从复制将无法启动。手动重启主从复制往往需要花费一小时的时间。

只有一个master并只挂一个slave

只有一个master和一个slave时，不会发生一些slave过时于某一slave的情况。当master崩溃时，只要使应用将所有流量发送到slave转成的新master上即可。故障切换很简单。

M(RW)
|                          –(master crash)–>             M(RW), promoted from S
S(R)

主(读写)
|                          –(master崩溃)–>               新主(读写), 由从机生格而来
从(读)

但是本节方案有严重的问题。

首先，无法水平扩展读流量。当在一个slave运行诸如备份、分析查询、脚本任务等重量级操作时可能带来性能问题。当这个唯一的slave宕机时，master需要处理slave的所有流量。

其次是可用性，当master宕机时，只剩新主机成为单一故障点。创建新slave需要作在线备份，将数据转储到新硬件并立即开启slave。这些操作通常需要花费几个小时的时间。一些关键应用不允许数据库成为单一故障点并持续几个小时的时间。在线备份数据库会造成额外的i/o负担，所以在使用高峰时期备份也是危险的。

第三个问题是缺乏扩展性。例如，如果想要在远程数据中心建立一个只读数据库，需要至少两个slave，一个位于本地数据中心，另一个slave位于远程数据中心。只有一个slave无法建立前述架构。

单一slave在许多场景中都无法满足要求。

 一个master一个候选master及多个slave

使用标题所述架构非常常见。在当前master宕机时，候选master具有较高优先级成为新的master。有些情况下候选master配置成只读master：譬如多master的配置。

 

M(RW)—–M2(R)                                            M(RW), promoted from M2
|                                                                           |
+—-+—-+                –(master crash)–>                  +-x–+–x-+
S(R) S2(R)                                                           S(?)      S(?)
(From which position should S restart replication?)

 

M(读写)—–M2(只读)                                            M(读写), 由 M2 升格成为新master
|                                                                           |
+—-+—-+                –(master 宕机)–>                   +-x–+–x-+
S(只读) S2(只读)                                                   S(?)      S(?)
(slave应该从哪一点开始复制？)

但是前述方案作为master的灾备方案不总是可行的。当master宕机时，其余salve可能没有接收到全部的relay log时间，因此还是需要解决salve之间的一致性问题。

既不能接受一致性问题，又想立即恢复服务怎么办：将候选master升格为新master，丢弃全部slave。然后通过在线备份新master建立新的slave。这种方案与上一节“单主单从”的问题一样，剩余的slave不能用于扩展读流量，也不能用于冗余。在恢复slave规模之前，将会产生故障单点问题。

这种架构使用非常广泛，但只有少数人能够全面了解前述的潜在问题：当master宕机时，其挂载的slave变得不一致；试图直接将slave挂到新master上开启复制也会失败。如果想要保证一致性，必须舍弃全部原有的slave。

还有一种架构：两个master，一个只读。每个master都至少挂一个slave。

M(RW)–M2(R)
|           |
S(R)    S2(R)

M(读写)  —  M2(只读)
|                |
S(只读)      S2(只读)

当当前master宕机时，至少有一个slave可以继续复制。但是这种方案使用不多，它最大的缺点是太复杂。三层复制（主主从，M->M2->S2）采用了这种架构，但是管理三层复制比较复杂。例如，如果中层的服务器（M2）宕机，第三层的slave（S2）无法继续复制。在许多情况下，需要重新配置M2和S2，因此这种架构至少需要4台机器（一台空白机用于出现问题时顶上）。

（待续）

 

一、权限说明

在配置mysql replication时，有一步骤：

其中两个权限的含义如下。

REPLICATION CLIENT：

enables the use of SHOW MASTER STATUS and SHOW SLAVE STATUS.

该权限用于查看replication的状态。

REPLICATION SLAVE：

The REPLICATION SLAVE privilege should be granted to accounts that are used by slave servers to connect to the current server as their master. Without this privilege, the slave cannot request updates that have been made to databases on the master server.

该权限用于slave机连接master并进行复制。

一般来说，我们会单独在主服务器创建一个专门用于Replication的账户。这个账户必须具有REPLICATION SLAVE权限，除此之外没有必要添加不必要的权限，保证该用户的职责单一。假定我们要建立的这个账户为repl,密码为repl,那么这一操作的命令如下：
mysql> GRANT REPLICATION SLAVE ON *.* TO ‘repl’@’192.168.0.%’ IDENTIFIED BY ‘repl’;
其中要特别说明一下192.168.0.%，这个配置是指明repl用户所在服务器，这里%是通配符，表示192.168.0.0-192.168.0.255的Server都可以以repl用户登陆主服务器。如果没有使用通配符，而访问的服务器又不在上述配制里，那么你将无法使用该账户从你的服务器replicate主服务器.

二、实践tips

在《Hight Performance MySql》一书中对用户权限的设置有所不同，作者建议在主机和从机上都配置repl账户，并同时赋予REPLICATION SLAVE和REPLICATION CLIENT权限，命令如下：
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@’192.168.0.%’ IDENTIFIED BY ‘repl’;
作者解释了这样做的好处：一方面使用同一账户对Replication进行监视管理会很方便，不必区分slave,master，另一方面，repl账户在slave和master上的配制是一样的，这样如果我们切换slave和master，账户不需要做任何改动。

参考：http://blog.csdn.net/bluishglc/article/details/5744303