如何搭建双 M 结构的主从备份?

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
日志服务 SLS,月写入数据量 50GB 1个月
简介: 关于 MySQL 主从搭建,我们在项目中,更常见一种结构是双 M 结构,即两个 MySQL 实例,每个 MySQL 实例互为主备,这样在主节点突然断电或者不可用的时候,slave 节点可以很快切换为 master,架构图如下:在这种结构中,两个 MySQL 实例的地位是平等的,互为对方的主备,我们判断谁是主机谁是从机的方式主要是看 readonly,谁是只读的,那谁就是从机,所以这种情况下,主从切换也很方便,只要修改 readonly 属性即可。接下来我们就来搭建一个 双 M 的主从备份,看看和单纯的 M-S 结 构 的有啥区别。

关于 MySQL 主从搭建,我们在项目中,更常见一种结构是双 M 结构,即两个 MySQL 实例,每个 MySQL 实例互为主备,这样在主节点突然断电或者不可用的时候,slave 节点可以很快切换为 master,架构图如下:

网络异常,图片无法展示
|

在这种结构中,两个 MySQL 实例的地位是平等的,互为对方的主备,我们判断谁是主机谁是从机的方式主要是看 readonly,谁是只读的,那谁就是从机,所以这种情况下,主从切换也很方便,只要修改 readonly 属性即可。

接下来我们就来搭建一个 双 M 的主从备份,看看和单纯的 M-S 结 构 的有啥区别。

1. 准备工作

以下配置基于 Docker。

这里,我们首先准备两台机器:

  • M1:10.3.50.27:33061
  • M2:10.3.50.27:33062

1.1 M1 配置

M1 的配置就三个步骤,比较容易:

1. 授权给 M2 服务器

GRANT REPLICATION SLAVE ON *.* to 'rep1'@'10.3.50.27' identified by '123';
FLUSH PRIVILEGES;

这里表示配置 M2 登录用户名为 rep1,密码为 123,并且必须从 10.3.50.27 这个地址登录,登录成功之后可以操作任意库中的任意表。其中,如果不需要限制登录地址,可以将 IP 地址更换为一个 %

注意,在 MySQL8 里边,这块有一些变化。MySQL8 中 用户创建和授权需要分开,不能像上面那样一步到位,具体方式如下:

CREATE USER `rep1`@`10.3.50.27` IDENTIFIED WITH caching_sha2_password BY 'javaboy.COM';
GRANT Replication Slave ON *.* TO `rep1`@`10.3.50.27`;

2. 修改主库配置文件

开启 binlog ,并设置 server-id ,每次修改配置文件后都要重启 MySQL 服务才会生效

开启 binlog 主要是修改 MySQL 的配置文件 mysqld.cnf,该文件在容器的 /etc/mysql/mysql.conf.d 目录下。

网络异常,图片无法展示
|

针对该配置文件,我们做如下修改:

[mysqld]
# 这个参数表示启用 binlog 功能,并指定 binlog 的存储目录
log-bin=javaboy_logbin
# 设置 binlog_format 格式,注意不要使用 STATEMENT
binlog_format=ROW
# 设置一个 binlog 文件的最大字节
# 设置最大 100MB
max_binlog_size=104857600
# 设置了 binlog 文件的有效期(单位:天)
expire_logs_days = 7
# binlog 日志只记录指定库的更新(配置主从复制的时候会用到)
binlog-do-db=javaboy_db
# binlog 日志不记录指定库的更新(配置主从复制的时候会用到)
#binlog-ignore-db=javaboy_no_db
# 写缓存多少次,刷一次磁盘,默认 0 表示这个操作由操作系统根据自身负载自行决定多久写一次磁盘
# 1 表示每一条事务提交都会立即写磁盘,n 则表示 n 个事务提交才会写磁盘
sync_binlog=0
# 为当前服务取一个唯一的 id(MySQL5.7 开始需要)
server-id=1

各项配置的含义已经在注视中说明了。截图如下:

如下图:

