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

 更新时间:2021年03月26日 14:25:35   作者:AsiaYe  
这篇文章主要介绍了MySQL大库搭建主从的一种思路分享,帮助大家更好的理解和学习使用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文件拷贝到新目录下面,否则搭建主从的时候,会提示无法找到这个文件。

3、改变一下从库的UUID,这个玩意儿在搭建GTID复制的时候需要使用,主从环境不能重复,否则会导致服务不可用,这个UUID的变更,一般是在auto.cnf文件中,这个文件保存的是当前库的UUID值。

4、在从库上reset slave all,然后使用auto_position=1的复制方式搭建主从复制,搭建好主从之后,校验主从数据的一致性。

5、在搭建好的从库上设置read-only选项,禁止从库上直接执行DML操作

以上就是MySQL大库搭建主从的一种思路分享的详细内容,更多关于MySQL大库搭建主从的资料请关注脚本之家其它相关文章!

相关文章

  • MYSQL输入密码后闪退现象的解决方法

    MYSQL输入密码后闪退现象的解决方法

    最近在启动MySQL服务端并输入密后,出现闪退现象,实际上这种问题很常见,下面这篇文章主要给大家介绍了关于MYSQL输入密码后闪退现象的解决方法,文中介绍的非常详细,需要的朋友可以参考下
    2023-05-05
  • Mysql中Insert into xxx on duplicate key update问题

    Mysql中Insert into xxx on duplicate key update问题

    在看代码的过程中碰到了这一用法,不太理解,google了一下。它的意义其实是如果在insert语句末尾制定了on duplicate key update语句的话,则当插入行会导致一个unique索引或者primary key中出现重复值,则执行update中的语句,否则才插入新行
    2012-08-08
  • mysql alter table命令修改表结构实例

    mysql alter table命令修改表结构实例

    这篇文章主要介绍了mysql alter table命令修改表结构实例的相关资料,需要的朋友可以参考下
    2016-10-10
  • mysql建立高效的索引实例分析

    mysql建立高效的索引实例分析

    这篇文章主要介绍了mysql建立高效的索引,结合实例形式分析了mysql建立高效索引的相关实现技巧与相关操作注意事项,需要的朋友可以参考下
    2019-07-07
  • mysql 常用命令集锦(Linux/Windows)

    mysql 常用命令集锦(Linux/Windows)

    这篇文章主要介绍了Linux/Windows系统下mysql 常用的命令,需要的朋友可以参考下
    2014-07-07
  • MySQL细数发生索引失效的情况

    MySQL细数发生索引失效的情况

    本文主要介绍了MySQL导致索引失效的几种情况,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2022-07-07
  • 关于Mysql5.7及8.0版本索引失效情况汇总

    关于Mysql5.7及8.0版本索引失效情况汇总

    这篇文章主要介绍了关于Mysql5.7及8.0版本索引失效情况汇总,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2022-08-08
  • MySQL动态SQL拼接实例详解

    MySQL动态SQL拼接实例详解

    动态SQL呢?首先是SQL语句,是根据条件来拼接SQL,下面这篇文章主要给大家介绍了关于MySQL动态SQL拼接的相关资料,文中通过实例代码介绍的非常详细,需要的朋友可以参考下
    2022-12-12
  • mysql zip 文件安装教程

    mysql zip 文件安装教程

    这篇文章主要为大家详细介绍了mysql zip 文件安装教程,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2018-04-04
  • MySQL中的ALTER EVENT语句的具体使用

    MySQL中的ALTER EVENT语句的具体使用

    EVENT 是一种特殊的数据库对象,它允许你在指定的时间间隔或特定的时间自动执行SQL语句或语句集,本文主要介绍了MySQL中的ALTER EVENT语句的具体使用,感兴趣的可以了解一下
    2024-07-07

最新评论