MySQL的google贡献Google-MySQL-Tools

 

顺便把以前写的google对MySQL的相关补丁介绍找出来了，部分补丁已经并入MySQL的新版中了。文章贴在这里。权当纪念

娘的，图片不知道怎么发上来，实在有人有兴趣，联系我要word版或者pdf版吧:)
Google-MySQL-Tools  overview
说明

目 录
目 录    2
1    修订记录    3
2    介绍    4
2.1    目的和范围    4
2.2    术语与缩写解释    4
3    详细限制和依赖描述    5
3.1    数据表限制    5
3.2    冲突解决限制    5
3.3    MySQL服务器限制    6
4    MySQL 5.1的新特性    7
4.1    Partitioning分区    7
4.2    Row-based replication    7
4.3    Plugin API.    8
4.4    Event scheduler    8
4.5    Server log tables    8
4.6    Upgrade program    8
4.7    MySQL Cluster replication    8
4.8    MySQL Cluster disk data storage    8
4.9    Improved backups for MySQL Cluster    9
4.10    MySQL Cluster NDB 6.x    9
4.11    Backup of tablespaces    9
4.12    Improvements to INFORMATION_SCHEMA    9
4.13    XML functions with XPath support    9
4.14    Load emulator    9
5    相关文档列表    10
6    附录    11

1修订记录

修订日期    版本号    描述    修订人
2009-02-04    1.0    create    Pickup.Li

2介绍
2.1目的和范围
本文档主要介绍google-mysql-tools工具的相关特性，原理及相关配置注意事项。
google-mysql-tools工具是google公司为了管理，维护和改进MySQL性能的一系列工具，它是一个开源项目，遵守Apache License 2.0协议，编写工具包括python和c++语言。这一系列工具主要包括三个主要的方面：
1)mypgrep.py。python文件，类似于pgrep工具。它是用来查看和管理MySQL连接的。
2)compact_innodb.py。python文件。这个工具通过dumping and reloading所有的table来压缩innodb的数据文件。
3)patches。为MySQL 4.0.26和5.0.37增加一些新特性的一系列patch文件。通过这些文件给MySQL的源代码打上对应的补丁以后，增强了MySQL的功能。目前google-mysql-tools对MySQL5.0.37有两个版本的补丁V1和V2，V2版本是V1版本的加强，并增加了新特性，但目前V2版本仍然是beta版本，没有发布出来。
本文档主要描述的是google-mysql-tools打上V1版本的补丁以后为MySQL增加的新特性。并简单涉及了V2版本的相关内容。

3Google-MySQL-Tools MySQL5 V1 V2已发布特性
3.1Mirrored Binlogs
该patch仅存在于V1版本，在V2版本中它被GlobalTransactionIds patch替换掉了。
3.1.1概述
MySQL本身的replication的效率，稳定性和易用性基本上能够满足一般用户的需求。但是对于那些复杂架构的replication结构有所欠缺。MySQL replication是slave保持着master的binlog名称和偏移量来复制event的。如图1左图所示，relay MySQL从master复制，并作为中继将从master复制的数据记录到本地binlog中（这里其实有一个“翻译”的过程，master的binlog名称和偏移量在relay中都不同了），而slave MySQL则从relay的binlog中读取event。

图1 MySQL replication和Google-MySQL-Tools mirrored binlog比较
Mirrored binlogs利用relay的IO线程来下载和保存一个master的binlog文件，binlog文件名和偏移量和master端的完全一致。
假如，还有另外一个MySQL instance从master复制数据。当master崩溃时，大家想到的第一个办法就是failover到从relay MySQL那里复制数据，因为relay MySQL已经从master中复制了数据，但是relay MySQL的binlog文件名和偏移量和master都不相同，这个新的slave应该从从relay MySQL的那个地方开始复制，这个很难确定而且容易出错。但是relay MySQL如果采用了Mirrored binlog，由于本地保存binlog文件和master端的完全一样，那么从master端failover到slave端时，新的slave可能完全感觉不到切换的过程。

3.1.2原理和实现方法
实际上Mirrored binlogs的原理很简单，它仅仅增加了一个ReplMule的类（sql/repl_mule.h），并修改了MySQL的IO thread的源代码：在IO thread中初始化和实例化该类并在IO thread获得一个event时将它记录到binlog文件中，这个binlog文件名和偏移量保持与master的一样。另外，要注意的是，第一次设置了Mirrored binlog的时候，slave将从master端下载当前的binlog。这个过程可能要花费一定的时间，在下载完成之前，将不会获取下一个master的event。

