这篇文章接前篇继续介绍一下问题的背景：什么是Group Commit，现在的官方版本Group Commit做到了什么程度？

MySQL/InnoDB在做事务的时候使用的日志先行（Write-ahead logging）的方式保证事务的快速和持久，所以每次事务完成都要求日志必须持久化到磁盘，在Linux上对应的操作就是“write and fsync”，write速度是很快的，一般对应的写Page Cache，而fsync则要求文件系统把对应文件的哦Page Cache必须持久化到磁盘上，而对于传统磁盘一次写操作大约需要1~3ms（不说BBU），这意味着对于传统磁盘1秒钟最多最多做333～1000个事务，这是不理想的，对硬件的利用率（吞吐量）也是非常低。

所以，这里就有了Group操作的概念，即当好几个线程都要fsync同一个日志文件时，我们将这些fsync合并到一次来做。简单举例：我们让系统每2ms做一次fsync，这样如果这2ms内有100个线程都需要做fsync，那就赚到了，原本100个fsync都独立来做那耗时会非常多的。

你肯定会说，难道这不是很简单的想法吗？是的，这就是原本是很简单、也很自然的想法。

但对MySQL来说却变成了一种奢求（看看这个Bug讨论）。

MySQL是不是太弱了，这么简单的事情都搞不定？不是的。

MySQL从开源到现在，成功的一个非常重要的原因，就是MySQL的插件式架构。如果MySQL只是MyISAM估计不会有现在的流行程度，插件式的架构让诸如Heikki Tuuri有了发挥空间，在InnoDB和MySQL一起时，MySQL才能算是一个真正的DBMS。再到后来，有Infobright、 FEDERATED、PBXT等等。

插件式的架构给MySQL带来了活力，做出牺牲便是在上层(MySQL)和下层(存储引擎)交互时带来的额外消耗，有时甚至上层和下层需要做一些重复工作。无法做Group Commit就是这其中的牺牲之一。

InnoDB在一次事务中，有两次fsync，分别是prepare阶段和commit阶段，对于这两次操作InnoDB都是实现了Group操作的。

如果你设置了binlog_sync=1，则又多了一次fsync操作（参考MYSQL_BIN_LOG::flush_and_sync），这次操作在innobase_xa_prepare和innodb_commit之间：

binlog_prepare (do nothing)
innodb_prepare
...
binlog_commit
innobase_commit

这次fsync，在MySQL中一直都无法做Group。所以，一直以来当innodb_flush_log_at_trx_commit和binlog_sync都等于1的时候，MySQL的性能就非常、非常糟糕。原因是为了保证InnoDB内部Commit的顺序和MySQL日志的顺序一致（参考）。

难道没人去解决这个问题吗？不是的。有很多人已经做出了努力，直到Kristian Nielsen@MariaDB提出了理论和实际上的最优解决方案。

Mark Callaghan@Facebook关于Group Commit做的工作：FB的基本实现 | FB的问题和改进 | 性能 | 对比MariaDB的实现(对比的结果是MariaDB完胜，无论是方案架构还是性能)

Facebooke可以说是通过一个Trick快速实现了Group Commit。而Kristian Nielsen@MariaDB这是从架构上根本的解决了这个问题。

MariaDB关于Group Commit架构和实现： WL116 | WL132 | WL164

后面还有很多值得写的，我希望自己能够一直写完这个系列。

主要有两个功能：

(1) 尽可能快的从一个非常大的mysqldump文件的分离出某个单表的备份文件

(2) 可以帮你把一个大的mysqldump文件，切割成非常小的单表备份文件（可继续做并行恢复）

(1) 如果把MySQL中某一个表数据弄丢了，需要从很大的mysqldump备份文件中恢复这个表

(2) 如果你想并行恢复整个mysqldump备份文件时，这个脚本可以帮你把大文件切割成多个小的单表备份文件，然后就可以方便并行恢复多个文件了

这里以实例的方式介绍如何使用该脚本：

(1) 从backup.sql文件中获取表process的备份：

tbdba-restore-mysqldump.pl -t process -f backup.sql

(2) 从backup.sql文件中获取数据库monitor中的表process的备份：

tbdba-restore-mysqldump.pl -t process -s monitor -f backup.sql

