MySQL是如何实现主备同步

主备同步，也叫主从复制，是MySQL提供的一种高可用的解决方案，保证主备数据一致性的解决方案。

在生产环境中，会有很多不可控因素，例如数据库服务挂了。为了保证应用的高可用，数据库也必须要是高可用的。

因此在生产环境中，都会采用主备同步。在应用的规模不大的情况下，一般会采用一主一备。

除了上面提到的数据库服务挂了，能够快速切换到备库，避免应用的不可用外，采用主备同步还有以下好处：

提升数据库的读并发性，大多数应用都是读比写要多，采用主备同步方案，当使用规模越来越大的时候，可以扩展备库来提升读能力。

备份，主备同步可以得到一份实时的完整的备份数据库。

快速恢复，当主库出错了（比如误删表），通过备库来快速恢复数据。对于规模很大的应用，对于数据恢复速度的容忍性很低的情况，通过配置一台与主库的数据快照相隔半小时的备库，当主库误删表，就可以通过备库和binlog来快速恢复，最多等待半小时。

说了主备同步是什么和好处，下面让我们来了解一下主备同步是怎么实现的。

主备同步的实现原理

我们先来了解一下主备同步的原理，下面以一个update语句来介绍主库与备库间是如何进行同步的。

上图是一个update语句在节点A执行，然后同步到节点B的完整流程图，具体步骤有：

  1. 主库接受到客户端发送的一条update语句，执行内部事务逻辑，同时写binlog。
  2. 备库通过 change master 命令，设置主库的IP、端口、用户名和密码，以及要从哪个位置开始请求 binlog。这个位置包含文件名和偏移量。
  3. 在备库上执行start slave命令，启动两个线程 io_thread 和 sql_thread，其中 io_thread 负责与主机进行连接。
  4. 主库校验完用户名和密码，按照接收到的位置去读取binlog，发给备库。
  5. 备库接收到binlog后，写到本地文件（relay log，中转文件）。
  6. 备库读取中转文件，解析出命令，然后执行。

主备同步的工作原理其实就是一个完全备份加上二进制日志备份的还原。不同的是这个二进制日志的还原操作基本上是实时的。

备库通过两个线程来实现同步：

  • 一个是 I/O 线程，负责读取主库的二进制日志，并将其保存为中继日志。
  • 一个是 SQL 线程，负责执行中继日志。

从上面的流程可以看出，主备同步的关键是binlog

常见的两种主备切换流程

M-S结构

M-S结构，两个节点，一个当主库、一个当备库，不允许两个节点互换角色。

在状态1中，客户端的读写都直接访问节点A，而节点B是A的备库，只是将A的更新都同步过来，到本地执行。这样可以保持节点B和A的数据是相同的。

当需要切换的时候，就切成状态2。这时候客户端读写访问的都是节点B，而节点A是B的备库。

双M结构

双M结构，两个节点，一个当主库，一个当备库，允许两个节点互换角色。

对比前面的M-S结构图，可以发现，双M结构和M-S结构，其实区别只是多了一条线，即节点A和B之间总是互为主备关系。这样在切换的时候就不用再修改主备关系。

双M结构的循环复制问题

在实际生产使用中，多数情况是使用双M结构的。但是，双M结构还有一个问题需要解决。

业务逻辑在节点A执行更新，会生成binlog并同步到节点B。节点B同步完成后，也会生成binlog。（log_slave_updates设置为on，表示备库也会生成binlog）。

当节点A同时也是节点B的备库时，节点B的binlog也会发送给节点A，造成循环复制。

解决办法：

  1. 设置节点的server-id，必须不同，不然不允许设置为主备结构
  2. 备库在接到binlog后重放时，会记录原记录相同的server-id，即谁产生即为谁的。
  3. 每个节点在接受binlog时，会判断server-id，如果是自己的就丢掉。

解决后的流程：

  1. 业务逻辑在节点A执行更新，会生成带有节点A的server-id的binlog。
  2. 节点B接受到节点A发过来的binlog，并执行完成后，会生成带有节点A的server-id的binlog。
  3. 节点A接受到binlog后，发现是自己的，就丢掉。死循环就在这里断掉了。

以上就是MySQL是如何实现主备同步的详细内容，更多关于MySQL 主备同步的资料请关注我们其它相关文章！

赞 (0)