3.1.3配置
Mirrored binlog有三个配置选项：rpl_mirror_binlog_enabled，rpl_mirror_binlog_no_replicate，sync-mirror-binlog。rpl_mirror_binlog_enabled设置Mirrored binlog功能的有效性。rpl_mirror_binlog_no_replicate启用slave端的Mirrored binlog功能，但是不允许它的slave继续Mirrored binlog 。sync-mirror-binlog类似于sync_binlog，只不过它是针对Mirrored Binlogs的。
在my.cnf中添加了rpl_mirror_binlog_enabled时，需要同时指定MASTER_HOST=”192.168.1.111″, MASTER_USER = ‘repl’, MASTER_PASSWORD = ‘slavepass’等选项以便Mirrored Binlog连接Master获取数据。并且不能指定skip-slave-start，否则Mirrored Binlogs将无效。
如果配置正确，重新启动MySQL后你可以在slave的data目录看到和master的binlog同名的文件，这就是Mirrored Binlogs下载并生成的。另外，在slave端用show master status你看到的将是master的binlog文件名

3.2Semi-synchronous replication

3.2.1概述
MySQL replication本身是异步的，master并不知道slave何时或者是否已经获得了binlog的event。它的效率也是比较高的，slave请求某个binlog文件的某一偏移量开始的replication event，而master在event准备好时将它们发送给slave，这样对master没有很多的性能消耗。
Semi-synchronous replication扩展了replication为半双工的，slave可以配置为async或semi-sync两种不同的方式。如果在master端启用了Semi-synchronous replication，当语句提交返回前都需要阻塞，直到至少收到了一个semi-sync slave的确认或者达到了用户配置的超时时间。如果超过了超时时间，Semi-synchronous replication将不再有效，当slave重新同步成功，Semi-synchronous replication又将重新启用。

3.2.2原理和实现方法
Semi-synchronous replication的主要流程如图2所示，它修改了MySQL replication的协议，以及语句提交的代码。在transanction提交以后将等待slave，这里将有可能超过超时时间；之后，才返回客户端通知操作结果。在等待网络回应的过程中其他的transaction并不会阻赛。在slave连接master并开始请求数据的时候，如果设置了Semi-synchronous replication，那么slave的请求数据的binlog_flag中将设置BINLOG_SEMI_SYNC以注册slave为semi-sync模式。这样的话，master向该slave发送的event将包括一个额外单字节的头，该字节指明slave是否需要向master回应一个消息。
Master端将为所有正在等待回应的transaction建立一个检索树，检索树以(binlog_filename, binlog_pos)为键，方便replication线程找到当前等待的transaction。图3，图4分别为master端transaction commit的流程图和replication thread发送binlog时的流程图。

图2 Semi-synchronous replication示意图

图3 master transaction commit流程图

图4 replication线程发送binlog流程图

3.2.3配置
Semi-synchronous replication有三个配置选项：rpl_semi_sync_enabled，rpl_semi_sync_slave_enabled，rpl_semi_sync_timeout。rpl_semi_sync_enabled用来在master端启用Semi-synchronous replication，而rpl_semi_sync_slave_enabled用于在slave端启用。而commit超时的时间由rpl_semi_sync_timeout设置。另外，用户还可以通过show status查看Semi-synchronous replication的状态变量，例如：semi-sync slave的个数-Rpl_semi_sync_clients，semi-sync是否被启用-Rpl_semi_sync_status等等。
Semi-synchronous replication可以在不重启数据库的情况下停用或者启用。
简单的测试表明，Semi-synchronous replication由于在第一次slave不能跟上的情况下将会自动停用，所以对master的性能影响不大。

3.3SqlChanges
Google-MySQL-Tools对MySQL的SQL分析进行了一定的改变。为MySQL增加了新的tokens，新的函数，新的语句（statements），也为已有的语句增加了新的选项(options)。
3.3.1New tokens
Google-MySQL-Tools为MySQL增加了一些新的token，主要包括：CLIENT_STATISTICS, TABLE_STATISTICS, USER_STATISTICS, INDEX_STATISTICS, IF_IDLE, MAKE, MAPPED, MAX_QUERIES_PER_MINUTE, NEW_PASSWORD, ROLE, SLOW, TCMALLOC, IEEE754_TO_STRING, LAST_VALUE, ORDERED_CHECKSUM, UNORDERED_CHECKSUM。