(3) 从backup.sql文件中获取多个表的备份文件（例如表process、users）：

tbdba-restore-mysqldump.pl -t process,user -s monitor -f backup.sql

(4) 直接接收来自管道的输出（如果你的mysqldump备份是压缩后，则可以使用）：

gunzip -c backup.sql.gz|tbdba-restore-mysqldump.pl -t process,user -s monitor

(5) 从backup.sql文件中获取数据库monitor下所有表的备份文件：

gunzip -c backup.sql.gz|tbdba-restore-mysqldump.pl -s monitor

(6) 从backup.sql文件中获取所有数据库下所有表的备份文件：

gunzip -c backup.sql.gz|tbdba-restore-mysqldump.pl --all-tables

(7) 使用-d参数，则可以看到切割的过程中的更多信息：

date && gunzip -c /backdir/backup.sql.gz|tbdba-restore-mysqldump.pl -d -a && date

(1) 如果指定了-s（获取某个数据库中的备份）参数，则脚本在成功截取需要恢复的表后就会立刻退出，所以如果你要恢复的表恰好在备份文件的比较靠前的位置时，该脚本的速度会非常快。

一个实际工作例子：

$ls -lh backup.sql.gz
-rw-r--r-- 1 mysql dba 14G Nov 21 04:49 backup.sql.gz
$date && gunzip -c backup.sql.gz|./tbdba-restore-mysqldump.pl -s monitor_general -t monitor_host_info && date
Fri Nov 25 14:35:06 CST 2011
Fri Nov 25 14:46:49 CST 2011
(the unzip of backup.sql.gz is 88G)

如果要全量恢复的话，根据经验值：88GB的sql文件完全恢复约需要400分钟（经验值）。

(2) 为了让每个独立的单表备份文件能够准确恢复，脚本做了两个额外的处理工作：在每个单表备份前加上'use db'，让该表能够恢复到正确的数据库；为了让单表恢复时字符集不出错误，脚本在某个单表备份前加上了对应的SET NAMES utf8、SET TIME_ZONE等命令。

Extract a Single Table from a mysqldump File：这篇文章提到了三个办法，分别是：perl脚本（我这里的做法基本“雷同”），awk解析后切割，先恢复到临时库(对大文件这个不现实...)。对比了我们的Perl脚本，这里做了几个改进：可以同时解析出多个表；完成目标表的切割后，则立刻退出，不再扫描剩余部分；会把mysqldump头部输出放到每一个切割文件中，方便各种字符集的恢复；

Restore a Single Table From mysqldump：这篇文章介绍如何用Sed来完成这个工作。

MySQL - Restoring a single table from nightly backup ：这位朋友则，想出一个“更损”的招：只给恢复用户赋予需要恢复的表的权限，然后用--force参数恢复整个mysqldump文件。

On restoring a single table from mysqldump：这篇文章则对比了使用grep sed 和“权限控制”三种方法的速度。

最后，如果不喜欢mysqldump这种一股脑的备份方式，可以考虑试用mydumper。

OK，That's all.

广告：我们寻找靠谱的人 | 感谢作者

在MySQL Replication结构中，备库端初次通过CHANGE MASTER TO完成Replication配置，再使用start slave命令开始复制。更细致的，备库通过IO Thread向主库发起读取binlog的请求（COM_BINLOG_DUMP命令），主库收到COM_BINLOG_DUMP请求后，使用单独线程（dump thread）不断向备库IO Thread发送Binlog。示意图(大图)：

在主库端一旦有新的日志产生后，立刻会发送一次广播，dump线程在收到广播后，则会读取二进制日志并通过网络向备库传输日志，所以这是一个主库向备库不断推送的过程；

新日志在产生后，只需一次广播和网络就会立刻（<1ms）向发送到备库，如果主备之间网络较好的话（例如RTT<1ms），备库端的日志也就小于2ms了。所以，一般的（依赖于RTT），备库的实时性都非常好。

参考：

1. MySQL Replication Manual

2. 图解"How MySQL Replication Works"

Have fun!

广告：我们寻找靠谱的人 | 感谢作者

