MySQL主从同步延迟的原因及解决办法

由于历史原因,MySQL复制基于逻辑的二进制日志,而非重做日志。多次被问到何时MySQL能支持基于物理的复制,其实这就看MySQL各位大佬的想法。上次和赖老师脑暴,倏地说道:MySQL会不会来个基于Paxos的redo复制?

物理复制的真正好处不在于正确性,因为基于ROW格式的日志复制也已能完全保证复制的正确性。由于物理日志的写入是在事务执行过程中就不断写入,而二进制日志的写入仅仅在事务提交时。因此物理日志的优势如下所示:

  • 复制架构下,大事务日志提交速度快;
  • 复制架构下,主从数据延迟小;

假设执行了1个小时的某大事务,在最后提交时,只需写入最后提交部分的重做日志(redo log可视为物理日志)。虽然此大事务重做日志写入的总量可能有1G,然而在提交时,数据主从复制仅需将最后一部分日志传输到远程从机,因为之前的重做日志已经在执行的1个小时内不断地同步到从机。

对于二进制日志,由于其写入时间发生在事务提交时,因此假设产生了1G的二进制日志,则需要事务提交时间会包含这1G日志的写入时间。在Oracle中有一种说法,事务的提交速度都是平的,不论事务的大小。这在MySQL数据库中是不成立的。即,MySQL的提交速度取决于事务产生的二进制日志的大小,事务提交的速度不是平的。

更为糟糕的是,MySQL主从复制在大事务下的延迟。同样假设1个大事务在主服务器上执行了1个小时,则需要在最后的提交时间传送到从服务器。主从延迟的时间至少为1个小时,若从服务器执行还需1个小时,则主从复制延迟的最坏情况可能是2个小时。物理复制则不存在这样的限制,原因还是如前所述,事务提交过程中,日志已经在传输和回放。

物理复制虽好,但是也有自己的缺陷,就我自己的实际体验来看:

  • 物理复制下,主机坏块会导致主从服务器都无法启动;相信遇到过此问题的同学不在少数;
  • 此外,做ETL是有困难的,比如怎么将物理日志同步到Hadoop大数据平台呢?

一言以蔽之,对于MySQL数据库来说,任何时刻不允许有大事务执行。若要执行,则将大事务拆成一个个小的子事务来执行。这是最基本心法口诀,但却又和Oracle有着很大不同。总之,气宗、剑宗,本无好坏,学会理解其中的差异,融会贯通方可达风清扬般的致臻境界。

mysql 用主从同步的方法进行读写分离,减轻主服务器的压力的做法现在在业内做的非常普遍。 主从同步基本上能做到实时同步。我从别的网站借用了主从同步的原理图。

在配置好了, 主从同步以后, 主服务器会把更新语句写入binlog,   从服务器的IO 线程(这里要注意, 5.6.3 之前的IO线程仅有一个,5.6.3之后的有多线程去读了,速度自然也就加快了)回去读取主服务器的binlog 并且写到从服务器的Relay log 里面,然后从服务器的 的SQL thread 会一个一个执行 relay log 里面的sql , 进行数据恢复。

relay 就是 传递, relay race 就是接力赛的意思

1. 主从同步的延迟的原因

我们知道, 一个服务器开放N个链接给客户端来连接的, 这样有会有大并发的更新操作, 但是从服务器的里面读取binlog 的线程仅有一个, 当某个SQL在从服务器上执行的时间稍长 或者由于某个SQL要进行锁表就会导致,主服务器的SQL大量积压,未被同步到从服务器里。这就导致了主从不一致, 也就是主从延迟。

2. 主从同步延迟的解决办法

实际上主从同步延迟根本没有什么一招制敌的办法, 因为所有的SQL必须都要在从服务器里面执行一遍,但是主服务器如果不断的有更新操作源源不断的写入, 那么一旦有延迟产生, 那么延迟加重的可能性就会原来越大。 当然我们可以做一些缓解的措施。

  • a. 我们知道因为主服务器要负责更新操作, 他对安全性的要求比从服务器高, 所有有些设置可以修改,比如sync_binlog=1,innodb_flush_log_at_trx_commit = 1 之类的设置,而slave则不需要这么高的数据安全,完全可以讲sync_binlog设置为0或者关闭binlog,innodb_flushlog, innodb_flush_log_at_trx_commit 也 可以设置为0来提高sql的执行效率 这个能很大程度上提高效率。另外就是使用比主库更好的硬件设备作为slave。
  • b. 就是把,一台从服务器当度作为备份使用, 而不提供查询, 那边他的负载下来了, 执行relay log 里面的SQL效率自然就高了。
  • c. 增加从服务器喽,这个目的还是分散读的压力, 从而降低服务器负载。

3. 判断主从延迟的方法

MySQL提供了从服务器状态命令,可以通过 show slave status 进行查看,  比如可以看看Seconds_Behind_Master参数的值来判断,是否有发生主从延时。

其值有这么几种:

NULL - 表示io_thread或是sql_thread有任何一个发生故障,也就是该线程的Running状态是No,而非Yes.
0 - 该值为零,是我们极为渴望看到的情况,表示主从复制状态正常

其它的方法我也没试过, 暂时不做评论

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对我们的支持。如果你想了解更多相关内容请查看下面相关链接

(0)

