防止服务器宕机时MySQL数据丢失的几种方案(2)_MySQL教程

推荐：MySQL Semisynchronous Replication介绍
这篇文章主要介绍了MySQL Semisynchronous Replication介绍,本文讲解了Semisynchronous Replication 定义、,需要的朋友可以参考下 前言 MySQL 5.5版本之前默认的复制是异步(Asynchronous )模式的, MySQL 5.5 以plugins的方式提供了Semisynchronous Replication 模式。

　　为了解决这一个问题，MySQL 5.6之后引入了GTID的概念，即uuid:gid，uuid为MySQL server的uuid，是全局唯一的，而gid则是一个递增的事务id，通过这两个东西，我们就能唯一标示一个记录到binlog中的事务。使用GTID，我们就能非常方便的进行failover的处理。

　　仍然是前面的例子，假设b此时读取到的a最后一个GTID为3E11FA47-71CA-11E1-9E33-C80AA9429562:23，而c的为3E11FA47-71CA-11E1-9E33-C80AA9429562:15，当c指向新的master b的时候，我们通过GTID就可以知道，只要在b中的binlog中找到GTID为3E11FA47-71CA-11E1-9E33-C80AA9429562:15这个event，那么c就可以从它的下一个event的位置开始复制了。虽然查找binlog的方式仍然是顺序查找，稍显低效暴力，但比起我们自己去猜测哪一个filename和position，要方便太多了。

　　google很早也有了一个Global Transaction ID的补丁，不过只是使用的一个递增的整形，LedisDB就借鉴了它的思路来实现failover，只不过google貌似现在也开始逐步迁移到MariaDB上面去了。

　　MariaDB的GTID实现跟MySQL 5.6是不一样的，这点其实比较麻烦，对于我的MySQL工具集go-mysql来说，意味着要写两套不同的代码来处理GTID的情况了。后续是否支持MariaDB再看情况吧。

　　Pseudo GTID

　　GTID虽然是一个好东西，但是仅限于MySQL 5.6+，当前仍然有大部分的业务使用的是5.6之前的版本，笔者的公司就是5.5的，而这些数据库至少长时间也不会升级到5.6的。所以我们仍然需要一套好的机制来选择master binlog的filename以及position。

　　最初，笔者打算研究MHA的实现，它采用的是首先复制relay log来补足缺失的event的方式，但笔者不怎么信任relay log，同时加之MHA采用的是perl，一个让我完全看不懂的语言，所以放弃了继续研究。

　　幸运的是，笔者遇到了orchestrator这个项目，这真的是一个非常神奇的项目，它采用了一种Pseudo GTID的方式，核心代码就是这个

　　复制代码 代码如下:

　　create database if not exists meta;

　　drop event if exists meta.create_pseudo_gtid_view_event;

　　delimiter ;;

　　create event if not exists

　　meta.create_pseudo_gtid_view_event

　　on schedule every 10 second starts current_timestamp

　　on completion preserve

　　enable

　　do

　　begin

　　set @pseudo_gtid := uuid();

　　set @_create_statement := concat('create or replace view meta.pseudo_gtid_view as select \'', @pseudo_gtid, '\' as pseudo_gtid_unique_val from dual');

　　PREPARE st FROM @_create_statement;

　　EXECUTE st;

　　DEALLOCATE PREPARE st;

　　end

　　;;

　　delimiter ;

　　set global event_scheduler := 1;

　　它在MySQL上面创建了一个事件，每隔10s，就将一个uuid写入到一个view里面，而这个是会记录到binlog中的，虽然我们仍然不能像GTID那样直接定位到一个event，但也能定位到一个10s的区间了，这样我们就能在很小的一个区间里面对比两个MySQL的binlog了。

　　继续上面的例子，假设c最后一次出现uuid的位置为s1，我们在b里面找到该uuid，位置为s2，然后依次对比后续的event，如果不一致，则可能出现了问题，停止复制。当遍历到c最后一个binlog event之后，我们就能得到此时b下一个event对应的filename以及position了，然后让c指向这个位置开始复制。

　　使用Pseudo GTID需要slave打开log-slave-update的选项，考虑到GTID也必须打开该选项，所以个人感觉完全可以接受。

　　后续，笔者自己实现的failover工具，将会采用这种Pseudo GTID的方式实现。

　　在《MySQL High Availability》这本书中，作者使用了另一种GTID的做法，每次commit的时候，需要在一个表里面记录gtid，然后就通过这个gtid来找到对应的位置信息，只是这种方式需要业务MySQL客户端的支持，笔者不很喜欢，就不采用了。

　　后记

　　MySQL HA一直是一个水比较深的领域，笔者仅仅列出了一些最近研究的东西，有些相关工具会尽量在go-mysql中实现。

　　更新

　　经过一段时间的思考与研究，笔者又有了很多心得与收获，设计的MySQL HA跟先前有了很多不一样的地方。后来发现，自己设计的这套HA方案，跟facebook这篇文章几乎一样，加之最近跟facebook的人聊天听到他们也正在大力实施，所以感觉自己方向是对了。

　　新的HA，我会完全拥抱GTID，比较这玩意的出现就是为了解决原先replication那一堆问题的，所以我不会考虑非GTID的低版本MySQL了。幸运的是，我们项目已经将MySQL全部升级到5.6，完全支持GTID了。

　　不同于fb那篇文章将mysqlbinlog改造支持semi-sync replication协议，我是将go-mysql的replication库支持semi-sync replication协议，这样就能实时的将MySQL的binlog同步到一台机器上面。这可能就是我和fb方案的唯一区别了。

　　只同步binlog速度铁定比原生slave要快，毕竟少了执行binlog里面event的过程了，而另外真正的slaves，我们仍然使用最原始的同步方式，不使用semi-sync replication。然后我们通过MHA监控整个集群以及进行故障转移处理。

　　以前我总认为MHA不好理解，但其实这是一个非常强大的工具，而且真正看perl，发现也还是看的懂得。MHA已经被很多公司用于生产环境，经受了检验，直接使用绝对比自己写一个要划算。所以后续我也不会考虑zookeeper，考虑自己写agent了。

分享：MySQL延迟关联性能优化方法
这篇文章主要介绍了MySQL延迟关联性能优化方法,本文讲解了延迟关联的背景、延迟关联的分析、延迟关联的解决等内容,需要的朋友可以参考下 【背景】 某业务数据库load 报警异常，cpu usr 达到30-40 ，居高不下。使用工具查看数据库正在执行的sql ，排在前面的大部分是：