MySQL大库搭建主从的一种思路分享

这个周忙的就像打仗一样，感觉有点被别人牵着鼻子走了，每天都是早出晚归，干不完的活儿，有时候感觉DBA这碗饭真的不好吃，要有强大的抗压能力和心理承受能力。今天下午吃饭的时候，真的感觉整个人快要垮掉了，吃完饭就依然决然的下班了，走在路上，看着下班的人群，心想这不就是正常的下班时间么，为什么我还有种早走惭愧的感觉？可能整个人都被洗脑了吧。

这个周的公众号内容更新也是耽搁了两天，周二那天实在是太累了，就直接休息了。昨晚要走的时候，大概九点多，工作了一天比较累，然后就大脑不听使唤，弄了一个故障，把线上一台环境的账号权限表给删掉了，然后发现那套环境还是个新的，没有进行备份，我了个苍天，当时感觉天都快塌了，幸好我平时有保留变更的习惯，在自己的txt文件里面找到了之前给业务方开过的一些账号权限，花了两个小时给修复了，期间包括测试服务是否可用，同步是否及时等等。回来一看时间，已经是十一点半了，赶紧抓时间写公众号，结果呢，写完的时候已经零点六分了，就索性没有更新公众号。

这种感觉真的很不好，不知道在哪儿看到过一句话，“毁掉一个ITer最好的方式，就是让他忙到没有时间成长”，我现在感觉自己就在这种恶性循环当中，又想起一个哥们儿给我说过的话，“埋头给公司拉车的时候，要时不时抬头看看前方的路。”

希望能够快速调整过来，我相信在北漂的人一定有一些跟我相同的感触，对于忙碌可能大家都有自己的定义，在这一点上我想可能和一些公众号的观众能够实现共鸣^_^。

废话也说了那么多了，光抱怨也解决不了问题，还是把目光放在当下吧，写点儿有用的东西，希望对大家有所帮助，也算是自己的一个整理吧。

大库搭建主从的一种方式

今天早上去公司，遇到了一个问题，就是报警信息中显示一个分布式的集群中的一些主从关系down掉了，也就是从库断开了，然后查看了一下原因，是因为业务方和另外一个同事在同时对主库进行数据导入，而这两个人所做的操作是有依赖关系的，而且都包含大量事务，由于产生了冲突，事务进行了回滚，而从库上发现要回滚的数据已经不存在了，所以就导致了从库的断开。

看到这个问题，我先尝试着修复了一下从库，因为是使用gtid搭建的主从复制，所以就尝试着使用set next gtid的方法修复了一下，具体方法可以在gtid那篇文章中看一下，文章在公众号底部有分类。然后begin;commit;设置自动gtid之后发现修复好了，但是过了大概五分钟，就又不行了，很显然，这个方法不是个长久之计，而业务方那边的数据还有很多没有流进来。最终考虑了各种方案之后，不得已而为之，重新搭建从库。

我查看了一下主库的数据量，大概100G左右吧，我想到的两种直观的方法如下：

1、直接备份在服务器上

2、备份在远程nfs挂载备份机里面

来看这两种方法，服务器本身没有那么多剩余的空间可供使用，强行备份也可以，但是会导致磁盘报警，这肯定不是一个好的方法。况且要是使用xtrabackup的方法去搞，apply log和copy back这两步花费的时间相当长。

再来看远程nfs备份机，备份机容量很大，解决了磁盘问题，但是远程传输需要的带宽是无法提供的，如果并行进行备份，那么带宽肯定是不够的，并发的备份进程都会比较慢，保守估计5套主从应该需要8个小时左右。

那么怎么办呢？这里使用了一种比较粗暴的方法，直接跟业务方沟通，暂时把服务停了，打通了两个机器的ssh互信，配置了scp工具，直接通过物理文件拷贝的方式给吧文件复制到从库去，也不进行压缩了，因为100G的文件压缩和解压需要大量的时间。这样做的好处有下面几个：

第一：各个备份之间解耦合，不受其他环境的影响。

第二：可以通过机器之间的带宽导入主库上的原生文件到从库，能够保证数据的完全一致。

第三：时间比较快

于是就这么做了，大概看了一下，100G的文件scp拷贝的话大概就17分钟左右，这样就解决了备份时间长的问题。并行5个窗口，互不影响，也就30分钟左右，5套环境的数据就过去了。现在主库和从库的数据已经完全一致了，现在开始搭建从库，需要做的事情有以下几个：

1、将从库中原来的my.cnf文件替换拷贝过来的主库的my.cnf文件，否则server_id将会重复，导致搭建主从报错。

2、将从库中原来的slave-relay-log.index文件拷贝到新目录下面，否则搭建主从的时候，会提示无法找到这个文件。