当前位置: 首页 > 精选 > 正文

基于 MySQL 多通道主主复制的机房容灾方案

文章中介绍了多种 MySQL 高可用技术,并介绍了根据自身需求选择多通道主主复制技术的过程和注意事项。

背景介绍

在云网融合大数据时代,数据已经成为重要的生产要素。特别是棱镜门、永恒之蓝、汶川大地震这类造成大规模数据丢失和泄漏的人为或自然灾害事件发生后,中国相继出台了一系列的法律法规,对各组织机构的数据安全保护条件进行限定,如 2016 年颁布的《中华人民共和国网络安全法》、 2021 年全国人民代表大会通过的《数据安全法》等。

当发生灾难时,容灾备份能够确保数据不丢失。要实现应用的容灾,一个关键就是通过数据库的实时同步和复制,在 A 地出现机房故障和问题的时候可以平滑快速的迁移到 B 地。虽然这种远程数据复制和同步存在一定的延迟,但是基本可以满足业务连续性的需求。

容灾的基础概述

容灾的定义

容灾是指当数据中心发生各种未知灾难的时候,确保数据不丢失或少丢失,同时 IT 业务系统能够不间断运行或快速切换恢复。

灾难的衡量指标

评估一个灾备系统可靠性的两个重要指标是 RTO 与 RPO。

RTO (Recovery Time Objective) 恢复时间目标。RTO 是指灾难发生后,从系统宕机导致业务停顿之刻开始,到系统恢复至可以支持业务部门运作,业务恢复运营之时,此两点之间的时间。RTO 可简单地描述为企业能容忍的恢复时间。

RPO (Recovery Point Objective) 恢复点目标。RPO 是指灾难发生后,容灾系统能把数据恢复到灾难发生前时间点的数据,它是衡量企业在灾难发生后会丢失多少生产数据的指标。RPO可简单地描述为企业能容忍的最大数据丢失量。

RTO 针对的是服务时间的丢失,RPO 针对的是数据的丢失,两者是衡量容灾系统的两个主要指标,但它们没有必然的关联性。

容灾的等级分类

2007 年 11 月 1 日开始正式实施的国家标准 (GB/T 20988-2007) 是我国灾难备份与恢复行业的第一个国家标准。

等级说明
第 1 级基本级。备份介质场外存,安全保障、 定期验证。
第 2 级备份场地支持。网络和业务处理系统可在预定时间内调配到备份中心。
第 3 级电子传输和部分设备支持。灾备中心配备部分业务处理和网络设备,具备部分通讯链路。
第 4 级电子传输和完整设备支持。数据定时批量传送,网络/系统始终就绪。温备中心模式。
第 5 级实时数据传输及完整设备支持。采用远程复制技术,实现数据实时复制,网络具备自动或集中切换能力,业务处理系统就绪或运行中。
第 6 级数据零丢失和远程集群支持。数据实时备份,零丢失,系统 /应用远程集群,可自动切换,用户同时接入主备中心。

灾难与 RTO、RPO 的关系

灾难恢复能力等级RTORPO
12 天以上1 天至 7 天
224 小时以后1 天至 7 天
312 小时以上数小时至 1 小时
4数小时至 2 天数小时至 1 小时
5数分钟至 2 天0 至 30 分钟
6数分钟0

两地三中心容灾

两地三中心能够组合本地高可用,同城灾备中心,异地灾备中心,提高可用性,提升业务连续性,重点业务多采用“两地三中心”(即生产数据中心、同城灾备中心、异地灾备中心)建设方案。这种模式下,多个数据中心是主备关系,针对灾难的响应与切换周期根据异常情况灵活处理,能够实现更优的 RTO 与 RPO 整体目标。

111

MySQL 常见的主从形式

MySQL 本身就自带有主从复制的功能,解决了几个关键的问题:数据一致性、检查点机制、可靠网络传输等,可以帮助我们实现高可用切换和读写分离。

一主一从

222

一主一从能够提供备库,主库故障后可以进行故障切换,避免数据丢失。

一主多从

333

一主多从常见的主从架构,使用起来简单有效,不仅可以实现 HA,而且还能读写分离,进而提升集群的并发能力。

多主一从

4444

多主一从可以将多个 MySQL 数据库备份到一台存储性能比较好的服务器上,方便统一分析处理。

双主复制

5555

双主复制,也就是互做主从复制,每个 master 既是 master,又是另外一台服务器的 slave。这样任何一方所做的变更,都会通过复制应用到另外一方的数据库中。同一时刻可以只有一个是主,另外一个是备,实例主动维护进行主从切换的时候无需进行特别的配置,秒级切换方便日常升级维护。