网络异常,图片无法展示
|

  • log-bin:同步的日志路径及文件名,一定注意这个目录要是 MySQL 有权限写入的(我这里是偷懒了,直接放在了下面那个datadir下面)。
  • binlog-do-db:要同步的数据库名,当 从 机连 上 主机后,只有这里配置的数据库才会被同步,其他的不会被同步。
  • server-id: MySQL 在主从环境下的唯一标志符,给个任意数字,注意不能和 M2 重复,因为将来 server-id 用于标志 binlog 是由哪个库产生的,所以主从数据库的 server-id 千万不能一样,不然可能导致主从数据库 binlog 的循环复制问题。
  • 注意 binlog_format 的值为 ROW

配置完成后重启 MySQL 服务端:

docker restart mysql33061

3. 查看 M1 当前二进制日志名和偏移量

这个操作的目的是为了在 M2 启动后,从这个点开始进行数据的恢复:

show master status;

网络异常,图片无法展示
|

至此,M1 配置完成。

1.2 M2 配置

M2 的配置和 M1 一模一样,唯一不同的地方在于,M2 的 mysqld.cnf 这个文件中的 server-id=2,其他都一模一样,我就不重复了。

配置完成后,相当于 M2 现在也是一个主 机,我们在 M2 上也可以执行 show master status; 命令,结果如下:

网络异常,图片无法展示
|

1.3 主从配置

接下来配置 M1 和 M2 分别为对方的主机。

M1 配置

先来配置给 M1 配置吧,执行如下命令设置主机:

change master to master_host='10.3.50.77',master_port=33062,master_user='rep1',master_password='123',master_log_file='javaboy_logbin.000001',master_log_pos=154;

这里配置了主机地址、端口以及从机登录主机的用户名和密码,注意最后两个参数要和 M2 中的保持一致。

注意,由于 MySQL8 密码插件的问题,这个问题同样会给主从配置带来问题,所以在 MySQL8 配置主从上,上面这行命令需要添加 get_master_public_key=1,完整命令如下:

change master to master_host='10.3.50.77',master_port=33062,master_user='rep1',master_password='123',master_log_file='javaboy_logbin.000001',master_log_pos=154,get_master_public_key=1;

3. 启动 slave 进程

start slave;

启动之后查看从机状态:

show slave status\G;

网络异常,图片无法展示
|

4. 查看 slave 的状态

主要是下面两项值都要为为 YES,则表示配置正确:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

至此,配置完成,主机创建库,添加数据,从机会自动同步。

如果这两个有一个不为 YES ,表示主从环境搭建失败,此时可以阅读日志,查看出错的原因,再具体问题具体解决。

M2 配置

接下来再来配置 M2,M2 和 M1 的配置基本上是一致的,change master 中记得把地址和端口写对:

change master to master_host='10.3.50.77',master_port=33061,master_user='rep1',master_password='123',master_log_file='javaboy_logbin.000001',master_log_pos=154;

配置完成后,现在 M1 和 M2 就互为主备了。

1.4 测试

测试分两步:

  • M1 中新建 javaboy_db 库,库中建 user 表,表中插入一条记录,然后查看 M2 中是否将数据同步过来了。
  • M2 中向 user 表中添加一条记录,查看 M1 中是否有对应的值。

经过测试,我们发现没问题,现在可以两边互相同步对方的数据了。

2. 谁主谁从

虽然是双 M 结构,但是在实际应用中还是得分个主从,那么双 M 该怎么分主从呢?

在生产环境中,我们一般会将备份节点设置为 read_only,也就是只读,防止有误操作,当然不用担心设置为 read_onlybinlog 的写入也被阻止,super 用户依然拥有写入权限。

设置全库只读的办法也很简单,首先我们执行如下 SQL 先看看对应变量的值:

show variables like 'read_only';

网络异常,图片无法展示
|

可以看到,默认情况下,read_only 是 OFF,即关闭状态,我们先把它改为 ON,执行如下 SQL:

set global read_only=1;

1 表示 ON,0 表示 OFF,执行结果如下:

网络异常,图片无法展示
|

这个 read_only 对 super 用户无效,所以设置完成后,接下来我们退出来这个会话,然后创建一个不包含 super 权限的用户,用新用户登录,登录成功之后,执行一个插入 SQL,结果如下:

网络异常,图片无法展示
|

可以看到,这个错误信息中说,现在的 MySQL 是只读的(只能查询),不能执行当前 SQL。

如此设置之后,在 master 发生异常需要主从切换的时候再将 slave 临时顶替上来。为了更好的做到主从同步,binlog 的类型建议使用 row 模式

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1天前
|
数据库
【YashanDB 知识库】数据库一主一备部署及一主两备部署时,主备手动切换方法及自动切换配置
**数据库主备切换简介** 在数据库正常或异常情况下,实现主备切换至关重要。若配置不当,主节点故障将影响业务使用,尤其在23.2版本中。原因包括资源紧张或主节点异常。解决方法涵盖手动和自动切换: 1. **一主一备部署**: - **手动切换**:支持Switchover(同步正常时)和Failover(主库损坏时)。 - **自动切换**:启用yasom仲裁选主开关。 2. **一主两备部署**: - 默认最大保护模式,自动切换开启。 需检查并配置自动切换以确保高可用性。经验总结:一主一备默认关闭自动切换,需手动开启;一主两备默认开启。
|
3月前
|
NoSQL 容灾 MongoDB
MongoDB主备副本集方案:两台服务器使用非对称部署的方式实现高可用与容灾备份
在资源受限的情况下,为了实现MongoDB的高可用性,本文探讨了两种在两台服务器上部署MongoDB的方案。方案一是通过主备身份轮换,即一台服务器作为主节点,另一台同时部署备节点和仲裁节点;方案二是利用`priority`设置实现自动主备切换。两者相比,方案二自动化程度更高,适合追求快速故障恢复的场景,而方案一则提供了更多的手动控制选项。文章最后对比了这两种方案与标准三节点副本集的优缺点,指出三节点方案在高可用性和数据一致性方面表现更佳。
263 5
|
7月前
|
消息中间件 NoSQL 中间件
MongoDB多数据中心的主从结构
【7月更文挑战第3天】
74 0
|
7月前
|
消息中间件 NoSQL 中间件
MongoDB主从结构、仲裁节点
【7月更文挑战第2天】
112 0
|
监控 数据库
构建高可用性的数据库架构:主从复制和分区策略
在今天的软件开发领域中,构建高可用性的数据库架构至关重要。数据是应用程序的核心,因此确保数据的持久性、可用性和一致性对于任何规模的应用程序都是至关重要的。在本篇文章中,我们将重点介绍两种常用的数据库高可用性技术:主从复制和分区策略,并讨论如何将它们结合起来构建一个稳定和可靠的数据库架构。
192 0
|
存储 弹性计算 关系型数据库
实践教程之如何对PolarDB-X的存储节点发起备库重搭
PolarDB-X 为了方便用户体验,提供了免费的实验环境,您可以在实验环境里体验 PolarDB-X 的安装部署和各种内核特性。除了免费的实验,PolarDB-X 也提供免费的视频课程,手把手教你玩转 PolarDB-X 分布式数据库。本期实验将指导您如何对PolarDB-X的存储节点发起备库重搭。
|
NoSQL 开发工具 Redis
主从复制-搭建主从结构|学习笔记
快速学习主从复制-搭建主从结构
Openstack-M版(双节点)热迁移记录
Openstack-M版(双节点)热迁移记录
180 0
Openstack-M版(双节点)热迁移记录
|
运维 监控 容灾
知识加油站 | OCP 多集群模式如何实现跨城双机房容灾呢?
之前的文章中,我们为您介绍过 OceanBase 集群的高可用性,戳这里回顾:【OB小蓝科创馆】3分钟揭秘 OceanBase 数据库特性——高可用!OceanBase 集群的高可用部署方案采用了分布式选举、多副本日志同步和节点故障的处理策略,可以通过三地五中心的部署模式,实现地域级容灾。那么当只在两个城市中有机房的时候,如何实现地域级容灾呢?
398 0
|
运维 分布式计算 Hadoop
记一次分布式数据库节点恢复思路
分布式数据库节点恢复思路
193 0

热门文章

最新文章