Semi-sync主库在一定时间内（可配置的超时时间），如果没有收到备库的响应，则会超时从而降级为普通的replication复制。如果超时发生，有时需要查清什么原因导致备库没有及时响应，一方面可以从备库的日志着手，另一方面，如果需要更细致的信息则需要从备库端的网络包查找原因。这里介绍如何分析一个Semi-sync备库响应主库的数据包。

概述：先使用tcpdump抓取正确（主要是src和dst都正确）的数据包；然后借助wireshark玻璃TCP/IP等层的头信息，仅保留发送的MySQL数据包；再分析MySQL Semi-sync Slave响应的协议。

通过如下tcpdump抓取主机的网络包：

nohup tcpdump -n -nn -tttt -i bond0 -s 65535 'port 3306 and ((dst host master.host and src host slave.host and len &lt 100) or (dst host slave.host and src host master.host))' -w tcpdump.ret -C 50 &

参数简单说明：

-n  表示ip不要转换为主机名
-nn表示端口号，不要转为为服务名（例如3306会被转换为mysql）
-tttt 打印出完成的格式化的时间戳
-C 50 表示抓取的结果放到文件中，文件大小不超过50MB

Semi-sync备库响应主库包，一般大小整个包大小约95字节。找到该网络包如下：

完整网络包内容：