级联复制

666

级联复制模式下,部分 slave 的数据同步不连接主节点,而是连接从节点。主节点有太多的从节点,就会损耗一部分性能用于 replication ,这个时候可以让 3~5 个从节点连接主节点,其它从节点作为二级或者三级与从节点连接,这样不仅可以缓解主节点的压力,并且对数据一致性没有负面影响。

两地三中心 MySQL 主从复制

MySQL 常见高可用方案优劣

对比目前主流的数据库高可用方案,都有各自的优势和劣势,但在支持异地容灾方面都不够简单易用:

高可用方案优势劣势
主从 + Keepalived部署简单,没有主实例宕机后选主的问题。一主多从在切换之后,其他从实例需要重新配置连接新主。
MHA支持一主多从、主服务崩溃时不会导致数据不一致。SSH 存在安全隐患,官方不在维护。
组复制 MGR无延迟,数据强一致性强依赖网络,只能用在 GTID 模式下,大事务和 DDL 操作有阻塞风险。
MySQL InnoDB Cluster弥补组复制无法提供具有自动化故障转移功能的中间件。组件多,成熟案例少。
Orchestrator支持一主多从,解决了管理节点的单点问题,支持命令行和 Web 界面管理复制。功能复杂,不方便集成进自有系统。

MySQL 主从初始化消息

通过抓取消息和分析代码,发现 MySQL 从库和主库建立同步通道过程中,分别进行网络连接建立、授权,实例唯一性、时钟、字符集、binlog 配置校验等工作。其中实例唯一性校验过程从库会获取主库的 server id。

7777

MySQL binlog 日志结构

MySQL 的主从复制是基于 binlog 文件,而 binlog 文件是由多个 binlog event 构成,binlog event 的整体结构由 head+data+footer 三部分组成。head 包含产生 event 的数据库实例 server id,在主从复制作为区分 event 是否为自己实例生成的重要依据。

111

之前通过主从初始化消息能够获取主从管道对端主库的 server id,此时和从库从管道内接受的 event 的 server id 进行对比,能够识别该 event 是否是当前对端主库产生的。

两地三中心 MySQL 主从方案 1

两地三中心建设相对容易,日常的演练和数据回流等配置比较繁琐,容易出错。本方案通过机房内建立 MySQL 主主复制,此时主从切换无需繁琐的命令,只需要设置 read_only;同城机房间也是建立主主复制,方便容灾演练回切,无需复杂的配置。同理,与两地三中心 MySQL 也建立主主复制,方便演练和回切。该方案使用原生的 MySQL 复制,成熟度高;未过多引入第三方组件,具备规模化运维潜力。但原生的 MySQL 主从在多条链路存在主主复制时,会出现复制回路问题,导致数据冲突和不一致。

222

两地三中心 MySQL 主从方案 2

为解决复制回路问题,在主机房边界节点实例上,本方案使用上文中根据对端主库 server id 判断是否和 event 的 server id 相同,对 IDC1 边界 MySQL 复制逻辑进行限制,只同步管道内临近主产生的 binlog 日志,级联主日志丢弃,1 个同步管道只同步单台 master 日志,解决回路问题。其他节点无需开启这个功能。

333

边界节点 MySQL 复制逻辑代码补丁

444

本补丁基于社区版 MySQL 5.7.40 升级,修改sys_vars.cc文件,增加 replicate_server_mode 配置项(默认为 0),兼容原有复制模式,配置为 1 时主从同步仅同步管道内对端主产生的 binlog event。

555

修改log_event.cc文件的Log_event::do_shall_skip函数,判断当前 event 的 server_id 和本通道对端主库 master 的 server_id 不相同时忽略,仅同步对端主库产生的 event,避免多通道主主时数据回路的问题。

总结

该 MySQL 数据同步方案优化了 MySQL 本身的日志同步机制,引入多通道主主复制技术,降低了机房容灾演练和回切时数据同步关系调整带的复杂性;每个通道仅同步临近主库 binlog event,解决了数据回路问题,支撑重点业务两地三中心容灾;无需引入第三方 HA,同步等组件,减少了相关软硬件和网络要求;补丁代码量 100 行以内,仅需对主机房边界节点升级,风险可控。具备规模实例运维场景下成熟,低成本,简单可靠的特点,能够和公司一键切换平台快速集成。未来也具备支撑三地五中心等更高等级容灾要求的能力。但该方案不支持多层级联复制,同时也不支持列、记录级等更精细化灵活控制的能力。

相关文章:

MYSQL 主从复制 --- binlog

