OS运维 自动化

架构图

系统：CentOS6.4_X86_64
软件版本：Mysql-5.6.12,Keepalived-1.2.7
环境简介：
1.Master-A 192.168.1.168 (Mysql+Keepalived)
2.Master-B 192.168.1.169 (Mysql+Keepalived)
3.写入VIP 192.168.100 (168主，169从)
4.读取VIP 192.168.200 (169主，168从)
此处略过Mysql和Keepalived的安装过程，请读者自行查找相关的安装指导资料.

工作流程图

复制实现原理（适用于Mysql 5.5及之前的版本）：

MySQL支持单向,异步复制，复制过程中一个服务器充当主服务器，而另外一个或多个其它服务器充当从服务器。

MySQL复制基于主服务器在二进制日志中跟踪所有对数据库的更改(插入、更新、删除等等)，必须在主服务器上启用二进制日志。

MySQL使用3个线程来执行复制同步功能，其中两个线程(Sql线程和IO线程)在从服务器，另外一个线程(IO线程)在主服务器。

当从服务器发出start slave服务时，从服务器创建一个I/O线程，以连接主服务器并让它发送记录在其二进制日志中的语句。

主服务器创建Binlog Dump线程将二进制日志中的内容发送到从服务器。

从服务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中(中继日志),接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”。SQL线程读取中继日志并执行日志中包含的更新。在从服务器上，读取和执行更新语句被分成两个独立的任务。

当从服务器启动时，其I/O线程可以很快地从主服务器索取所有二进制日志内容，然后执行sql线程。

Mysql 5.6 特性

由于Mysql 5.6 引入了 GTID(Global Transaction ID)，保证 Slave 在复制的时候不会重复执行相同的事务操作；其次，是用全局事务 IDs 代替由文件名和物理偏移量组成的复制位点，定位 Slave 需要复制的 binlog 内容，在旧的 binlog 事件基础上新增两类事件

1.Previous_gtids_log_event 该事件之前的全局事务 ID 集合
2.Gtid_log_event 标记之后的事务对应的全局事务 ID

MySQL 5.6 的 binlog 文件中，每个事务的开始不是 “BEGIN” ，而是 Gtid_log_event 事件。

详解可以参考 https://gitsea.com/wp-content/uploads/2013/06/MySQL_Innovation_Day_Replication_HA.pdf

优点:
1.使用 GTIDs 作为主备复制的位点，在写 binlog 时用 Gtid_log_event 标记事务

2.主从复制不再基于master的binary logfile和logfile postition,从服务器连接到主服务器之后，把自己曾经获取到的GTID(Retrieved_Gtid_Set)发给主服务器，主服务器把从服务器缺少的GTID及对应的transactions发过去即可.

3.采用多个sql线程，每个sql线程处理不同的database，提高了并发性能，即使某database的某条语句暂时卡住，也不会影响到后续对其它的database进行操作.

http://www.mamicode.com/info-detail-247980.html

mysql高可用探究Lvs+Keepalived+Mysql单点写入读负载均衡主主同步高可用方案

Lvs+Keepalived+Mysql单点写入读负载均衡主主同步高可用方案

1.1  方案简介

Lvs+keepalived作为目前比较流行的高可用解决方案，lvs提供负载均衡，keepalived作为故障转移，提高系统的可用性。但是一般的mysql高可用为了实现mysql数据的一致性，一般都是采用单点写入，本方案采用keepalived中的sorry_server来实现写入数据库为单点的需求，读负载均衡通过lvs实现，读能自由的实现负载均衡和故障切换。本方案实现的功能是当网络有问题、mysql有问题、服务器宕机、keepalived服务停止后,服务器能自动跳转到备用机，当主服务器服务启动起来后会自动切换回来。

1.2  方案架构图

1.3  方案优缺点

优点：

ü  实现方便，高可用效率好，可以根据服务与系统的可用性多方面进行切换。

ü  可以将写VIP和读VIP分别进行设置，为读写分离做准备。

ü  扩展很方便。可以在后面添加多个从服务器，并做到负载均衡。

缺点：

ü  在启动或者恢复后会立即替换掉定义的sorry_server，因此如果要实现指定条件替换或者不替换需要通过其他方式实现，比如：临时更改mysql的端口等。

ü  安装配置比单写入稍微复杂，需要另外一个VIP。管理比单写入复杂。

ü  主切换后从需要手工切换。

ü  切换需要1s左右的时间。

http://www.tuicool.com/articles/7jeAf2j