0000  00 24 e8 57 76 5e 00 1d  70 82 ca c0 08 00 45 00   .$.Wv^.. p.....E.
0010  00 51 a6 e2 40 00 3e 06  89 34 ac 13 46 44 ac 17   .Q..@.>. .4..FD..
0020  6e 21 b3 35 0c ea b2 2d  26 2a da 46 3c df 80 18   n!.5...- &*.F<...
0030  04 82 35 ef 00 00 01 01  08 0a 5a a2 7f cd 50 43   ..5..... ..Z...PC
0040  c1 5b 19 00 00 00 ef 38  40 01 00 00 00 00 00 6d   .[.....8 @......m
0050  79 73 71 6c 2d 62 69 6e  2e 30 30 31 35 31 36      ysql-bin .001516

剥去TCP/IP等层（使用wireshark就可以了），剩下MySQL 包如下：

0040        19 00 00 00 ef 38  40 01 00 00 00 00 00 6d   .[.....8 @......m
0050  79 73 71 6c 2d 62 69 6e  2e 30 30 31 35 31 36      ysql-bin .001516

更具Semi-sync备库响应源码分析如下：

+============================+
| packetlength      0 : 4    | 对应的：19 00 00 00 表示包数据长度为0x19=25字节
+----------------------------+
| magic_num         4 : 1    | 对应的：ef 这是一个kPacketMagicNum，表示这是一个Semi-sync slave响应
+----------------------------+
| binlog_pos        5 : 4    | 对应的：38  40 01 00 Binlog Pos:0x14038 = 81976
+----------------------------+
| event_length      9 : 20   | 对应的：00 00 00 00 6d 79 73 71 6c .... 31 36 （mysql-bin.001516）
+----------------------------+

可以看出，改网络包，响应主库端的mysql-bin.001516中的偏移为81976的事务。

通过tcpdump的网络包，我们可以看到毫秒（甚至微秒）级别数据包的传送情况。依据此，通常可以精确分析出Semi-sync在何时、何处出现超时。然后，可以继续分析为何出现超时。

That's all... 这篇枯燥吧，哈哈

广告：我们寻找靠谱的人 | 感谢作者

Percona在提供了tcprstat工具统计RT时间之后，很快就在Percona Server中集成了响应时间统计的功能。这里介绍一下该功能，各位看官如果在犹豫选择Percona Server还是MySQL Community Server，这里给Percona Server加一个筹码。

"响应时间"（Response time，后面简称RT）在数据库应用中，特别是OLTP的场景，可以说非常重要，不过，MySQL官方版本中一直没有加上这个统计功能。最早，社区开始尝试tcmdump+perl脚本的方式查看RT，后来告警一点用tcpdump+mk-query-digest，再后来Ignacio Nin和Baron Schwartz完成了tcprstat。

在Percona的5.1.53和5.5.8版本，开始将RT的统计内置到MySQL Server端。

这个是功能默认是关闭的，可以通过设置参数query_response_time_stats=1打开这个功能，这是一个动态参数，所以在服务器上可以很方便的打开或者关闭这个功能。可以通过命令SHOW QUERY_RESPONSE_TIME查看响应时间统计。

SHOW QUERY_RESPONSE_TIME;
+----------------+---+----------------+
|                |   |                |
+----------------+---+----------------+
|       0.000001 | 0 |       0.000000 |
|       0.000010 | 0 |       0.000000 |
|       0.000100 | 0 |       0.000000 |
|       0.001000 | 0 |       0.000000 |
......
|  1000000.00000 | 0 |       0.000000 |
| TOO LONG       | 0 | TOO LONG       |
+----------------+---+----------------+

set global query_response_time_stats=1;
Query OK, 0 rows affected (0.00 sec)

08:23:13>SHOW QUERY_RESPONSE_TIME;
+----------------+-------+----------------+
|                |       |                |
+----------------+-------+----------------+
|       0.000001 |  7982 |       0.000000 |
|       0.000010 | 13927 |       0.014511 |
|       0.000100 | 43811 |       1.553811 |
|       0.001000 |    29 |       0.007936 |
|       0.010000 |     1 |       0.001711 |
|       0.100000 |     0 |       0.000000 |

这里可以看到，响应时间小于0.000001秒的SQL有7982个，0.000001 < RT < 0.000010有13927个， 0.000010 < RT < 0.000100有43811 ...... 。这样整个系统的响应时间就清晰了。

除了用命令SHOW QUERY_RESPONSE_TIME，还可以通过INFORMATION_SCHEMA里面的表QUERY_RESPONSE_TIME来查看MySQL的响应时间。

08:25:16>SELECT * from INFORMATION_SCHEMA.QUERY_RESPONSE_TIME;
+----------------+--------+----------------+
| time           | count  | total          |
+----------------+--------+----------------+
|       0.000001 |  33824 |       0.000000 |
|       0.000010 |  59222 |       0.060457 |
|       0.000100 | 186003 |       6.659908 |
|       0.001000 |    117 |       0.025163 |
|       0.010000 |      8 |       0.014534 |

使用INFORMATION_SCHEMA.QUERY_RESPONSE_TIME，就可以稍微定制一下输出结果了：

SELECT time, CONCAT(ROUND(100*count/query_count,2),"%") as percent,count
FROM(
    SELECT
    	c.count,
    	c.time,
    	(
    	    SELECT SUM(a.count)
    	    FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as a
    	    WHERE a.count != 0
    	) as query_count
    FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as c
    WHERE c.count > 0
) d;
+----------------+---------+--------+
| time           | percent | count  |
+----------------+---------+--------+
|       0.000001 | 12.64%  |  81557 |
|       0.000010 | 20.69%  | 133440 |
|       0.000100 | 66.62%  | 429705 |
|       0.001000 | 0.05%   |    339 |
|       0.010000 | 0.00%   |     10 |
|    1000.000000 | 0.00%   |      1 |
+----------------+---------+--------+

默认的时间区间是：

(0; 10 ^ -6], (10 ^ -6; 10 ^ -5], (10 ^ -5; 10 ^ -4], ..., (10 ^ -1; 10 ^1], (10^1; 10^2]...(10^

你可以通过修改参数query_response_time_range_base来缩小时间区间，默认该参数是10，时间区间如上。

例如我们修个set global query_response_time_range_base=2; 则区间如下：

(0; 2 ^ -19], (2 ^ -19; 2 ^ -18], (2 ^ -18; 2 ^ -17], ..., (2 ^ -1; 2 ^1], (2 ^ 1; 2 ^ 2]...(2 ^

第一个区间总是最接近0.000001区间开始(2^19次方最接近)；最后一个区间是到最接近且小于10000000处结束。

具体的：

在备库上，只有打开了参数log_slow_slave_statements(这个参数也是Percona Server上特有的)时，slave sql线程的SQL才会被统计。

启动变量have_response_time_distribution，不能配置，该参数只表示该Server是否具有上述的RT统计功能。

设置了query_response_time_range_base，必须flush QUERY_RESPONSE_TIME后才生效。这里flush做两件事情，使得QUERY_RESPONSE_TIME生效，另外清空之前的统计结果。

累了，听首歌，扭扭脖子吧:)

广告：我们寻找靠谱的人 | 感谢作者

参考文献：

1. Introducing tcprstat, a TCP response time tool

2. The tcprstat User's Manual

3. Using Tcpdump for MySQL query logging

4. How to use tcpdump on very busy hosts

5. Take a look at mk-query-digest

6. Implementation Details: Response Time Distribution

7. Percona Software Documentation :Response Time Distribution

【附录】

既然上面读取INFORMATION_SCHEMA的SQL已经有些复杂了，那就不怕再复杂一些：

SELECT
    case TRIM(time)
    	when '0.000001' then '<  1us'
    	when '0.000010' then '< 10us'
    	when '0.000100' then '<100us'
    	when '0.001000' then '<  1ms'
    	when '0.010000' then '< 10ms'
    	when '0.100000' then '<100ms'
    	when '1.000000' then '<   1s'
    	when '10.000000' then '<  10s'
    	when '100.000000' then '<100s'
    	else '>100s'
    END as `RT area`,
    CONCAT(ROUND(100*count/query_count,2),"%") as percent,
    count
FROM(
    SELECT
    	c.count,
    	c.time,
    	(
    	    SELECT SUM(a.count)
    	    FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as a
    	    WHERE a.count != 0
    	) as query_count
    FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as c
    WHERE c.count > 0
) d;
+---------+---------+--------+
| RT area | percent | count  |
+---------+---------+--------+
| < 10us  | 41.92%  | 404409 |
| <100us  | 21.34%  | 205881 |
| <  1ms  | 35.20%  | 339574 |
| < 10ms  | 1.30%   |  12586 |
| <100ms  | 0.18%   |   1736 |
| <   1s  | 0.02%   |    160 |
| <  10s  | 0.04%   |    340 |
+---------+---------+--------+

如果还不了解Semi-sync可以阅读（Manual | 概述）

当事务返回客户端成功后，则日志一定在至少两台主机上存在。

MySQL在加载并开启Semi-sync插件后，每一个事务需等待备库接收日志后才返回给客户端。如果做的是小事务，两台主机的延迟又较小，则Semi-sync可以实现在性能很小损失的情况下的零数据丢失。

完成单条事务增加了额外的等待延迟，延迟的大小取决于网络的好坏。

Semi-sync不是分布式事务，主库会在自己完成事务后，等待备库接收事务日志。

备库Crash时，主库会在某次等待超时后，关闭Semi-sync的特性，降级为普通的异步复制，这种情况比较简单。

主库Crash后，那么可能存在一些事务已经在主库Commit，但是还没有传给任何备库，我们姑且称这类事务为"墙头事务"。"墙头事务"都是没有返回给客户端的，所以发起事务的客户端并不知道这个事务是否已经完成。

这时，如果客户端不做切换，只是等Crash的主库恢复后，继续在主库进行操作，客户端会发现前面的"墙头事务"都已经完成，可以继续进行后续的业务处理；另一种情况，如果客户端Failover到备库上，客户端会发现前面的“墙头事务”都没有成功，则需要重新做这些事务，然后继续进行后续的业务处理。

可以做多个备库，任何一个备库接收完成日志后，主库就可以返回给客户端了。

网络传输在并发线程较多时，一次可能传输很多日志，事务的平均延迟会降低。

"墙头事务"在墙头上的时候，是可以被读取的，但是这些事务在上面Failover的场景下，是被认为没有完成的。

累了，听首歌，伸个懒腰吧:)

广告：我们寻找靠谱的人 | 感谢作者

Semi-sync最早是由Google实现的一个补丁，代码主要由Mark Callaghan、Wei Li（@Google）等人贡献。Google原本是将需求提给Hekki的，但是后来等不及就自己实现了......。(现在Mark Callaghan已跳到Facebook，除了Google，他曾经还在Informix、Oracle工作过)

在5.5之后由MySQL Replication Team按照Plugin的方式将代码移植过来，并将Semi-sync独立成MySQL的一个插件，主要代码移植者是Zhenxing He（参考）。

在两台主机上安装好MySQL5.5，编译好的插件在目录CMAKE_INSTALL_PREFIX/lib/plugin下（默认是/usr/local/mysql/lib/plugin）。例如这里编译是指定CMAKE_INSTALL_PREFIX为/home/mysql/mysql，则有：

在主库初次启动时，执行如下语句加载semisync_master插件：

备库上则加载semisync_slave插件：

在初次加载插件后，MySQL会将该插件记录到系统表mysql.plugin中，下次启动时系统则会自动加载该插件了，无需再次执行上面的命令。

另外，主备库的配置文件my.cnf还需要新增如下记录来打开semi-sync。主库上，新增如下参数：

备库上新增：

那么主备在启动后，且slave线程开始dump主库的日志后，Semi-sync Replication就会开启，上面的配置(rpl_semi_sync_master_timeout=1000)表示主库在某次事务中，如果等待时间超过1000毫秒，那么则降级为普通模式，不再等待备库。如果主库再次探测到，备库恢复了，则会自动再次回到Semi-sync状态。

Semi-sync的配置参数不多，按照上面配置就可以了，其他少数几个参数默认即可。

主库上的其他参数：

mysql> show variables like "%rpl_semi%";
+------------------------------------+-------+
| Variable_name                      | Value |
+------------------------------------+-------+
| rpl_semi_sync_master_enabled       | ON    |
| rpl_semi_sync_master_timeout       | 1000  |
| rpl_semi_sync_master_trace_level   | 32    |
| rpl_semi_sync_master_wait_no_slave | ON    |
+------------------------------------+-------+

备库上有：

mysql> show variables like "%rpl_semi%";
+------------------------------------+-------+
| Variable_name                      | Value |
+------------------------------------+-------+
| rpl_semi_sync_master_wait_no_slave | ON    |
| rpl_semi_sync_slave_enabled        | ON    |
| rpl_semi_sync_slave_trace_level    | 32    |
+------------------------------------+-------+

rpl_semi_sync_master_trace_level和rpl_semi_sync_slave_trace_level是可以组合（求或）的参数，可以是下面值的组合：

1 = general level (for example, time function failures)
16 = detail level (more verbose information)
32 = net wait level (more information about network waits)
64 = function level (information about function entry and exit)

备库上很简单，只有一个状态值，查看备库是否开启了Semi-sync功能：

show status like "%rpl_semi%";
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Rpl_semi_sync_slave_status | ON    |
+----------------------------+-------+

主库需要关注的状态值则比较多

mysql> show status like "%rpl_semi%";
+--------------------------------------------+---------------+
| Variable_name                              | Value         |
+--------------------------------------------+---------------+
| Rpl_semi_sync_master_clients               | 1             |# 有多少个Semi-sync的备库
| Rpl_semi_sync_master_net_avg_wait_time     | 732           |# 事务提交后，等待备库响应的平均时间
| Rpl_semi_sync_master_net_wait_time         | 1042785285    |# 等待网络响应的总次数
| Rpl_semi_sync_master_net_waits             | 1423323       |# 总的网络等待时间
| Rpl_semi_sync_master_no_times              | 0             |# 一共有几次从Semi-sync跌回普通状态
| Rpl_semi_sync_master_no_tx                 | 0             |# 备库未及时响应的事务数
| Rpl_semi_sync_master_status                | ON            |# 主库上Semi-sync是否正常开启
| Rpl_semi_sync_master_timefunc_failures     | 0             |# 时间函数未正常工作的次数
| Rpl_semi_sync_master_tx_avg_wait_time      | 29059         |# 开启Semi-sync，事务返回需要等待的平均时间
| Rpl_semi_sync_master_tx_wait_time          | 8164966680929 |# 事务等待备库响应的总时间
| Rpl_semi_sync_master_tx_waits              | 280974820     |# 事务等待备库响应的总次数
| Rpl_semi_sync_master_wait_pos_backtraverse | 5499398       |# 改变当前等待最小二进制日志的次数
| Rpl_semi_sync_master_wait_sessions         | 230           |# 当前有几个线程在等备库响应
| Rpl_semi_sync_master_yes_tx                | 16801244      |# Semi-sync模式下，成功的事务数
+--------------------------------------------+---------------+

上面比较重要的状态值有：

Rpl_semi_sync_master_tx_avg_wait_time：事务因开启Semi_sync，平均需要额外等待的时间

Rpl_semi_sync_master_net_avg_wait_time：事务进入等待队列后，到网络平均等待时间

依据上面两个状态值可以知道，Semi-sync的网络消耗有多大，给某个事务带来的额外的消耗有多大。

Rpl_semi_sync_master_status 则表示当前Semi-sync是否正常工作。

从Rpl_semi_sync_master_no_times变量，可以知道一段时间内，Semi-sync是否有超时失败过，该计数器则记录了这样的失败次数。

比较难理解参数有：

Rpl_semi_sync_master_wait_pos_backtraverse：这个稍微难理解一点，不过该参数并不重要。

花了一些时间弄明白这个变量，继续证实了这个变量确实不重要。

在semisync_master中，维护了这样的两个变量wait_file_name_和wait_file_pos_，当主库上多个事务都在等待备库的响应时，这两个变量记录了所有等待中，最小的那一个Binlog位置。如果这时，一个新的事务加入等待，并且该事务需要等待的Binlog比wait_file_name_和wait_file_pos_还小的话，则更新这两个值，并将Rpl_semi_sync_master_wait_pos_backtraverse值自增一次。

上面的解释参考如下代码段（semisync_master.cc）：

int cmp = ActiveTranx::compare(trx_wait_binlog_name, trx_wait_binlog_pos,
                               wait_file_name_, wait_file_pos_);
if (cmp <= 0)
{
  /* This thd has a lower position, let's update the minimum info. */
  strcpy(wait_file_name_, trx_wait_binlog_name);
  wait_file_pos_ = trx_wait_binlog_pos;

  rpl_semi_sync_master_wait_pos_backtraverse++;
  if (trace_level_ & kTraceDetail)
    sql_print_information("%s: move back wait position (%s, %lu),",
                          kWho, wait_file_name_, (unsigned long)wait_file_pos_);
}

累了，听首歌，伸个懒腰吧:)

广告：我们寻找靠谱的人 | 感谢作者

参考文献：

1. ReplicationFeatures/SemiSyncReplication

2. SemiSync Replication of Google-mysql-tool

3. SemiSyncReplicationDesign

4. ReplicationTeam

5. MySQL Manual Semisynchronous Replication

Cmake是跨平台的工具，如果之前就尝试过在Windows上编译MySQL的同学，就应该还记得CMake。

我的环境是不自带CMake（环境：RHEL5.4，YUM仓库里面没有CMake），所以需要自己安装。安装过程简单、顺利，没有遇到任何依赖问题......:)

