测试主从：
1. 用BSS代码去测试速度
2. 主从版本是否影响同步
3. 数据的正确性
切换方案：
1. 主从分布（确定19为主，13为从）
2. 具体如何切换对系统影响最小
3. 以后主从出问题的应急方案
配置文件etc/my.cnf配置主从参数的详细解析及注意：
server-id=1 #【必填】服务器ID，默认是1，一般取IP的最后一段
log-bin=mysql-bin #【主必开启项，从可忽略】
binlog_format=mixed #【复制类型】
①、基于语句的复制：在主服务器执行的SQL语句，在从也执行相同的语句。MySQL默认采用语句复制，效率比较高。
②、基于行的复制，把改变的内容复制过去，而不是把命令在从执行一遍（5.0开始支持）
③、混合类型的复制：默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行复制
【搜索引擎结果：从服务器的MySQL版本需高于主服务器版本】
1. BSS代码测试速度结果如下：
------------------------------------------------------------------------------------------------------------------
本地环境 MySQL 5.5.28 - MySQL Community Server（GPL）
服务器19环境 MySQL 5.5.33
访问连接：http://192.168.5.166/box/index.php?namespace=sales&controller=order&action=outlist
响应时间：
19： 3.5482 (secs) （平均翻页时间3.8左右）
本地： 3.4086 (secs)（平均翻页时间017--0.5左右）
------------------------------------------------------------------------------------------------------------------
重新配置19为5.1的MySQL环境测试（19为slave，虚机167为master）
show slave status\G; //显示正常连接上，数据同步正常（单向）
授权本地环境代码166：
访问连接：http://192.168.5.166/box/index.php?namespace=sales&controller=order&action=outlist
19：3.9950 (secs)（平均翻页时间3.5左右）
配置文件设置成跟13参数一样，本地166环境代码访问速度明显提升，翻页速度平均响应时间为0.2左右
【实践测试证明】：
当slave的MySQL的版本低于master的版本时不影响同步数据，主从服务器数据和连接正常（单双向都测试过没有问题）
故MySQL的版本影响应该不大（5.1和5.5版的对比）
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2. 模拟应急实现主从切换（主宕机，切换从，主修复，切换回主）
模拟情景：主宕机
show processlist; #看到Slave has read all relay log;表明已经更新完主服务器的数据数据
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
①（最笨方法实现）单向切换：
flush tables with read lock #停止从数据库的数据更新和插入，然后打包复制会主服务器
tar -cvf bss_box.tar bss_box/
scp bss_box.tar root@192.168.5.167:/usr/local/mysql/data
######################################
scp命令用法：
①本地复制到远程（如上所示）；
②远程复制到本地：
scp root@192.168.5.167:/usr/local/mysql/data/bss_box.tar /soft/
######################################
mv bss_box bss_box_old #重命名旧的数据库
tar xf bss_box.tar #解压从数据复制过来的数据
show master status; #记录log_file文件和位置
重新设置从数据库
unlock tables;
stop slave;
change master to master_host='192.168.5.167',master_user='backup',master_password='backup',master_log_file='mysql-bin.000001',master_log_pos=107;
切换主服务器数据库回程序配置
【备注：此种方法在主宕机情况下，可以很快的切换从做为应急数据库；单在主修复后，需要切换回来过程会影响系统使用】
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
②、双向主从切换：
主从配置参数一样，操作步骤参考《MySQL主从功能配置》
测试主从宕机，恢复即可使用，无需再设置什么，只需切换ip且保证日志文件和中继文件对应得上即可，对系统影响最小【注意宕机时，数据库数据问题】
宕机时，在备份服务器show processlist查看备份的端的slave是否已经Slave has read all relay log;
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
综上选择方案②
日志清理问题（设置expire_logs_days日志有效期）
http://wangwei007.blog.51cto.com/68019/1123088
3. 主从异常实际案例及解决方法[http://www.3lian.com/edu/2014/01-23/126344.html]
*
主从同步失败，如何快速同步
[尝试执行方案一]：
①、查看报错信息记录同步出错节点位置和文件；
手动尝试：change master to master_host='192.168.5.13',master_user='backup',master_password='vYYMd9jtbLZ7e3Lq',master_log_file='mysql-bin.000001',master_log_pos=107;
如果问题依旧执行下一步，
②、查看该节点位置是否存在：
mysqlbinlog --start-position=xxx mysql-bin.000001
查找最后节点位置，指定回去即可
【参考：http://blog.sina.com.cn/s/blog_002f90e10100o60b.html 】
如果以上步骤都未能修复，则只能执行③来修复了....
③、主服务器发生SQL执行错误：is marked as crashed and should be repaired 导致从服务器数据复制失败
[修复]：
flush tables with read lock;
tar cvf bss_box.tar bss_box/
scp root@192.168.5.13:/home/mysql/data/bss_box.tar .
*
主从复制，中继日志不断增长，设置中继日志自动清除
vi配置文件my.cnf，在mysqld下添加
relay_log_purge=1（自动清除中继日志打开）
重启mysql，这样SQL Thread每执行完一个events时才会判断该relay-log是否需要，已经不再需要则自动删除