3.3.2New SQL functions
Google-MySQL-Tools为MySQL增加了一些新的函数。包括：ORDERED_CHECKSUM, UNORDERED_CHECKSUM, LAST_VALUE, HASH, IEEE754_TO_STRING, NEW_PASSWORD。这些函数的具体信息可以通过这里查找到详细信息。参见3.16 NewSqlFunctions

3.3.3New options for existing statements
KILL <id> IF_IDLE可以仅在一个连接空闲的时候切断它。MAX_QUERIES_PER_MINUTE可以用来替代MAX_QUERIES_PER_HOUR，从而对查询的限制从每小时转为每分钟。CREATE MAPPED USER ‘foo’ ROLE ‘bar’和DROP MAPPED USER ‘foo’为Mapped user提供支持。详情请查看MySQLRoles介绍或者这里。相对应的SHOW PROCESSLIST WITH ROLES和SHOW USER_STATISTICS WITH ROLES通过role而不是用户名来再结果中展示进程和用户数据。

3.3.4New statements
Google-MySQL-Tools为MySQL增加了用户表监控函数：SHOW USER_STATISTICS, SHOW TABLE_STATISTICS, SHOW INDEX_STATISTICS, SHOW CLIENT_STATISTICS, FLUSH TABLE_STATISTICS, FLUSH INDEX_STATISTICS, FLUSH CLIENT_STATISTICS。参见3.8节UserTableMonitoring。
Google-MySQL-Tools为MySQL增加了针对帐号和客户端IP速度限制的函数。例如：MAKE USER ‘foo’ DELAYED 1000, MAKE CLIENT ’10.0.0.1′ DELAYED 2000, SHOW DELAYED USER, SHOW DELAYED CLIENT。参见3.11节MysqlRateLimiting。
另外，还包括：SHOW TCMALLOC STATUS用于展示tcmalloc的状态，它只有在在MySQL连接(link) tcmalloc并且编译时指定了-DUSE_TCMALLOC时才有效。实际上它只是展示了MallocExtension::GetStats的输出结果。CAST函数可以转换数据为双精度型。SHOW INNODB LOCKS函数提供了InnoDB锁的占用者holders和等待者waiters的更多详细信息。FLUSH SLOW QUERY LOGS刷新slow query log文件。MAKE MASTER REVOKE SESSION使得除当前会话以外的连接都断开，并且除了有SUPER, REPL_CLIENT或者REPL_SLAVE权限的用户可以连接，其他的用户都不能连接数据库。与之相反的，MAKE MASTER GRANT SESSION取消这种限制。

3.4InnodbSmp
Google-MySQL-Tools修改了MySQL的源代码使得它在SMP服务器上运行更加快速，在8核以上的服务器上更加明显。代码修改包括：对InnoDB的互斥量mutex采用原子内存操作(atomic memory operations)。使用tcmalloc并且禁用了InnoDB的内存堆(memory heap)。对InnoDB的读写互斥量rw-mutex采用原子内存操作(atomic memory operations)。

3.5NewShowStatus
Google-MySQL-Tools为用户监控和查看MySQL的状态提供了更多的信息。Show status中现在宝航了一些show innodb status的信息。对那些频繁查看MySQL状态的工具(overzealous monitoring tools)也进行了速率限制，限制他们不断的进行耗费资源的show操作。更多详细信息见这里。

3.6NewShowInnodbStatus
Google-MySQL-Tools修改了SHOW INNODB STATUS的输出，输出了更多信息。通过输出的重新排序使得事务以列表的形式打印并且可能返回的最大输出大小。更多详细信息见这里。

3.7NewConfiguration
由于Google-MySQL-Tools增加了这么多功能，所以配置文件也有相应的选项增加。更多详细信息见这里。

3.8UserTableMonitoring
Google-MySQL-Tools为每个帐号，数据表，索引记录了数据库动作(database activity) 。同样，为这些数据提供了SQL语句来打印这些信息。并且，Google-MySQL-Tools正在计划把他们整合到information_schema中。
相关的SQL statement有：SHOW USER_STATISTICS, SHOW TABLE_STATISTICS, SHOW INDEX_STATISTICS, SHOW CLIENT_STATISTICS, FLUSH TABLE_STATISTICS, FLUSH INDEX_STATISTICS, FLUSH CLIENT_STATISTICS。更多详细信息见这里。