CMake下载、安装参考。

其中"ccmake . -D......"也可直接使用"cmake ."，这样会进入一个简单文本GUI界面进行MySQL编译参数配置；

另外，原来的AutoTools和现在CMake配置参数的变化，在MySQL Forge的Autotools to CMake Transition Guide中可以查阅详细的对比说明。

除了上面编译部分不同之外，其他的过程和原来的版本都还是不变的：

# # # 新建运行MySQL的用户
groupadd dba
useradd -g dba mysql
cp mysql-5.5.11.tar.gz /home/mysql/
chown -R mysql:dba /home/mysql/mysql-5.5.11.tar.gz

# # # 开始编译、安装
su - mysql
tar zxf mysql-5.5.11.tar.gz
cd mysql-5.5.11
CFLAGS="-O3" CXX=gcc
CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti"
cmake . -LH|more        //CMake下查看MySQL的编译配置
cmake . -DCMAKE_INSTALL_PREFIX=/home/mysql/mysql -DEXTRA_CHARSETS=all
make -j 8 && make install   #-j 表示希望使用cpu核数

# # # 建立配置文件
cd /home/mysql/mysql
su - root
cp mysql/share/mysql/my-medium.cnf /etc/my.cnf
chown -R mysql:dba /etc/my.cnf

