温馨提示
关于主从复制的原理及其实现请参阅mysql主从复制
一、关于复制的相关问题
1、异步复制解决了那些问题
复制解决的基本问题是让一台服务器的数据和另外的服务器保持同步，可以位于不同的网络拓扑中，对整台服务器的特定的数据库，甚至特定的表进行复制。
mariadb或mysql复制大部分都是向后兼容的。这意味着版本较新的服务器可以是版本老的服务器的从服务器。复制通常不会大幅增加服务器的开销，它需要主服务器启用二进制日志。复制对扩展读取有好处，可以将读指向到到从服务器上.
2、有了异步为什么还要用半同步复制
MySQL5.5之前版本的MySQL Replication都是异步（asynchronous）的，主库在执行完一些事务后，是不会管备库的进度的。如果备库不幸落后，而更不幸的是主库此时又出现Crash（例如宕机），这时备库中的数据就是不完整的。简而言之，在主库发生故障的时候，我们无法使用备库来继续提供数据一致的服务了。Semisynchronous Replication则一定程度上保证提交的事务已经传给了至少一个备库。
3. 为什么不是完全同步
Semi_synchronous中，仅仅保证事务的已经传递到备库上，但是并不确保已经在备库上执行完成了。
此外，还有一种情况会导致主备数据不一致。在某个session中，主库上提交一个事务后，会等待事务传递给至少一个备库，如果在这个等待过程中主库Crash，那么也可能备库和主库不一致，这是很致命的。（在主库恢复后，可以通过参数Rpl_semi_sync_master_no_tx观察）
4. 如果主备之间连接出现故障，主库是否会一直等待？
如果主备网络故障或者备库挂了，主库在事务提交后等待10秒（rpl_semi_sync_master_timeout的默认值）后，就会继续。这时，主库就会变回原来的异步状态
二、半同步的实现过程
注：
1、之前的博文己经说过如何安装mariadb（与msyql编译或二进制通用格式安装方法一样），这里就直接上配置了。
2、如果要想实现半同步复制，先得配置主从复制。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝正式开始＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
系统版本：centos6.5
数据库：mariadb-10（通用二进制格式安装）
系统资源分配
master 端：
ip地址： 192.168.1.114
slave 端：
ip地址：192.168.1.109
半同步插件是由谷歌提供，具体位置/usr/local/mysql/lib/plugin/下，一个是master用的semisync_master.so，一个是slave用的semisync_slave.so
在master端上执行如下命令：
MariaDB [(none)]> install plugin rpl_semi_sync_master soname ‘semisync_master.so‘;
还要在/etc/my.cnf中打开semi_sync，将以下两条语句写入[mysqld]段中
或在数据库中直接执行如下命令
MariaDB [(none)]> set global rpl_semi_sync_master_enabled=1
重新启动服务
[root@bogon ~]# service mysqld restart MySQL server PID file could not be found! [FAILED] Starting MySQL [ OK ]
在slave端执行如下命令：
MariaDB [(none)]> install plugin rpl_semi_sync_slave soname ‘semisync_slave.so‘;
在/etc/my.cnf配置文件[mysqld]段中添加如下一条语句
rpl_semi_sync_slave_enabled=1
或在数据库中直接执行下面的语句
MariaDB [(none)]>set global rpl_semi_sync_slave_enabled=1
重新启动服务器
[root@bogon data]# service mysqld restart Shutting down MySQL.. [ OK ] Starting MySQL... [ OK ]
在master查看一下状态
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE ‘rpl_semi%‘; +--------------------------------------------+-------+ | Variable_name | Value | +--------------------------------------------+-------+ | Rpl_semi_sync_master_clients | 1 | | Rpl_semi_sync_master_net_avg_wait_time | 0 | | Rpl_semi_sync_master_net_wait_time | 0 | | Rpl_semi_sync_master_net_waits | 0 | | Rpl_semi_sync_master_no_times | 0 | | Rpl_semi_sync_master_no_tx | 0 | | Rpl_semi_sync_master_status | ON | | Rpl_semi_sync_master_timefunc_failures | 0 | | Rpl_semi_sync_master_tx_avg_wait_time | 0 | | Rpl_semi_sync_master_tx_wait_time | 0 | | Rpl_semi_sync_master_tx_waits | 0 | | Rpl_semi_sync_master_wait_pos_backtraverse | 0 | | Rpl_semi_sync_master_wait_sessions | 0 | | Rpl_semi_sync_master_yes_tx | 0 | +--------------------------------------------+-------+ 14 rows in set (0.00 sec)
注解：
Rpl_semi_sync_master_clients
记录支持半同步的slave的个数。
Rpl_semi_sync_master_net_avg_wait_time
master 等待slave 回复的平均等待时间。 单位毫秒.
Rpl_semi_sync_master_net_wait_time
master 总的等待时间。
Rpl_semi_sync_master_net_waits
master 等待slave 回复的的总的等待次数。
Rpl_semi_sync_master_no_times
master 关闭半同步复制的次数。
Rpl_semi_sync_master_no_tx
master 没有收到slave的回复而提交的次数，（应该可以理解为master 等待超时的次
数)
Rpl_semi_sync_master_status
标记master现在是否是半同步复制状态。
Rpl_semi_sync_master_tx_avg_wait_time
master 花在每个事务上的平均等待时间。
Rpl_semi_sync_master_tx_wait_time
master 总的等待次数。
Rpl_semi_sync_master_wait_sessions
当前有多少个session 因为slave 的回复而造成等待。
Rpl_semi_sync_master_yes_tx
master 成功接收到slave的回复的次数。
Rpl_semi_sync_slave_status
标记slave 是否在半同步状态。
slave
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE ‘rpl_semi%‘; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | Rpl_semi_sync_slave_status | ON | +----------------------------+-------+ 1 row in set (0.00 sec)
下面我们来测试一下
在maser中新创建一个库与一个表，向表中插入数据
MariaDB [(none)]> create database yy
-> ;
Query OK, 1 row affected (0.02 sec)
MariaDB [(none)]> use yy
Database changed
MariaDB [yy]> create table t1 (name char(20));
Query OK, 0 rows affected (0.55 sec)
MariaDB [yy]> insert into t1 value(‘tom‘);
Query OK, 1 row affected (0.08 sec)
现在模拟一下故障，看看会发生什么。
在slave中将slave停止
MariaDB [(none)]> stop slave io_thread; Query OK, 0 rows affected (0.00 sec) #在master中新建立一张表看看效果。 MariaDB [(none)]> create table yy.user1 (id int(10)); Query OK, 0 rows affected (10.19 sec)
这时我们再看一下master的状态
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE ‘rpl_semi%‘; +--------------------------------------------+-------+ | Variable_name | Value | +--------------------------------------------+-------+ | Rpl_semi_sync_master_clients | 1 | | Rpl_semi_sync_master_net_avg_wait_time | 1807 | | Rpl_semi_sync_master_net_wait_time | 1807 | | Rpl_semi_sync_master_net_waits | 1 | | Rpl_semi_sync_master_no_times | 1 | | Rpl_semi_sync_master_no_tx | 1 | | Rpl_semi_sync_master_status | OFF | | Rpl_semi_sync_master_timefunc_failures | 0 | | Rpl_semi_sync_master_tx_avg_wait_time | 0 | | Rpl_semi_sync_master_tx_wait_time | 0 | | Rpl_semi_sync_master_tx_waits | 0 | | Rpl_semi_sync_master_wait_pos_backtraverse | 0 | | Rpl_semi_sync_master_wait_sessions | 0 | | Rpl_semi_sync_master_yes_tx | 0 | +--------------------------------------------+-------+ 14 rows in set (0.00 sec)
再看一下slave的状态
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE ‘rpl_semi%‘; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | Rpl_semi_sync_slave_status | OFF | +----------------------------+-------+ 1 row in set (0.00 sec)
三、总结
当事务返回客户端成功后，则日志一定在至少两台主机上存在。
mariadb/mysql在加载并开启Semi-sync插件后，每一个事务需等待备库接收日志后才返回给客户端。如果做的是小事务，两台主机的延迟又较小，则Semi-sync可以实现在性能很小损失的情况下的零数据丢失。
完成单条事务增加了额外的等待延迟，延迟的大小取决于网络的好坏。
Semi-sync不是分布式事务，主库会在自己完成事务后，等待备库接收事务日志。
备库意外宕机时，主库会在某次等待超时后，关闭Semi-sync的特性，降级为普通的异步复制，这种情况比较简单。
主库意外宕机后，那么可能存在一些事务已经在主库Commit，但是还没有传给任何备库，这类"无根事务"都是没有返回给客户端的，所以发起事务的客户端并不知道这个事务是否已经完成。
这时，如果客户端不做切换，只是等意外宕机的主库恢复后，继续在主库进行操作，客户端会发现前面的"无根事务"都已经完成，可以继续进行后续的业务处理；
好了，到这里我们就配置完成了半同步复制。希望大家有所收获！
本文出自 “和风细雨” 博客，请务必保留此出处http://essun.blog.51cto.com/721033/1394807