MySQL主库将Binlog事件写入到Binlog文件中,此时主库只通知一下Dump线程发送这些新的Binlog,然后主库继续处理提交操作,不会保证这些Binlog传到任何一个从库节点上.
因为异步复制,主节点不关从节点是否收到Binlog,如果主crash掉了,此时主节点上已提交的事务可能并没有传到从库上,如果此时,强行将从节点提升为主节点,可能导致新的主节点上数据不完整.
半同步复制是介于全同步复制和全异步复制之间的一种,主库只需要等待至少一个从库节点收到并Flush Binlog到Relay log文件即可,主库不需要等待所有从库给主库反馈.（注意只要收到一个从库的反馈即可）
相对于异步复制,半同步复制提交了数据的安全性,同时它也造成了一定程序的延迟,这个延迟至少是一个TCP/IP往返时间,所以呢,半同步复制虽好在低延时的网络中使用.
XMind - Trial Version
半同步复制很大程度上取决于主从库之间的网络情况,往返时延RTT 越小决定了从库的实时性越好.通俗地说,主从库之间网络越快,从库越实时.
①.、首先,判断MySQL服务器是否支持动态增加插件:
主：
从：
以上的启动方式是在命令行操作,也可写在配置文件中.
如果没有重启,则默认还是异步复制,重启后,slave会在master上注册为半同步复制的slave角色.这时候,主的error.log中会打印如下信息：
查看半同步是否在运行
这两个变量常用来监控主从是否运行在半同步复制模式下.至此,MySQL半同步复制搭建完毕~
来做个实验,观察半同步状态参数的变化.
①.、在主库上insert一条记录,观察下变化；
Rpl_semi_sync_master_net_waits加1,说明刚才的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；
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 主从,就是建立两个完全一样的数据库,一个是主库,一个是从库, 主库对外提供读写的操作,从库对外提供读的操作 ,下面是一主一从模式：
大部分系统的访问模型是读多写少,读写请求量的差距可能达到几个数量级,所以我们可以通过一主多从的方式, 主库只负责写入和部分核心逻辑的查询,多个从库只负责查询,提升查询性能,降低主库压力.
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扩展
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
但是实测发现ubuntu默认安装的gearman版本过低,直接运行pecl install gearman会报错
configure: error: libgearman version 1.1.0or later required
所以呢Gearman + PHP扩展建议通过编译方式安装,这里为了简单说明,选择安装旧版本扩展：
Gearman + PHP实例
为了更容易理解后文Gearman的运行流程,这里不妨从一个最简单的Gearman实例来说明,比如要进行一个文件处理的操作,首先编写一个Gearman Client并命名为client.php：
php
$client =newGearmanClient();
$client-addServer();
$client-doBackground('writeLog','Log content');
echo '文件已经在后台操作';
运行这个文件,相当于模拟用户请求一个Web页面后,将处理结束的信息返回用户：
php client.php
查看一下Gearman的状况：
可以看到输出为
writeLog ? ? ? ?100.
说明已经在Gearman中建立了一个名为writeLog的任务,并且有1个任务在队列等待中.
任务名称
在等待队列中的任务
正在运行的任务
正在运行的Worker进程
可以使用watch进行实时监控：
然后我们需要编写一个Gearman Worker命名为worker.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
-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服务器的信息：
通过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
然后编写一个Gearman Worker：redis_worker.php
#!/usr/bin/env php?
$worker-addFunction('syncToRedis','syncToRedis');
$redis =newRedis();
$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的接收线程出了问题? 而主库没有任何的报错信息 .
bug 详情链接：?
我们来看看采用了select()多路复用io模型的ack_reciver 线程的代码：
（ulimit -n 命令可以修改nproc参数）.
貌似所有的疑问都揭开,但请继续.
Asynchronous?Replication?Automatic failover
其原理是在一条异步复制通道上配置多个可用复制源,当某个复制源不可用时（宕机、复制链路中断）,且 slave 的 IO 线程尝试重连无效,自动根据权重选择新的源继续同步.
在 master_retry_count 和 master_connect_retry 的设置上要考虑尝试重连多久才切换复制源.
配置 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 节点切换,异步复制也能切换到新的主节点.
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
注意：当主节点故障,一旦复制链路成功 failover 后,在新的复制链路没有故障时,如果原主节点恢复,是不会回切的.如果当前复制链路发生故障,会再次选择权重高的进行切换