# # # 修改配置文件 配置数据文件、日志的路径
su - mysql
vi /etc/my.cnf
basedir = /home/mysql/mysql
datadir = /home/mysql/mysql/data
socket = /home/mysql/mysql/run/mysql.sock
log-error = /home/mysql/mysql/log/alert.log
log_slow_queries = /home/mysql/mysql/log/slow.log

mkdir log run tmp

# # # 初始MySQL配置表（用户表 权限表等）
./scripts/mysql_install_db --basedir=/home/mysql/mysql  --datadir=/home/mysql/mysql/data --user=mysql --force

# # # 启动MySQL
./bin/mysqld_safe &

参考：

1. MySQL Forge::CMake

2. Autotools to CMake Transition Guide

3. 编译安装MySQL

4. MySQL Source-Configuration Options

在一台主机上如果复制多个主库，可以很简单：在备库主机上启动多个MySQL实例（mysqld_muilt），每个实例使用一个端口，复制多台主库就可以了。但是如果希望复制过来的数据都在同一个实例中，事情就复杂了。

需求：多个主库都复制到一个备库，复制过来的数据都在一个实例中，这样实现对应用层的透明。目前，MySQL本身不提供这样的功能(考虑过，但一直未实现)。

1.1 开源社区也有很多方案和想法，例如Tungsten replicator：可以支持异构数据复制，JAVA实现，数据量较大时，性能较差，而且MySQL版本更新较快，而该软件支持较慢；