在 Master 端并不 Care 有多少个 Slave 连上了自己,只要有 Slave 的 IO 线程通过了连接认证,向他请求指定位置之后的 Binary Log 信息,他就会按照该 IO 线程的要求,读取自己的 Binary Log 信息,返回给 Slave 的 IO 线程。默认MySQL是未开启该日志的。如果读压力加大,就需要更多的 slave 来解决,但是如果slave的复制全部从 master 复制,势必会加大 master 的复制IO的压力,所以就出现了级联复制,减轻 master 压力。

MySQL 中 is null 和 =null 的区别

如果 set ANSI_NULLS为 ON 时,表示SQL语句遵循SQL-92标准;如果 set ANSI_NULLS 为 OFF 时,表示不遵从 SQL-92 标准。但SQL-92 标准要求对null的 = 或不等于 (!= ,) 比较取值都为 false,也就是 =null 或者 null,返回的都是false。null 在MySQL中不代表任何值,通过运算符是得不到任何结果的,因此只能用 is null(默认情况)MySQL 中 null 不代表任务实际的值,类似于一个未知数。

MySQL数据库查询语句之组函数,子查询语句

当一个SQL的执行需要借助另一个SQL的执行结果时,则需要进行SQL嵌套,该语法结构称之为子查询。先筛选出符合要求的数据,再对符合要求的数据进行分组时,分组的工作量会被减少,效率更高。先确定从哪张表进行操作-->对表中数据进行分组-->基于分组结果进行查询操作。执行顺序:优先执行小括号内的子SQL,根据子SQL的执行结果再执行外层SQL。执行顺序:from-->where-->group by-->select。执行顺序:from-->group by-->select。

mysql开启可以使用IP有权限访问

为实际的IP地址和你想要设置的密码。请小心操作,并确保你了解每个命令的作用。如果你对此有任何疑问,最好咨询经验丰富的数据库管理员。来设置或修改用户的密码。相反,你需要分两步来完成这个过程:首先创建或修改用户,并设置密码;然后授予相应的权限。用户应该能够从指定的内网IP地址访问MySQL服务器。用户已存在并且你只是想更改其密码或允许从另一个地址访问,使用。在MySQL 8.0及更高版本中,语句的语法有所变化。替换为你的内网IP地址,

雪花算法生成ID、UUID生成ID和MySql自增ID优缺点分析

综上所述,UUID适用于分布式系统和需要保密的场景,雪花ID适用于分布式系统和高并发环境,MySQL自增ID适用于单机系统和高效查询的场景。根据具体的业务需求和系统架构,选择合适的主键类型。通过本文的介绍和对比,希望读者能够更好地理解在MySQL中不推荐使用UUID或者雪花ID作为主键的原因,并能够根据实际情况做出明智的选择。在MySQL中,使用自增整数作为主键是一种常见的做法,因为它具有较小的存储空间、高效的索引和自动增长的特性。然而,具体选择何种主键类型还是要根据具体的业务需求和数据特点来决定。

【小白专用】C# 连接 MySQL 数据库

C# 连接 MySQL 数据库

如何用pthon连接mysql和mongodb数据库【极简版】

发现宝藏 前言 1. 连接mysql 1.1 安装 PyMySQL 1.2 导入 PyMySQL 1.3 建立连接 1.4 创建游标对象 1.5 执行查询 1.6 关闭连接 1.7 完整示例 2. 连接mongodb 2.1 安装 PyMongo 2.2 导入 PyMongo 2.3 建立连接 2.4

MySQL索引优化实战

对于这种varchar(255)的大字段可能会比较占用磁盘空间,可以稍微优化下,比如针对这个字段的前20个 字符建立索引,就是说,对这个字段里的每个值的前20个字符放在索引树里,类似于 KEY index(name(20),age,position)。此时你在where条件里搜索的时候,如果是根据name字段来搜索,那么此时就会先到索引树里根据name 字段的前20个字符去搜索,定位到之后前20个字符的前缀匹配的部分数据之后,再回到聚簇索引提取出来 完整的name字段值进行比对。

《mybatis》--大数据量查询解决方案

之前写百万以及千万的导出数据的时候,对于将数据写道csv文件并压缩这里没有什么大问题了,但是出现了其他问题为:1、我们需要将数据从数据库中拿出来,并且在进行装配的时候出现了一些问题。2、对于整体内存安全来说,如果直接将数据从数据库中拿出来百万级别以上的数据对于内存是非常不友好的。当问题出现比较大的时候会直接触发GC,造成瘫痪。目前开发以及项目测试的是更多的使用mybatis来进行开发的,所以本文章讨论以及解决的的就是如何使用mybaits来解决流式查询并单条处理的问题。