3.9TransactionalReplication
MySQL本身的replication会记录当前的复制信息到master.info和relay-log.info文件中。SQL thread首先在存储引擎端提交事务，然后更新上述两个文件来指明下一个SQL thread执行的event的偏移量。但是，如果正好在提交事务以后和更新文件之前MySQL被停掉了，那么复制状态就不对了，SQL thread将在MySQL再次启动的时候重新执行上次的最后一个事务。
Google-MySQL-Tools通过在InnoDB的事务日志中保存复制状态来避免上述错误。在MySQL重新启动的时候，保证前面提到的复制信息文件和该状态保持一致。可以通过指定：rpl_transaction_enabled=1来使的该策略生效。一般来说，它应该加到my.cnf的[mysqld]段。更多详细信息见这里。

3.10MysqlRoles
MySQL对成千上万的账号和表的访问控制效果不理想。导致这个问题的原因在于，很多帐户都有一样的权限，而唯一为一个账号限制它的访问权限的办法就是为它在表一级或者列一级分配权限，从而使得mysql.user表存在很多条记录。实际上，权限(privileges)可以和角色(role)对应起来，而一个角色可以和多个账号对应起来。从而，当多个帐号有同样的权限时，可以避免为每一个账号去单独指定一个权限。
Google-MySQL-Tools在MySQL访问控制模式中增加了mapped user来实现这样的功能。一个mapper user提供了权限认证并且对应于访问控制中的一个角色。Mysql.mapped_user表就是为了定义mapper user的表。Mysql.user表则被当作角色的表。也就是说：mapped user对应于mysql.mapped_user表中的一行记录，role对应mysql.user的一行记录，而同时又对应着多个mysql.mapped_user中的记录(对应列为：mysql.mapped_user.Role)。
通过对访问控制模式的修改，Google-MySQL-Tools有如下特性：一个帐户可以有多个密码；手动的密码过期机制；角色的概念；这个修改对客户端透明，客户端连接完全不需要修改。更多详细信息见这里。

3.11MysqlRateLimiting
Google-MySQL-Tools为MySQL的每个用户或者客户端IP增加了速度控制。MAKE USER ‘foo’ DELAYED 1000使得foo用户提交的SQL语句在执行前先sleep 1000毫秒。当延迟设置为0时表示没有延迟。对应的用户延时值可以通过SHOW DELAYED USER打印出来。这些延时值是易失的，在MySQL重启之后都被设置为0。对于已有的连接，延时设置是无效的，只有该用户在重新连接的时候才会获得新的延时值。另外要注意的是，MySQL本身通过mysql.user. max_questions列为一个账号指定了每个小时可以执行的语句个数，Google-MySQL-Tools把它改为每分钟可以执行的语句个数。
MAKE CLIENT ’10.0.0.1′ DELAYED 2000对IP地址为10.0.0.1提交的语句sleep 2000毫秒，这些延时值通过SHOW DELAYED CLIENT获得。更多详细信息见这里。

3.12MoreLogging
Google-MySQL-Tools为MySQL增加了更多的日志记录选项：audit_log记录了用户登录信息，对指定表的查询语句(用log_tables选项来指定，各表名用分号分隔)和启动的相关信息。Log-update记录有SUPER权限的用户提交的DDL和DML语句。更多详细信息见这里。

3.13InnodbAsyncIo
InnoDB在Windows环境下支持异步IO，在Linux环境下将启动4个线程来完成后台的IO任务，这些线程都采用同步IO。
在不使用直接IO(direct IO)而采用缓存IO(buffered IO)或者远程IO(remote disk)的架构里，写线程(write threads)个数并不需要太多，因为写到操作系统的缓存中非常快速。但是如果内存非常大，使用直接IO的效率会更高。
Google-MySQL-Tools修改了InnoDB相关代码，使得用户可以配置读写请求的后台IO线程个数。配置参数如下：innodb_max_merged_io：后台IO线程合并提交的IO请求的最大个数。innodb_read_io_threads：读取预取请求(prefetch requests)的后台IO线程的个数。innodb_write_io_threads：从缓存中向脏页(dirty pages)写的后台IO线程个数。更多详细信息见这里。