1.2 再如P.Linux的尝试：通过拉取多个主库上的Binlog在单个备库上应用的方式，对MySQL没有入侵，实现也较为简单。

1.3 High Performance MySQL还可以通过多级复制的方式实现：例如有主库DB1、DB2，都需要复制到S1上，则先配置D2复制D1的全部数据，然后再从S1上复制D2的全部数据就可以了。整理需要注意D2上的log-slave-update需要打开，为了减少D2的压力，DB上复制过来的表可以全部使用Blackhole引擎。

1.4 另外，还有一些欠成熟的Patch实现。

Federated引擎可以在本地数据库中创建一个远端数据表的“软链接”。这样，访问远端数据表就如同访问本地数据表。（这里远端可以是不同主机上的不同实例）

例如，主库DB1，DB2，都需要复制到S1上，这里DB1，DB2，S1分别在主机H1，H2，H3上。首先，在主机H3(S1所在的主机)上其另外起两个MySQL实例S2、S3，分别复制主库DB1和DB2，然后在实例S1上建立多个Federated表关联S2、S3中的数据表（相当于在S1中建立到S2、S3的软连接）。

这时应用，连接到S1，就可以同时透明的访问到DB1、DB2中的实时数据表了。

4.1 上面描述的方法，也可以直接在S1上建立到DB1、DB2各个表的软连接，但是为了最大程度的减少对主库的影响，最好如上多配一层备库。