相关推荐

  • Mysql覆盖索引详解

    概念 如果索引包含所有满足查询需要的数据的索引成为覆盖索引(Covering Index),也就是平时所说的不需要回表操作 判断标准 使用explain,可以通过输出的extra列来判断,对于一个索引覆盖查询,显示为using index,MySQL查询优化器在执行查询前会决定是否有索引覆盖查询 注意 1.覆盖索引也并不适用于任意的索引类型,索引必须存储列的值 2.Hash 和full-text索引不存储值,因此MySQL只能使用B-TREE 3.并且不同的存储引擎实现覆盖索引都是不同的 4.并

  • Mysql通过存储过程分割字符串为数组

    分割字符串为数组需要用到 三个mysql 的函数 : REVERSE(str) 返回颠倒字符顺序的字符串str. SUBSTRING_INDEX(str,delim,count) 返回从字符串str的第count个出现的分隔符delim之后的子串.如果count是正数,返回最后的分隔符到左边(从左边数) 的所有字符.如果count是负数,返回最后的分隔符到右边的所有字符(从右边数). REPLACE(str,from_str,to_str) 返回字符串str,其字符串from_str的所有出现由

  • linux下mysql乱码问题的解决方案

    项目进行到和服务器交互,通过post访问服务器端jsp,jsp访问服务器端mysql数据库,最终返回到客户端的中文出现乱码问题. 在整个流程中,出现错误的原因可能是三个:post未设置编码或者编码不相符合,jdbc出现问题,linux下mysql初始码制问题. 在经过繁琐的排查后,最终确定问题为mysql编码问题.下文介绍如何解决linux下mysql中文乱码问题. 首先进入mysql命令行模式,键入mysql -uroot -p 即可进入.随后键入 SHOW VARIABLES LIKE 'c

  • MySQL执行状态的查看与分析

    当感觉mysql性能出现问题时,通常会先看下当前mysql的执行状态,使用 show processlist 来查看,例如: 其中state状态列信息非常重要,先看下各列含义,然后看下state常用状态 各列的含义 1.id 一个标识,你要kill一个语句的时候使用,例如 mysql> kill 207; 2.user 显示当前用户,如果不是root,这个命令就只显示你权限范围内的sql语句 3.host 显示这个语句是从哪个ip 的哪个端口上发出的,可用来追踪出问题语句的用户 4.db 显示这

  • sql与各个nosql数据库使用场景的讲解

    sql为主干为什么我这样理解: 单从技术角度来说 关系型网格 充分的体现了现实事务 对事务,审计,闪存等等对数据的重视所以如何一些特别主要的数据,一定要放到sql里面.一个系统里面至少有用户信息是重要的数据. 所以sql必须有,而且数据存储的主干 什么时候引入nosql 先看看sql - > sql + nosql的过程. https://www.jb51.net/article/79236.htm 为什么要使用NoSQL 这些nosql? 对java语言而言: redis:用于缓存 - 读速度

  • MySQL group by对单字分组序和多字段分组的方法讲解

    我这里创建了一个 goods 表,先看下里面的数据: mysql> select * from goods; +----+------+------+------------+-------------+------------+ | id | s_id | b_id | goods_name | goods_price | goods_desc | +----+------+------+------------+-------------+------------+ | 1 | 1 | 5

  • 阿里云mysql空间清理的方法

    今天收到阿里云磁盘告警通知,查看了一个100G的空间已达到80G的使用量,如果决定删除2018年1月1日之前的数据,可delete后,再去查看发现磁盘可用空间并没有减少,还飞速的上涨,这可把我急坏了,不一会儿数据库就锁死了. 敢忙找度娘,原来delete后,磁盘不会减少,还得执行一下 OPTIMIZE TABLE +表名,以后找到救星了,可执行此命信不成功,原来是空间不足,数据库存补锁不能执行这条指令,一下没了头绪,如是决定先把服务器暂停,就在暂停时奇迹发生了,可用空间有5G多了,这下可以执行O

  • mysql实现查询数据并根据条件更新到另一张表的方法示例

    本文实例讲述了mysql实现查询数据并根据条件更新到另一张表的方法.分享给大家供大家参考,具体如下: 原本的数据库有3张表 travel_way :旅游线路表,存放线路的具体信息 traveltag :线路标签表,存放线路目的地等信息 tagrelation:标签对应表,存放线路和目的地的对应关系 因为业务逻辑的改变,现在要把它们合并为一张表,把traveltag中的目的地信息插入到travel_way中. 首先获取到所有线路对应的目的地,以线路ID分组,合并目的地到一行,以逗号分隔. 复制代码

  • MySQL数据库中CAST与CONVERT函数实现类型转换的讲解

    MySQL 的CAST()和CONVERT()函数可用来获取一个类型的值,并产生另一个类型的值. 两者具体的语法如下: CAST(value as type); CONVERT(value, type); 就是CAST(xxx AS 类型), CONVERT(xxx,类型). 可以转换的类型是有限制的.这个类型可以是以下值其中的一个: 二进制,同带binary前缀的效果 : BINARY 例如:当使用 like 模糊搜索日期类型的字段时 语句应该是 Create_Time like binary

  • MySQL开发规范与使用技巧总结

    1.命名规范 1.库名.表名.字段名必须使用小写字母,并采用下划线分割. a)MySQL有配置参数lower_case_table_names,不可动态更改,linux系统默认为 0,即库表名以实际情况存储,大小写敏感.如果是1,以小写存储,大小写不敏感.如果是2,以实际情况存储,但以小写比较. b)如果大小写混合使用,可能存在abc,Abc,ABC等多个表共存,容易导致混乱. c)字段名显示区分大小写,但实际使⽤用不区分,即不可以建立两个名字一样但大小写不一样的字段. d)为了统一规范, 库名

随机推荐

其他