3.14FastMasterPromotion
Google-MySQL-Tools提供了一些命令来允许快速的将slave升级为master，它是在slave不重新启动的情况下升级的，有脏页(dirty pages)的存储引擎，例如InnoDB需要耗费很长时间（大于一分钟）来停止。以下命令在V1和V2补丁中都存在：MAKE MASTER REVOKE SESSION, MAKE MASTER REVOKE SESSION WITH KILL, MAKE MASTER GRANT SESSION。而以下命令仅存在于V1补丁：MAKE MASTER MASTER_LOG_FILE=<log_file>, MASTER_SERVER_ID=<id> BINLOG, MAKE MASTER MASTER_LOG_FILE=<log_file>, MASTER_SERVER_ID=<id>, INDEX=<log_file.index> BINLOG。
MAKE MASTER MASTER_LOG_FILE使得slave在不重启mysqld的情况下使用对应的binlog文件。MAKE MASTER REVOKE SESSION阻止那些没有SUPER权限的用户连接，当指定了WITH KILL选项时当前的没有SUPER权限的连接将被断开。MAKE MASTER GRANT SESSION则取消上述限制，允许那些没有SUPER权限的用户连接。更多详细信息见这里。

3.15InnodbSampling
InnoDB使用取样(sampling)来确定进一步的优化统计(optimizer statistics)。它采用8个叶子节点(leaf node)的索引键。而Google-MySQL-Tools增加了一个会话参数(session parameter)来设置取样的叶子快(leaf block)个数，缺省为8。对应的参数为：innodb_btr_estimate_n_pages。更多详细信息见这里。

3.16NewSqlFunctions
Google-MySQL-Tools为MySQL添加了一些新的函数。
IEEE754_TO_STRING：转换浮点型(float)或者双精度型(double)数据为字符串型(string)。转换成的字符串为17位的数字精度(17 digits of precision)，这样从字符串转换回双精度型就不会损失精度。这样，除非在特殊情况下，转换回的双精度型数据和原来的相等。
UNORDERED_CHECKSUM：这是一个SQL聚合函数(SQL aggregate function)，接受一个或者多个参数，返回每个group的输入参数的hash值(returns the hash of its input arguments per group)。该函数与order独立。Group中的每一个row的结果是用异或(XOR)连接起来的。用户可以像这样调用该函数：select unordered_checksum(c1, c2) from foo group by c3;
ORDERED_CHECKSUM：和上面的函数一样，不过它跟order有关，group中的第一个row将作为下一个row的hash的种子。
HASH：这是一个SQL函数(SQL function)，返回输入参数的hash值，它不是一个聚合函数，对每个row将返回一个值。
LAST_VALUE：这是一个SQL聚合函数(SQL aggregate function)，它返回每个group读取的最后一个值。也就是说它依赖于聚合的输入顺序(input order to aggregation)。可以参考OnlineDataDrift。
NEW_PASSWORD：计算新密码(new-style password)的hash值，而不管my.cnf中的old_passwords参数值。
更多详细信息见这里。

3.17InnoDBStatus
Google-MySQL-Tools为MySQL的show innodb status增加额外的输出信息。包括：当前的事务信息段(current transaction section)太长了而被截断的时候而打印完整的信息(print last)；返回的数据量从64kb增加到了128kb；在show innodb status中提供了更加丰富的信息。额外的统计信息包括：每次读或者写请求的平均时间；调用fsync的源；调用同步函数同步InnoDB事务日志的源；后台IO线程完成的工作量等。更多详细信息见这里。

3.18LosslessFloatDump
Google-MySQL-Tools使得MySQL备份和恢复(dump and restore)列数据为浮点型(float)或者双精度型(double)时没有精度上的损失。用户可以在mysqldump命令里加上选项—lossless-fp来启用这个特性。这样，备份时，浮点和双精度型的数据将被转换为17位精度的数字字符串(decimal string with 17 digits of precision)。更多详细信息见这里。

3.19MysqlHttp
Google-MySQL-Tools为MySQL增加了HTTP的内容。更多详细信息见这里。

3.20InnodbIoTuning
Google-MySQL-Tools修改了InnoDB相关代码来调整输入输出。InnoDB利用后台线程来进行IO操作，包括：purge thread物理删除那些被逻辑删除的行；insert buffer thread更新二级索引(secondary indexes)；log thread进行事务日至IO的操作；write thread将缓存脏页(dirty buffer cache pages)写入磁盘；read thread预取磁盘块(prefetches blocks)。一般来说，一个线程无法完成读和写的任务，所以Google-MySQL-Tools增加了一些配置参数来设置线程个数：innodb_read_io_threads，innodb_write_io_threads。参见3.13 InnodbAsyncIO。
Google-MySQL-Tools为了避免后台IO线程耗尽服务器资源增加了速度限制的功能。这里假设服务器最大可以做100个IOPs，用户可以设置innodb_io_capacity来指定最大磁盘IOPs数。另外innodb_extra_dirty_writes可以在dirty pct比最大值小的时候刷新缓存脏页(dirty buffer page)。