ClickHouse 与mysql等关系型数据库对比

先用一张图帮助理解两者的本质上的区。

Windows安装MySQL及网络配置

向日葵软件是一种远程控制软件,可以让用户在不同设备之间进行远程桌面访问和文件传输。用户可以通过向日葵软件,在任何具有互联网连接的设备上远程控制其他设备,包括计算机、智能手机和平板电脑。用户只需安装向日葵软件,并使用登录凭据连接到目标设备,就可以实时控制目标设备上的屏幕、键盘和鼠标。向日葵软件还提供了一些辅助功能,如文件传输、远程打印和远程会议等。这使得向日葵软件成为一个方便实用的远程协助工具,适用于个人用户、技术支持人员和企业用户等各种场景。

深入理解Mysql事务隔离级别与锁机制

我们的数据库一般都会并发执行多个事务,多个事务可能会并发的对相同的一批数据进行增删改查操作,可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。这些问题的本质都是数据库的多事务并发问题,为了解决多事务并发问题,数据库设计了事务隔离机制、锁机制、MVCC多版本并发控制隔离机制,用一整套机制来解决多事务并发问题。接下来,我们会深入讲解这些机制,让大家彻底理解数据库内部的执行原理。

MySQL是如何保证数据不丢失的?

上篇文章《InnoDB在SQL查询中的关键功能和优化策略》对InnoDB的查询操作和优化事项进行了说明。但是,MySQL作为一个存储数据的产品,怎么确保数据的持久性和不丢失才是最重要的,感兴趣的可以跟随本文一探究竟。

where查询条件的字段顺序打乱会影响命中索引吗?

答案是:不影响我们的where后边条件字段打乱会影响命中索引吗?先来进行下边的实验:可以看到实验结果,where条件字段顺序没有按照索引的字段顺序,依然不影响命中索引。因为Mysql中有查询优化器,会自动优化查询顺序。

MySQL删除会走索引吗

MySQL是关系型数据库管理系统的一种, 网站在进行数据的增删改查的时候,我们往往需要使用 MySQL 数据库。而删除操作就是在 MySQL 数据库中删除指定的数据或者表格的操作。

Linux多种方法安装MySQL

源码安装:优点是安装包比较小,只有十多M,缺点是安装依赖的库多,安装编译时间长,安装步骤复杂容易出错。使用官方编译好的二进制文件安装:优点是安装速度快,安装步骤简单,缺点是安装包很大,300M左右。yum安装。rpm安装。

Linux中mysql 默认安装位置&Linux 安装 MySQL

MySQL在Linux系统上的默认安装位置是目录。这是MySQL服务器的数据目录,包含所有数据库文件。通过检查MySQL二进制文件的路径,我们可以确认MySQL是否正确安装。在目录中,MySQL使用一系列文件和子目录来组织和存储数据。确保理解MySQL数据目录的结构对于管理和维护MySQL数据库至关重要。按照顺序安装即可解决。

MySQL数据库索引以及使用唯一索引实现幂等性

一次和多次请求某一个资源对于资源本身应该具有同样的结果任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

【微服务】mysql + elasticsearch数据双写设计与实现

在很多电商网站中,对商品的搜索要求很高,主要体现在页面快速响应搜索结果。这就对服务端接口响应速度提出了很高的要求。

MySQL中的 增 删 查 改(CRUD)

文章浏览阅读1.8k次,点赞60次,收藏56次。insert into 表名 value(数据,数据),.......;可以单行,多行插入。​为查询结果的列取别名select 表达式/列名as 别名 from 表名;去重:DISTINCTselect distinct 单列/多列 from 表名;会去除查询结果中的重复项(只保留一项)select 条件查询的执行顺序遍历表中的每个记录把当前记录的值带入条件,根据条件进行筛选如果这条记录满足条件,保留并进行列上的表达式的计算如果有 order by 会在所有行都被获取到之后(表​

【MySQL从删库到跑路 | 基础第二篇】——谈谈SQL中的DML语句

详细介绍SQL中的DML语句(增加、修改、删除操作)。

【MySQL基础|第三篇】--- 详谈SQL中的DQL语句

详解MySQL中SQL的基础查询、条件查询、聚合函数、分组查询、排序查询、分页查询。

【MySQL函数篇】—— 字符串函数(超详细)

详细介绍MySQL函数中的字符串函数。

MySQL常用函数集锦 --- 字符串|数值|日期|流程函数总结

主要讲解MySQL中的字符串、日期、数值、流程函数。

详细介绍MySQL中的六种约束

详细介绍MySQL中的六种约束