MYSQL的读写分离主从延时问题

如何实现 MySQL 的读写分离?

其实很简单,就是基于主从复制架构,简单来说,就搞一个主库,挂多个从库,然后我们就单单只是写主库,然后主库会自动把数据给同步到从库上去。

MySQL 主从复制原理的是啥?

主库将变更写入 binlog 日志,然后从库连接到主库之后,从库有一个 IO 线程,将主库的 binlog 日志拷贝到自己本地,写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog,然后执行 binlog 日志中的内容,也就是在自己本地再次执行一遍 SQL,这样就可以保证自己跟主库的数据是一样的。

这里有一个非常重要的一点,就是从库同步主库数据的过程是串行化的,也就是说主库上并行的操作,在从库上会串行执行。所以这就是一个非常重要的点了,由于从库从主库拷贝日志以及串行执行 SQL 的特点,在高并发场景下,从库的数据一定会比主库慢一些,是有延时的。所以经常出现,刚写入主库的数据可能是读不到的,要过几十毫秒,甚至几百毫秒才能读取到。

而且这里还有另外一个问题,就是如果主库突然宕机,然后恰好数据还没同步到从库,那么有些数据可能在从库上是没有的,有些数据可能就丢失了。

所以 MySQL 实际上在这一块有两个机制,一个是半同步复制,用来解决主库数据丢失问题;一个是并行复制,用来解决主从同步延时问题。

这个所谓半同步复制,也叫 semi-sync 复制,指的就是主库写入 binlog 日志之后,就会将强制此时立即将数据同步到从库,从库将日志写入自己本地的 relay log 之后,接着会返回一个 ack 给主库,主库接收到至少一个从库的 ack 之后才会认为写操作完成了。

所谓并行复制,指的是从库开启多个线程,并行读取 relay log 中不同库的日志,然后并行重放不同库的日志,这是库级别的并行。

MySQL 主从同步延时问题(精华)

以前线上确实处理过因为主从同步延时问题而导致的线上的 bug,属于小型的生产事故。

是这个么场景。有个同学是这样写代码逻辑的。先插入一条数据,再把它查出来,然后更新这条数据。在生产环境高峰期,写并发达到了 2000/s,这个时候,主从复制延时大概是在小几十毫秒。线上会发现,每天总有那么一些数据,我们期望更新一些重要的数据状态,但在高峰期时候却没更新。用户跟客服反馈,而客服就会反馈给我们。

我们通过 MySQL 命令:

show status

查看 Seconds_Behind_Master,可以看到从库复制主库的数据落后了几 ms。

一般来说,如果主从延迟较为严重,有以下解决方案:

  • 分库,将一个主库拆分为多个主库,每个主库的写并发就减少了几倍,此时主从延迟可以忽略不计。
  • 打开 MySQL 支持的并行复制,多个库并行复制。如果说某个库的写入并发就是特别高,单库写并发达到了 2000/s,并行复制还是没意义。
  • 重写代码,写代码的同学,要慎重,插入数据时立马查询可能查不到。
  • 如果确实是存在必须先插入,立马要求就查询到,然后立马就要反过来执行一些操作,对这个查询设置直连主库。不推荐这种方法,你要是这么搞,读写分离的意义就丧失了。

原文地址:https://www.cnblogs.com/windpoplar/p/10926594.html

时间: 2024-07-30 01:32:04

MYSQL的读写分离主从延时问题的相关文章

如何实现 MySQL 的读写分离?MySQL 主从复制原理的是啥?如何解决 MySQL 主从同步的延时问题?

高并发这个阶段,肯定是需要做读写分离的,啥意思?因为实际上大部分的互联网公司,一些网站,或者是 app,其实都是读多写少.所以针对这个情况,就是写一个主库,但是主库挂多个从库,然后从多个从库来读,那不就可以支撑更高的读并发压力了吗? 如何实现 MySQL 的读写分离? 其实很简单,就是基于主从复制架构,简单来说,就搞一个主库,挂多个从库,然后我们就单单只是写主库,然后主库会自动把数据给同步到从库上去. MySQL 主从复制原理的是啥? 主库将变更写入 binlog 日志,然后从库连接到主库之后,

MySQL的读写分离与主从同步数据一致性