4.2 最简单的可以直接在备库上配置多个实例，让应用连接多个实例就好了，无需上面这么复制的配置。

参考文献：

1. MySQL Manual: The FEDERATED Storage Engine

2. Post of MySQL Forums : Multiple masters to single slave

3. 通过tungsten replicator实现mysql多主一从的备份架构

4. Is it possible to do N-master => 1-slave replication with MySQL

5. MySQL Multi-Master – Single-Slave – Replication

上面的SQL，咋一眼，很难看出SQL的目的是什么。而格式化的输出可以让SQL更易读懂，如：

上周末做了一个简单的PHP SQL Format工具，可以实现上述功能，这里简单的介绍如何使用PHP SQL Format（也可以参考这里）。

有如下文件:

将这些文件都放入web目录下的sqlparserlib目录下。

<link rel="stylesheet" type="text/css" href="sqlparserlib/sqlsyntax.css" />
<?php
     define('PARSER_LIB_ROOT', "/opt/www/sqlparserlib/");
     require_once PARSER_LIB_ROOT.'sqlparser.lib.php';
     function SQLFormatPHP($sql){
        return PMA_SQP_formatHtml(PMA_SQP_parse($sql));
     }
     $sql = "SELECT  FROM (select  from dual)";
     echo SQLFormatPHP($sql);
 ?>

只要把上面php代码中的$sql改成你的输入SQL就OK了。

* 上面的代码中，路径一定要注意，在你的代码中也必须引用正确的路径

* 上面的sqlsyntax.css定义了很多CSS，注意不要与你的CSS冲突了

* 上面require_once很多函数，注意不要与你的函数冲突了

这里使用的代码包sqlparser.lib.php来自phpMyAdmin，稍微做了一些改动，让这块代码能够独立使用。

看了Stackoverflow上很多朋友也有类似问题，所以就花了几个小时的尝试，把phpMyAdmin里面SQL Parser相关的代码独立出来，lib中有很多的代码都应该是无用的，我并没有做精简，所以你最求效率的话，可能需要自己再优化一下。