MySQL 默认的复制就是异步的，主库再执行完客户端提交的事务后会立即将结果返回给客户端，并不关系从库是否已经接收和处理。
创新互联长期为近1000家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为武威企业提供专业的网站设计、成都网站制作，武威网站改版等技术服务。拥有10多年丰富建站经验和众多成功案例,为您定制开发。
MySQL主库将Binlog事件写入到Binlog文件中，此时主库只通知一下Dump线程发送这些新的Binlog，然后主库继续处理提交操作，不会保证这些Binlog传到任何一个从库节点上。
因为异步复制，主节点不关从节点是否收到Binlog，如果主crash掉了，此时主节点上已提交的事务可能并没有传到从库上，如果此时，强行将从节点提升为主节点，可能导致新的主节点上数据不完整。
全同步是指当主库接收到客户端的一个事务请求，所有的从库都执行了该事务才返回给客户端。
当主库收到客户端提交的事务后，所有的从库必须收到并且执行事务，然后主库才会执行后续操作。
因为要等待所有从库执行完事务，主库才将结果返回给客户端，所以全同步复制的性能必然受到严重影响，即完成一个事务的时间被拉长，性能降低。
半同步复制是介于全同步复制和全异步复制之间的一种，主库只需要等待至少一个从库节点收到并Flush Binlog到Relay log文件即可，主库不需要等待所有从库给主库反馈。（注意只要收到一个从库的反馈即可）
介于异步复制和全同步复制之间，主库再执行完客户端提交的食物后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。
相对于异步复制，半同步复制提交了数据的安全性，同时它也造成了一定程序的延迟，这个延迟至少是一个TCP/IP往返时间，因此，半同步复制虽好在低延时的网络中使用。
XMind - Trial Version
在MySQL5.5之前，MySQL 的复制是异步操作，主库和从库的数据之间存在一定的延迟，这样存在一个隐患:当在主库上写入一个事务并提交成功，而从库尚未得到主库推送的Binlog日志时，主库宕机了，例如主库可能因磁盘损坏、内存故障等造成主库上该事务Binlog丢失，此时从库就可能损失这个事务，从而造成主从不一致。
为了解决这个问题, MySQL5.5引人了半同步复制机制。
在MySQL 5.5之前的异步复制时，主库执行完 Commit提交操作后，在主库写入 Binlog日志后即可成功返回客户端，无需等待Binlog日志传送给从库，如图31-7所示。
而半同步复制时，为了保证主库上的每一个 Binlog 事务都能够被可靠的复制到从库上，主库在每次事务成功提交时，并不及时反馈给前端应用用户，而是等待其中一个从库也接收到 Binlog事务并成功写入中继日志后，主库才返回Commit操作成功给客户端。 半同步复制保证了事务成功提交后，至少有两份日志记录 ，一份在主库的 Binlog日志上，另一份在至少一个从库的中继日志Relay Log 上，从而更进一步保证了数据的完整性。半同步复制的大致流程如图31-8所示。
半同步复制模式下，假如在图31-8的步骤1、2、3中的任何一个步骤中主库宕机，则事务并未提交成功，从库上也没有收到事务对应的 Binlog日志，所以主从数据是一致的;
假如在步骤4传送 Binlog日志到从库时，从库宕机或者网络故障，导致 Binlog并没有及时地传送到从库上，此时主库上的事务会等待一段时间(时间长短由参数rpl_semi_sync_master_timeout设置的毫秒数决定)，如果 Binlog 在这段时间内都无法成功推送到从库上，则 MySQL自动调整复制为异步模式，事务正常返回提交结果给客户端。
半同步复制很大程度上取决于主从库之间的网络情况，往返时延RTT 越小决定了从库的实时性越好。通俗地说，主从库之间网络越快，从库越实时。
半同步模式是作为MySQL5.5的一个插件来实现的，主库和从库使用不同的插件。安装比较简单，在上一小节异步复制的环境上，安装半同步复制插件即可。
1、首先,判断MySQL服务器是否支持动态增加插件:
2、安装插件
3、可以查看到已安装的插件
4、在安装完插件后，半同步复制默认是关闭的，这时需设置参数来开启半同步
主：
从：
以上的启动方式是在命令行操作，也可写在配置文件中。
主：
从：
4、重启从上的IO线程
从：
如果没有重启，则默认还是异步复制，重启后，slave会在master上注册为半同步复制的slave角色。这时候，主的error.log中会打印如下信息：
查看半同步是否在运行
主：
从：
这两个变量常用来监控主从是否运行在半同步复制模式下。至此，MySQL半同步复制搭建完毕~
来做个实验，观察半同步状态参数的变化。
1、在主库上insert一条记录，观察下变化；
Rpl_semi_sync_master_net_waits加1，说明刚才的insert已经发送到从机并且主机还接收到从机的反馈响应；
2、我们将从机mysql停止，再次在主机上进行insert后查看状态
可以看到，主机进行insert阻塞了10秒才返回结果。Rpl_semi_sync_master_status变为OFF，Rpl_semi_sync_master_no_tx加1，说明这条insert没有同步到从机。后面再一次执行了insert立马返回了结果，说明此时已经降级为异步复制；Rpl_semi_sync_master_no_tx也是增加了1；
3、现在恢复启动从机，再次在主机上进行insert后查看状态
Rpl_semi_sync_master_status还是OFF，Rpl_semi_sync_master_no_tx又增加了1。说明从库重启并不会自动恢复为原来的半同步复制，需要手动操作：
主 SET GLOBAL rpl_semi_sync_master_enabled = 1;
从 SET GLOBAL rpl_semi_sync_slave_enabled = 1; STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
上面是从机重启后的变化，那么主到从之间的网络问题呢，我们可以利用防火墙来模拟。
对于全同步复制，当主库提交事务之后，所有的从库节点必须收到，APPLY并且提交这些事务，然后主库线程才能继续做后续操作。这里面有一个很明显的缺点就是，主库完成一个事务的时间被拉长，性能降低。
MySQL 主从一直是面试常客，里面的知识点虽然基础，但是能回答全的同学不多。
比如楼哥之前面试小米，就被问到过主从复制的原理，以及主从延迟的解决方案，因为回答的非常不错，给面试官留下非常好的印象。你之前面试，有遇到过哪些 MySQL 主从的问题呢？
所谓 MySQL 主从，就是建立两个完全一样的数据库，一个是主库，一个是从库， 主库对外提供读写的操作，从库对外提供读的操作 ，下面是一主一从模式：
对于数据库单机部署，在 4 核 8G 的机器上运行 MySQL 5.7 时，大概可以支撑 500 的 TPS 和 10000 的 QPS， 当遇到一些活动时，查询流量骤然，就需要进行主从分离。
大部分系统的访问模型是读多写少，读写请求量的差距可能达到几个数量级，所以我们可以通过一主多从的方式， 主库只负责写入和部分核心逻辑的查询，多个从库只负责查询，提升查询性能，降低主库压力。
MySQL 主从还能做到服务高可用，当主库宕机时，从库可以切成主库，保证服务的高可用，然后主库也可以做数据的容灾备份。
整体场景总结如下：
MySQL 的主从复制是依赖于 binlog 的，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上二进制日志文件。
主从复制就是将 binlog 中的数据从主库传输到从库上，一般这个过程是异步的，即主库上的操作不会等待 binlog 同步的完成。
详细流程如下：
当主库和从库数据同步时，突然中断怎么办？因为主库与从库之间维持了一个长链接，主库内部有一个线程，专门服务于从库的这个长链接的。
对于下面的情况，假如主库执行如下 SQL，其中 a 和 create_time 都是索引：
我们知道，数据选择了 a 索引和选择 create_time 索引，最后 limit 1 出来的数据一般是不一样的。
所以就会存在这种情况：在 binlog = statement 格式时，主库在执行这条 SQL 时，使用的是索引 a，而从库在执行这条 SQL 时，使用了索引 create_time，最后主从数据不一致了。
那么我们改如何解决呢？
可以把 binlog 格式修改为 row，row 格式的 binlog 日志记录的不是 SQL 原文，而是两个 event:Table_map 和 Delete_rows。
Table_map event 说明要操作的表，Delete_rows event用于定义要删除的行为，记录删除的具体行数。 row 格式的 binlog 记录的就是要删除的主键 ID 信息，因此不会出现主从不一致的问题。
但是如果 SQL 删除 10 万行数据，使用 row 格式就会很占空间的，10 万条数据都在 binlog 里面，写 binlog 的时候也很耗 IO。但是 statement 格式的 binlog 可能会导致数据不一致。
设计 MySQL 的大叔想了一个折中的方案，mixed 格式的 binlog，其实就是 row 和 statement 格式混合使用， 当 MySQL 判断可能数据不一致时，就用 row 格式，否则使用就用 statement 格式。
有时候我们遇到从数据库中获取不到信息的诡异问题时，会纠结于代码中是否有一些逻辑会把之前写入的内容删除，但是你又会发现，过了一段时间再去查询时又可以读到数据了，这基本上就是主从延迟在作怪。
主从延迟，其实就是“从库回放” 完成的时间，与 “主库写 binlog” 完成时间的差值， 会导致从库查询的数据，和主库的不一致 。
谈到 MySQL 数据库主从同步延迟原理，得从 MySQL 的主从复制原理说起：
总结一下主从延迟的主要原因 ：主从延迟主要是出现在 “relay log 回放” 这一步，当主库的 TPS 并发较高，产生的 DDL 数量超过从库一个 SQL 线程所能承受的范围，那么延时就产生了，当然还有就是可能与从库的大型 query 语句产生了锁等待。
我们一般会把从库落后的时间作为一个重点的数据库指标做监控和报警，正常的时间是在毫秒级别，一旦落后的时间达到了秒级别就需要告警了。
解决该问题的方法，除了缩短主从延迟的时间，还有一些其它的方法，基本原理都是尽量不查询从库。
具体解决方案如下：
在实际应用场景中，对于一些非常核心的场景，比如库存，支付订单等，需要直接查询从库，其它非核心场景，就不要去查主库了。
两台机器 A 和 B，A 为主库，负责读写，B 为从库，负责读数据。
如果 A 库发生故障，B 库成为主库负责读写，修复故障后，A 成为从库，主库 B 同步数据到从库 A。
一台主库多台从库，A 为主库，负责读写，B、C、D为从库，负责读数据。
如果 A 库发生故障，B 库成为主库负责读写，C、D负责读，修复故障后，A 也成为从库，主库 B 同步数据到从库 A。
对于变化频率非常快的数据来说，如果还选择传统的静态缓存方式（Memocached、File System等）展示数据，可能在缓存的存取上会有很大的开销，并不能很好的满足需要，而Redis这样基于内存的NoSQL数据库，就非常适合担任实时数据的容器。
但是往往又有数据可靠性的需求，采用MySQL作为数据存储，不会因为内存问题而引起数据丢失，同时也可以利用关系数据库的特性实现很多功能。
所以就会很自然的想到是否可以采用MySQL作为数据存储引擎，Redis则作为Cache。而这种需求目前还没有看到有特别成熟的解决方案或工具，因此采用Gearman+PHP+MySQL UDF的组合异步实现MySQL到Redis的数据复制。
MySQL到Redis数据复制方案
无论MySQL还是Redis，自身都带有数据同步的机制，比较常用的MySQL的Master/Slave模式，就是由Slave端分析Master的binlog来实现的，这样的数据复制其实还是一个异步过程，只不过当服务器都在同一内网时，异步的延迟几乎可以忽略。
那么理论上也可以用同样方式，分析MySQL的binlog文件并将数据插入Redis。但是这需要对binlog文件以及MySQL有非常深入的理解，同时由于binlog存在Statement/Row/Mixedlevel多种形式，分析binlog实现同步的工作量是非常大的。
因此这里选择了一种开发成本更加低廉的方式，借用已经比较成熟的MySQL UDF，将MySQL数据首先放入Gearman中，然后通过一个自己编写的PHP Gearman Worker，将数据同步到Redis。比分析binlog的方式增加了不少流程，但是实现成本更低，更容易操作。
Gearman的安装与使用
Gearman是一个支持分布式的任务分发框架。设计简洁，获得了非常广泛的支持。一个典型的Gearman应用包括以下这些部分：
Gearman Job Server：Gearman核心程序，需要编译安装并以守护进程形式运行在后台
Gearman Client：可以理解为任务的收件员，比如在后台执行一个发送邮件的任务，可以在程序中调用一个Gearman Client并传入邮件的信息，然后就可以将执行结果立即展示给用户，而任务本身会慢慢在后台运行。
Gearman Worker：任务的真正执行者，一般需要自己编写具体逻辑并通过守护进程方式运行，Gearman Worker接收到Gearman Client传递的任务内容后，会按顺序处理。
以前曾经介绍过类似的后台任务处理项目Resque。两者的设计其实非常接近，简单可以类比为：
Gearman Job Server：对应Resque的Redis部分
Gearman Client：对应Resque的Queue操作
Gearman Worker：对应Resque的Worker和Job
这里之所以选择Gearman而不是Resque是因为Gearman提供了比较好用的MySQL UDF，工作量更小。
安装Gearman及PHP Gearman扩展
以下均以Ubuntu12.04为例。
apt-get install gearman gearman-server libgearman-dev
检查Gearman的运行状况：
/etc/init.d/gearman-job-server status
* gearmand is running
说明Gearman已经安装成功。
PHP的Gearman扩展可以通过pecl直接安装
pecl install gearman
echo "extension=gearman.so"/etc/php5/conf.d/gearman.ini
service php5-fpm restart
但是实测发现ubuntu默认安装的gearman版本过低，直接运行pecl install gearman会报错
configure: error: libgearman version 1.1.0or later required
因此Gearman + PHP扩展建议通过编译方式安装，这里为了简单说明，选择安装旧版本扩展：
pecl install gearman-1.0.3
Gearman + PHP实例
为了更容易理解后文Gearman的运行流程，这里不妨从一个最简单的Gearman实例来说明，比如要进行一个文件处理的操作，首先编写一个Gearman Client并命名为client.php：
?php
$client =newGearmanClient();
$client-addServer();
$client-doBackground('writeLog','Log content');
echo '文件已经在后台操作';
运行这个文件，相当于模拟用户请求一个Web页面后，将处理结束的信息返回用户：
php client.php
查看一下Gearman的状况：
(echo status ; sleep 0.1)| netcat127.0.0.14730
可以看到输出为
writeLog 100.
说明已经在Gearman中建立了一个名为writeLog的任务，并且有1个任务在队列等待中。
而上面的4列分别代表当前的Gearman的运行状态：
任务名称
在等待队列中的任务
正在运行的任务
正在运行的Worker进程
可以使用watch进行实时监控：
watch -n 1"(echo status; sleep 0.1) | nc 127.0.0.1 4730"
然后我们需要编写一个Gearman Worker命名为worker.php：
?php
$worker =newGearmanWorker();
$worker-addServer();
$worker-addFunction('writeLog','writeLog');while($worker-work());function writeLog($job){
$log = $job-workload();file_put_contents(__DIR__ .'/gearman.log', $log ."\n", FILE_APPEND | LOCK_EX);}
Worker使用一个while死循环实现守护进程，运行
php worker.php
可以看到Gearman状态变为：
writeLog 001
同时查看同目录下gearman.log，内容应为从Client传入的值Log content。
通过MySQL UDF + Trigger同步数据到Gearman
MySQL要实现与外部程序互通的最好方式还是通过MySQL UDF（MySQL user defined functions）来实现。为了让MySQL能将数据传入Gearman，这里使用了lib_mysqludf_json和gearman-mysql-udf的组合。
安装lib_mysqludf_json
使用lib_mysqludf_json的原因是因为Gearman只接受字符串作为入口参数，可以通过lib_mysqludf_json将MySQL中的数据编码为JSON字符串
apt-get install libmysqlclient-dev
wget
unzip master.zip
cd lib_mysqludf_json-master/
rm lib_mysqludf_json.so
gcc $(mysql_config --cflags)-shared -fPIC -o lib_mysqludf_json.so lib_mysqludf_json.c
可以看到重新编译生成了 lib_mysqludf_json.so 文件，此时需要查看MySQL的插件安装路径：
mysql -u root -pPASSWORD --execute="show variables like '%plugin%';"+---------------+------------------------+|Variable_name|Value|+---------------+------------------------+| plugin_dir |/usr/lib/mysql/plugin/|+---------------+------------------------+
然后将 lib_mysqludf_json.so 文件复制到对应位置：
cp lib_mysqludf_json.so /usr/lib/mysql/plugin/
最后登入MySQL运行语句注册UDF函数：
CREATE FUNCTION json_object RETURNS STRING SONAME 'lib_mysqludf_json.so';
安装gearman-mysql-udf
方法几乎一样：
apt-get install libgearman-dev
wget
tar -xzf gearman-mysql-udf-0.6.tar.gz
cd gearman-mysql-udf-0.6./configure --with-mysql=/usr/bin/mysql_config
-libdir=/usr/lib/mysql/plugin/
make make install
登入MySQL运行语句注册UDF函数：
CREATE FUNCTION gman_do_background RETURNS STRING SONAME 'libgearman_mysql_udf.so';
CREATE FUNCTION gman_servers_set RETURNS STRING SONAME 'libgearman_mysql_udf.so';
最后指定Gearman服务器的信息：
SELECT gman_servers_set('127.0.0.1:4730');
通过MySQL触发器实现数据同步
最终同步哪些数据，同步的条件，还是需要根据实际情况决定，比如将数据表data的数据在每次更新时同步，那么编写Trigger如下：
DELIMITER $$
CREATE TRIGGER datatoredis AFTER UPDATE ON data
FOR EACH ROW BEGIN
SET @ret=gman_do_background('syncToRedis', json_object(NEW.id as`id`, NEW.volume as`volume`));END$$
DELIMITER ;
尝试在数据库中更新一条数据查看Gearman是否生效。
Gearman PHP Worker将MySQL数据异步复制到Redis
Redis作为时下当热的NoSQL缓存解决方案无需过多介绍，其安装及使用也非常简单：
apt-get install redis-server
pecl install redis
echo "extension=redis.so"/etc/php5/conf.d/redis.ini
然后编写一个Gearman Worker：redis_worker.php
#!/usr/bin/env php?
$worker =newGearmanWorker();
$worker-addServer();
$worker-addFunction('syncToRedis','syncToRedis');
$redis =newRedis();
$redis-connect('127.0.0.1',6379);while($worker-work());function syncToRedis($job){global $redis;
$workString = $job-workload();
$work = json_decode($workString);if(!isset($work-id)){returnfalse;}
$redis-set($work-id, $workString);}
最后需要将Worker在后台运行：
nohup php redis_worker.php
通过这种方式将MySQL数据复制到Redis，经测试单Worker基本可以瞬时完成。
研发的同事反馈，mysql的半同步怎么变异步了？开始觉得不足为奇，超时之后，自然变成异步了。但同步binlog的速度变得正常之后，就会自动变成同步了。但抱着严谨负责的态度，马上去检查了一
下数据库的日志跟半同步的状态。
看了一下从库的错误日志，被图片中所示的sem-sync slave net_flush() reply failed 刷屏。。。。。。，汗了，这又是哪一出？ 主库却没有任何日志。
虽然此时的主从同步的延迟时间是正常的，维持在0s的延迟，但此时同步状态却是异步的。
好奇怪呢？
查看一下代码，该Semi-sync slave net_flush() reply failed 信息来自函数
ReplSemiSyncSlave::slaveReply，函数如下
该错误发生的条件就是执行net_flush(net)函数，没有收到正常的返回，报错了，所以有上面的错误发生，该函数的作用是将从库收到的binlog file 跟binlog pos的信息发送给主库。
网络有问题？ 即使网路抖动性的问题，网路恢复之后应该正常才是。
为什么这个错误持续刷屏？ 而主从同步目前是正常的，只是由半同步变成了异步。
当我将slave重启之后，错误信息也很快就出现。
因为该函数是向主库发送同步binlog的确认信息的，也就是ack信息，难道是主库的ack的接收线程出了问题？ 而主库没有任何的报错信息 。
关键时刻，自己搞不定的时候，尝试找帮手。我将错误信息，发给oracle公司的mysql开发者宋老师，宋老师是负责replication模块的开发者，对replication相当熟悉，说我可能遇上一个mysql的Bug，让我查看一下Bug 79865 . 在此，非常感谢宋老师的热情的无偿援助。
bug 详情链接：
我们来看看采用了select()多路复用io模型的ack_reciver 线程的代码：
bug的关键点是因为 ret= select(max_fd+1, fds, NULL, NULL, tv); select()函数的入参max_fd+1有1024的限制，且这个限制无法通过修改nproc来突破？
（ulimit -n 命令可以修改nproc参数）。
貌似所有的疑问都揭开，但请继续。
作者采用的环境是5.7.15,同时，作者采用的操作系统是centOS 7, 根据上面 后半部分，Meiji Kimura 的描述信息，该bug在centos 6上复现了, 而在centOS7上没有复现。而作者正是采用了centos 7.
Asynchronous Replication Automatic failover
其原理是在一条异步复制通道上配置多个可用复制源，当某个复制源不可用时（宕机、复制链路中断），且 slave 的 IO 线程尝试重连无效，自动根据权重选择新的源继续同步。
准备一个 MGR 集群和单实例，模拟复制链路切换，当 primary 故障，slave 自动切换到其他节点。dbdeployer deploy replication --topology=group 8.0.22 --single-primarydbdeployer deploy single 8.0.22
2. 在从机上建立指向 MGR 主节点的复制通道，
change master to master_user='msandbox',master_password='msandbox', master_host='127.0.0.1',master_auto_position=1,source_connection_auto_failover=1,master_port=23223,master_retry_count=6,master_connect_retry=10 for channel 'mgr-single';
在 master_retry_count 和 master_connect_retry 的设置上要考虑尝试重连多久才切换复制源。
3. 在从机上配置 asynchronous connection auto failover
配置 asynchronous connection auto failover 的两个函数：
asynchronous_connection_failover_add_source(channel-name,host,port,network-namespace,weight)
asynchronous_connection_failover_delete_source(channel-name,host,port,network-namespace)
权重值大的被优先级选择，可以配合MGR的选举权重配置 asynchronous_connection_failover 的权重。当 MGR 节点切换，异步复制也能切换到新的主节点。
SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23223,null,100); SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23224,null,80); SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23225,null,50);start slave for channel 'mgr-single';
4. 检查异步复制通道是否启用 failover。
mysql SELECT CHANNEL_NAME, SOURCE_CONNECTION_AUTO_FAILOVER FROM performance_schema.replication_connection_configuration; +--------------+---------------------------------+| CHANNEL_NAME | SOURCE_CONNECTION_AUTO_FAILOVER |+--------------+---------------------------------+| mgr-single | 1 |+--------------+---------------------------------+1 row in set (0.01 sec
5. 把 MGR 的 primary 节点 kill 掉，这个从节点会在尝试几轮重连失败后自动切换到次权重的复制源，其日志中会输出切换信息。
注意：当主节点故障，一旦复制链路成功 failover 后，在新的复制链路没有故障时，如果原主节点恢复，是不会回切的。如果当前复制链路发生故障，会再次选择权重高的进行切换