3.21MutexContentionStats
这个补丁是在x86-64的linux 2.6上用gcc构建的，不知道在其他平台下好不好用。
该补丁为MySQL提供了互斥量争用统计信息(mutex contention statistic)，它和show mutex status提供的InnoDB的互斥量输出信息类似。
它同样在请求锁的阻塞过程前(before blocking on lock request)使用忙等循环(busy-wait loops)。这么做的主要原因是为了确定是否有互斥量争用的情况(mutex contention)。如果在忙等循环中不能获得锁，代码就会假设调用者(caller)在请求锁的时候应该要阻塞。忙等循环的持续时间由my.cnf中的参数mysql_spin_wait_loops确定，默认值为500-在X86-64的CPU上对应为4毫秒的延迟。在mysqld启动时将获得该延迟并且输出在数据库的error log日志文件中。同样在show status的变量Mysql_spin_wait_microseconds中也可以查看。
对于指定的锁请求来说，忙等时间是从1到Max（Max为变量mysql_spin_wait_loops的值）中的一个随机数。Google-MySQL-Tools修改了这个计算随机值的函数，使用从InnoDB中的代码，而不是用libc中的random()函数。因为random()函数本身就有互斥量争用的问题。
忙等循环(busy-wait loop)将循环四次(four rounds)。在每次循环中，它都会尝试提交一个非阻塞的锁请求(makes a non-blocking lock attempt)。如果没有得到锁，那么spin 1毫秒(spins for 1 microsecond)。如果四次都失败了，它将提交一个阻塞型的锁请求，并且增加sleeps counter。Spin的主要目的是为了检查互斥量争用(mutex contention)，它并不是用来提升性能的。它应该用在性能测试环境(performance debugging builds)而不是生产环境(production builds)。在构建时可以通过指定标志：–with-fast-mutexes来启用它。
SHOW GLOBAL MUTEX STATUS命令可以显示大部分信息。更多详细信息见这里。

3.22FastMutexes
Google-MySQL-Tools将MySQL5.1中的快速互斥量(fast mutexes)backport到以前的版本，并实现了MutexContentionStat。编译时指定—with-fast-mutexes就可以启用它。更多详细信息见这里。

3.23InnodbFreeze
Google-MySQL-Tools可以冻结InnoDB的文件系统的活动。通过set global innodb_disallow_writes=ON，set global innodb_disallow_writes=OFF可以实现这样的目的。它们允许或者阻止用户进行除读取以外的InnoDB文件系统的操作。如果你想在不停止MySQL的情况下备份数据库，并且你也没有使用LVM，ZFS或者其他可以提供快照(snapshots)的存储软件(storage software)，那么你可以使用上述命令来阻止InnoDB对文件的修改操作(halt all destructive file system activity from InnoDB)，然后就可以备份InnoDB的数据文件。注意：FLUSH TABLES WITH READ LOCK并不能达到这个目的，因为InnoDB的后台IO线程仍然可能做一些IO操作。更多详细信息见这里。

4Features in the V2 beta patch
Google-MySQL-Tools的V2 patch目前并没有发布出来。我们这里简要介绍一下它的几个简单特性。
4.1GlobalTransactionIds
Google-MySQL-Tools让slave能够直接从一个master切换到另外一个master。它提出了一个Global Group ID的概念。每个MySQL instance都有一个统一的Global Group ID，并且在复制的过程中Global Group ID不会变化。这个ID将加到binlog 的事件头中，一个group中的所有事件event的ID都相同，并且group ID都是唯一并且比之前的group ID要大。这个group ID同样也要写到slave的relay log中。这样，slave的SQL thread分析执行event的时候也要解析group ID并且把它保持不变的写到自己的binlog中。这样，当fail over到新的master的时候，它就可以从以前的master的group ID号继续。更多详细信息见这里。

4.2OnlineDataDrift
这个工具主要做以下事情：1、评估数据库里面的row的数目来决定它运行的速度。2、对每一个表执行一系列语句来计算一些行(a chunk of rows)的校验和(checksum)并把结果记录到一个表中。当它运行完时，就可以比较master和slave的存放结果的表。如果两者有不同，那就说明有数据偏差(data drift)。更多详细信息见这里。

4.3MysqlThreadPool
Google-MySQL-Tools为MySQL增加了线程池的代码。

5相关文档列表
Google-MySQL-Tools官方网站

6附录

may your sucess.

http://www.slideshare.net/pickup112/google-mysqltools-overview