MySQL Replication可以很方便的用来做应用的读扩展，也可以帮MySQL实现一定程度的HA方案。MySQL通过向备库传送二进制日志来实现Replication，本文将通过二进制日志相关源代码的主要接口来解释：“MySQL如何传输二进制日志，是主库推，还是备库拉？MySQL日志传输的实时性如何？”。
在MySQL Replication结构中，备库端初次通过CHANGE MASTER TO完成Replication配置，再使用start slave命令开始复制。更细致的，备库通过IO Thread向主库发起读取binlog的请求（COM_BINLOG_DUMP命令），主库收到COM_BINLOG_DUMP请求后，使用单独线程（dump thread）不断向备库IO Thread发送Binlog。示意图(大图)：
7月份YOSHINORI MATSUNOBU在Blog上Release了第一个版本的MySQL Master High Availability manager and tools(简称MHA)。
用于自动主备切换（Master的Failover），切换时间大约是10-30秒，MHA主要的优势是解决了主备的一致性问题，是第三方脚本的方式，对原来的MySQL没有任何影响，也不需要改变任何原来的架构部署。当然也支持在线的计划切换，切换时间大约也就0.5-2秒【可读，不可写】
是一种简单、优雅的高可用解决方案，有一些功能：
在一个配好的主从环境中，MHA能够实时的监控MySQL主库，如果探测到主库失败，则会启动自动的切换程序(master failover)。这时，MHA能够保证所有的备库上的数据都一致。MHA会检查所有备库上的relay log，并使用最靠前的relay log，来同步所有其他的备库，保证各个备库的数据一致。MHA一般能够很快完成切换工作：9-12秒来探测主库失败，7-10秒来关闭master来避免脑裂(可选的)，然后在各个落后的备库上应用最新的日志(某一个备库上受到的最新的日志)。整个downtime大概是10-30秒。可以设置某一个备库，总是优先成为主库（可以通过在配置文件中设置优先级来实现），因为各个备库会全部同步，所以任何一个备库都可以成为主库。由于不一致导致的备库失败，这里都可以避免。
不监控，直接进行切换操作。
有时候，需要更换主库，例如原主库有已知的硬件故障（RAM、RAID control等）或者换上更好的硬件等等。这是一种计划切换，MHA能够非常快速、并且“一致的”的完成切换。所谓“一致的”，即避免在切换时，原主库上还存在存活的Session，在做一些事务，导致数据的不一致。MHA完成这个“一致的”切换，大概会有0.5-2秒的写阻塞，一般这都是可以接受的维护时间。
主库Failover并没有想象的那么繁琐。我们看看最典型的MySQL部署情况：单个主库拖多个备库。当主库挂了，则需要先找到“最新”的Slave，将其升级为新的主库，并且让其他的备库都指向这个新主库。这并不复杂。当找到“最新”的slave，很容易确定其他备库哪些event还没有收到，如果这些非“最新”的备库不问青红皂白就直接连到新主库上的话，则会导致一些数据不一致。为了避免这种不一致，则需要确定哪些是丢失的events，然后apply到这些备库上，再连新主库。如果手动来做这些事儿的话，那就十分繁琐而且复杂。在这个Slide里面详细描述了这个细节：Automated master failover
Fig: Master Failover: What makes it difficult?
“最新”的slave表示：获得最多binlog的备库。
Currently most MySQL Replication users have no choice but to perform failover manually on master crashes.
在主库crash的时候，目前还没有什么好办法保证各个备库的一致。所以，很多时候需要手动去做这些操作，虽然主库crash的时候不多，但是一旦出现，那将是“相当”（用宋丹丹的口气说）的痛苦。
MHA目标就是实现这样的自动恢复。这个恢复包括选定新主库、确定各个备库relay log的差异、在新主库上应用差异的relay log，然后将其他备库指向新主库。一般MHA10-30秒可以完成全部的操作（可能更久如果你的备库延迟了很久的话）。
MHA有自动和命令行切换工具，自动切换命令”masterha_manager (MHA Manager)”由主库监控和主库Failover两部分组成。masterha_manager一直监控主库是否可用，如果发现无法连接主库，则可以立即执行一个非交互是的切换过程。
手动切换命令：masterha_master_switch先检查主库是否确实挂了，如果真挂了，masterha_master_switch选一个备库作为新主库（也可以指定一个），然后做恢复和切换。命令行把前面的复杂操作全部都封装起来了。
当已经有了自己的监控系统时（例如，你可以使用Pacemake之类的监控），无需使用MHA的监控功能时，这个功能可以帮你实现MySQL的切换操作。
注意事项：
这又是一篇介绍Semi-sync的文章。
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 < 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
在Percona的5.1.53和5.5.8版本，开始将RT的统计内置到MySQL Server端。Thanks, Percona.
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查看响应时间统计。 (more…)
从09年12月份MySQL5.5的第一个Release，再到去年12月的第一个GA，MySQL5.5平均一月一个小版本号的速度在默默更新。该版本最重要的特性目前仍是Semi-sync Replication，之前做了一个概述，这里将继续介绍如何安装、配置Semi-sync，后续还将继续介绍其性能和一些基本的代码实现。
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插件：