相关推荐

  • 基于Docker如何实现MySQL主从复制详解

    基于Docker如何实现MySQL主从复制详解

    前言 MySQL的主从复制是实现应用的高性能,高可用的基础.对于数据库读操作较密集的应用,通过使数据库请求负载均衡分配到不同MySQL服务器,可有效减轻数据库压力.当遇到MySQL单点故障中,也能在短时间内实现故障切换.本文就MySQL的内建的复制功能进行阐述. 版本 MySQl: 5.7.17 CentOS: 7.4.1708 Docker: 1.13.1 概述 MySQL复制数据流程: 主库在数据更新提交事务之前,将事件异步记录到binlog二进制日志文件中,日志记录完成后存储引擎提交本次事

  • MySQL主从复制延迟原因以及解决方案

    来源:公众号「神谕的暗影长廊」 在异步或半同步的复制结构中,从库出现延迟是一件十分正常的事. 虽出现延迟正常,但是否需要关注,则一般是由业务来评估. 如:从库上有需要较高一致性的读业务,并且要求延迟小于某个值,那么则需要关注. 简单概述一下复制逻辑: 1.主库将对数据库实例的变更记录到binlog中. 2.主库会有binlog dump线程实时监测binlog的变更并将这些新的events推给从库(Master has sent all binlog to slave; waiting for

  • MySql主从复制实现原理及配置

    数据库读写分离对于大型系统或者访问量很高的互联网应用来说,是必不可少的一个重要功能.对于MySQL来说,标准的读写分离是主从模式,一个写节点Master后面跟着多个读节点,读节点的数量取决于系统的压力,通常是1-3个读节点的配置.而一般的读写分离中间件,例如Mycat的读写分离和自动切换机制,需要mysql的主从复制机制配合. 主从配置需要注意的地方 1.主DB server和从DB server数据库的版本一致 2.主DB server和从DB server数据库数据名称一致 3.主DB se

  • Windows下MySQL主从复制的配置方法

    MySQL主从复制允许将来自一个数据库(主数据库)的数据复制到一个或多个数据库(从数据库). 主数据库一般是实时的业务数据写入和更新操作,从数据库常用的读取为主. 主从复制过程: 1.主服务器上面的任何修改都会通过自己的 I/O tread(I/O 线程)保存在二进制日志 Binary log 里面. 2.从服务器上面也启动一个 I/O thread,通过配置好的用户名和密码, 连接到主服务器上面请求读取二进制日志,然后把读取到的二进制日志写到本地的一个Realy log(中继日志)里面. 3.

  • MySQL主从复制与读写分离原理及用法详解

    MySQL主从复制与读写分离原理及用法详解

    本文实例讲述了MySQL主从复制与读写分离原理及用法.分享给大家供大家参考,具体如下: 主从复制 概念 影响MySQL-A数据库的操作,在数据库执行后,都会写入本地的日志系统A中. 假设,实时的将变化了的日志系统中的数据库事件操作,在MYSQL-A的3306端口,通过网络发给MYSQL-B. MYSQL-B收到后,写入本地日志系统B,然后一条条的将数据库事件在数据库中完成. 那么,MYSQL-A的变化,MYSQL-B也会变化,这样就是所谓的MYSQL的复制,即MYSQL replication.

  • Mysql主从复制作用和工作原理详解

    Mysql主从复制作用和工作原理详解

    一.什么是主从复制 主从复制,是用来建立一个和主数据库完全一样的数据库环境,称为从数据库,主数据库一般是准实时的业务数据库.在最常用的mysql数据库中,支持单项.异步赋值.在赋值过程中,一个服务器充当主服务器,而另外一台服务器充当从服务器:此时主服务器会将更新信息写入到一个特定的二进制文件中. 并会维护文件的一个索引用来跟踪日志循环.这个日志可以记录并发送到从服务器的更新中去.当一台从服务器连接到主服务器时,从服务器会通知主服务器从服务器的日志文件中读取最后一次成功更新的位置.然后从服务器会接

  • MYSQL数据库GTID实现主从复制实现(超级方便)

    MYSQL数据库GTID实现主从复制实现(超级方便)

    一.添加Maria源 vi /etc/yum.repos.d/MariaDB.repo 粘贴阿里云的最新mariadb镜像: [mariadb] name = MariaDB baseurl = https://mirrors.aliyun.com/mariadb/yum/10.5/centos7-amd64/ gpgkey=https://mirrors.aliyun.com/mariadb/yum/RPM-GPG-KEY-MariaDB gpgcheck=1 安装新版本的MariaDB yu

  • mysql 主从复制如何跳过报错

    一.传统binlog主从复制,跳过报错方法 mysql> stop slave; mysql> set global sql_slave_skip_counter = 1; mysql> start slave; mysql> show slave status \G 二.GTID主从复制,跳过报错方法 mysql> stop slave: #先关闭slave复制: mysql> change master to ...省略... #配置主从复制: mysql>

  • MySQL是如何实现主备同步

    MySQL是如何实现主备同步

    主备同步,也叫主从复制,是MySQL提供的一种高可用的解决方案,保证主备数据一致性的解决方案. 在生产环境中,会有很多不可控因素,例如数据库服务挂了.为了保证应用的高可用,数据库也必须要是高可用的. 因此在生产环境中,都会采用主备同步.在应用的规模不大的情况下,一般会采用一主一备. 除了上面提到的数据库服务挂了,能够快速切换到备库,避免应用的不可用外,采用主备同步还有以下好处: 提升数据库的读并发性,大多数应用都是读比写要多,采用主备同步方案,当使用规模越来越大的时候,可以扩展备库来提升读能力.

  • MySQL是怎么保证主备一致的

    MySQL是怎么保证主备一致的

    目录 MySQL 主备的基本原理 binlog 的三种格式对比 为什么会有 mixed 格式的 binlog? 循环复制问题 总结: 抛出问题:大家知道 binlog 可以用来归档,也可以用来做主备同步,但它的内容是什么样的呢?为什么备库执行了 binlog 就可以跟主库保持一致了呢? MySQL 主备的基本原理 图 1 MySQL 主备切换流程 在状态 1 中,客户端的读写都直接访问节点 A,而节点 B 是 A 的备库,只是将 A 的更新都同步过来,到本地执行.这样可以保持节点 B 和 A 的

  • 基于mysql+mycat搭建稳定高可用集群负载均衡主备复制读写分离操作

    数据库性能优化普遍采用集群方式,oracle集群软硬件投入昂贵,今天花了一天时间搭建基于mysql的集群环境. 主要思路 简单说,实现mysql主备复制-->利用mycat实现负载均衡. 比较了常用的读写分离方式,推荐mycat,社区活跃,性能稳定. 测试环境 MYSQL版本:Server version: 5.5.53,到官网可以下载WINDWOS安装包. 注意:确保mysql版本为5.5以后,以前版本主备同步配置方式不同. linux实现思路类似,修改my.cnf即可. A主mysql.19

  • Linux下指定mysql数据库数据配置主主同步的实例

    一. 概念: ① 数据库同步  (主从同步 --- 主数据库写的同时 往从服务器写数据)② 数据库同步  (主主同步 --- 两台数据库服务器互相写数据) 二. 举例主主数据库同步服务器配置数据库服务器(A) 主数据库   IP:192.168.1.134数据库服务器(B) 主数据库   IP:192.168.1.138两台服务器同步的用户名为: bravedu    密码: brave123 一.主数据库操作设置(A): ① 创建同步用户名   允许连接的 用户IP地址  (非本机IP) 复制

  • PostgreSQL+Pgpool实现HA主备切换的操作

    PostgreSQL流复制实现HA主备切换 环境说明和主机规划 操作系统 主机名 主机 角色 端口 CentOS 7 master 10.0.0.11 PG-Master 54321 CentOS 7 slave 10.0.0.12 PG-Slave 54321 CentOS 7 pool 10.0.0.13 pgpool 54321 基础环境配置(所有主机操作) 配置HOSTS echo -e "10.0.0.11 master\n10.0.0.12 slave\n10.0.0.13 pool

  • 关于mysql主备切换canal出现的问题解决

    通过配置VIP,在进行主备切换时,出现的报错信息: 1.当主备节点当前binlog文件名称相同时,原主节点的position小于主备切换后的position,出现如下报错: 2020-07-02 15:08:09,332 INFO [destination = 1-236 , address = /192.168.3.100:3306 , EventParser] MysqlConnection:293 | Register slave RegisterSlaveCommandPacket[re

  • MySQL GTID主备不一致的修复方案

    目录 方案一:重建 Replicas 前提条件 优点 缺点 操作步骤 Master Slave 方案二:使用percona-toolkit进行数据修复 前提条件 优点 缺点 操作步骤 背景示例 校验一致性 方案一:重建 Replicas MySQL 5.6及以上版在复制中引入了新的全局事务ID(GTID)支持. 在启用了GTID模式的情况下执行MySQL和MySQL 5.7的备份时,Percona XtraBackup会自动将GTID值存储在xtrabackup_binlog_info中. 该信

  • 基于Docker的Mysql主备搭建的实现步骤

    目录 前期规划: 配置过程: Docker mysql主从配置.我们会在一台centos的虚拟机上,配置mysql主备 前期规划: docker mysql版本 mysql:5.7 docker网络配置,我们会创建名称为mysql的网络,子网掩码为 172.88.0.0/16 docker mysql主对应的容器名称:mysql-master, ip地址:172.88.0.11,映射端口:3307,文件卷配置(配置文件和数据文件持久化)mysql配置文件地址:/usr/local/docker/

  • Docker 环境运行 Mysql 和开启 Binlog 配置主从同步的设置方法

    Docker 环境运行 Mysql 和开启 Binlog 配置主从同步的设置方法

    同一服务器模拟利用 Docker 模拟 Mysql 设置的主从同步设置. 1.运行起来两个 Mysql :masterMysql(主库).slaveMysql(从库),数据库版本 5.7. #拉取镜像 docker pull mysql:5.7 #y运行主.从容器 docker run -p 13306:3306 --name slavemysql -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7 docker run -p 13307:3306 --name

  • postgres主备切换之文件触发方式详解

    本文测试参考PostgresSQL实战一书. 本文档测试环境: 主库IP:192.168.40.130 主机名:postgres 端口:5442 备库IP: 192.168.40.131 主机名:postgreshot 端口:5442 PostgreSQL9.0版本流复制主备切换只能通过创建触发文件方式进行,这一小节将介绍这种主备切换方式,测试环境为一主一备异步流复制环境,postgres上的数据库为主库,postgreshot上的数据库为备库,文件触发方式的手工主备切换主要步骤如下: 1)配置

随机推荐