有没有做MySQL读写分离?如何实现mysql的读写分离?MySQL主从复制原理的是啥?如何解决mysql主从同步的延时问题? 高并发这个阶段,那肯定是需要做读写分离的,啥意思?因为实际上大部分的互联网公司,一些网站,或者是app,其实都是读多写少.所以针对这个情况,就是写一个主库,但是主库挂多个从库,然后从多个从库来读,那不就可以支撑更高的读并发压力了吗? (1)如何实现mysql的读写分离? 其实很简单,就是基于主从复制架构,简单来说,就搞一个主库,挂多个从库,然后我们就单单只是写主库,然后

搭建MySQL代理服务器实现读写分离+主从同步

实验需求: 1.配置2台MySQL服务器(192.168.100.2,192.168.100.3)+1台代理服务器(192.168.100.1),实现MySQL代理的读写分离. 2.用户只需要访问MySQL代理服务器,实际的SQL查询.写入操作交给后台的2台MySQL服务器来完成. 3.2台MySQL服务器实现主从同步,其中Master服务器允许SQL查询.写入,Slave服务器只允许SQL查询. 一 .MASTER数据库服务器(192.168.100.2)的配置 1.安装软件包(本实验采用My

mysql+mysql_proxy+haproxy+memcache (mysql的读写分离)

参考: http://www.cnblogs.com/xxcn/p/4385412.html http://blog.jobbole.com/94606/ http://www.open-open.com/lib/view/open1413274853450.html 原理:略(下次再写)图片来自:http://www.open-open.com/lib/view/open1413274853450.html 架构: master: 192.168.2.127 slave: 192.168.2.

MySQL的读写分离的几种选择

MySQL的读写分离的几种选择 MySQL主从复制(Master-Slave)与读写分离(MySQL-Proxy)实践 原址如下: http://heylinux.com/archives/1004.html Mysql作为目前世界上使用最广泛的免费数据库,相信所有从事系统运维的工程师都一定接触过.但在实际的生产环境中,由单台Mysql作为独立的数据库是完全不能满足实际需求的,无论是在安全性,高可用性以及高并发等各个方面. 因此,一般来说都是通过 主从复制(Master-Slave)的方式来同步

Amoeba for MySQL的读写分离配置

一.Amoeba概述 1.amoeba简介 Amoeba是一个类似MySQL Proxy的分布式数据库中间代理层软件,是由陈思儒开发的一个开源的java项目.其主要功能包括读写分离,垂直分库,水平分库等,经过测试,发现其功能和稳定性都非常的不错,如果需要构架分布式数据库环境,采用Amoeba是一个不错的方案.目前Amoeba一共包括For aladdin,For MySQL和For Oracle三个版本,本文主要关注For MySQL版本的一个读写分离实现. Amoeba处于在应用和数据库之间,

使用代理软件mysql-proxy实现mysql的读写分离

使用代理软件mysql-proxy实现mysql的读写分离实验:172.16.1.10客户端请求mysql-proxy,判断是写还是读建立两次连接是远程连接,要授予远程连接的权限>use db;>create table test (id int);>insert into test values (10),(100);>grant all on db.* to [email protected]'%' identified by '123';在打开一个终端设置从服务器和主服务器一

利用amoeba实现mysql主从复制读写分离

一般大型网站为了缓解大量的并发访问,会在web端实现负载均衡,但是这是远远不够的.到了数据存储层.数据访问层,如果还是传统的架构,或者只是依靠一台服务器,大量的数据库连接操作,会导致数据库面临崩溃的危险.进而造成数据丢失,后果不堪设想.所以我们会考虑如何减少数据库的连接,一方面进行代码的优化,采用优秀的数据缓存技术如memcached,如果资金丰厚的话,必然会想到假设服务器群,来分担主数据库的压力.今天我们就利用MySQL主从配置,实现读写分离,分散数据库的压力.这种方式,很多网站都有应用,今天

搭建基于MySQL的读写分离工具Amoeba

搭建基于MySQL的读写分离工具Amoeba: Amoeba工具是实现MySQL数据库读写分离的一个工具,前提是基于MySQL主从复制来实现的: 实验环境(虚拟机): 主机 角色 10.10.10.20 多实例加主从复制 10.10.10.30 Amoeba服务器 10.10.10.40 客户端(最后测试使用) 1.首先搭建MySQL的主从复制(不在多提):需要注意的是:在主从库上需要创建一个用户,在主库上创建的用户为amoeba,权限是create,update,insert,delete: