主从同步设置的重要参数log_slave_updates

本文讨论了在MySQL集群环境中配置主主复制和主从复制时遇到的问题,特别是当从服务器M02尝试更新从M01复制的数据到R01时,数据无法更新的情况。问题原因是log_slave_updates参数未启用。通过调整此参数,可以实现M01和M02之间的主主复制,以及M01和R01之间的主从复制,从而确保数据库架构的正常运行。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

说明:最近部署了mysql的集群环境,详细如下M01和M02为主主复制,M01和R01为主从复制;在测试的过程中发现了以下问题:

1、M01和M02的主主复制是没有问题的(从M01写入数据能同步到M02,从M02写入数据能够同步到M01);

2、主从同步的时候,当从M01写入的时候,数据可以写入到R01;

3、当从M02写入的时候,数据就不能写入到R01;

 

问题的原因:log_slave_updates参数的状态为NO

mysql的官网说明如下:

Normally, a slave does not log to its own binary log any updates that are received from a master server. This option tells the slave to log the updates performed by its SQL thread to its own binary log. For this option to have any effect, the slave must also be started with the --log-bin option to enable binary logging. Prior to MySQL 5.5, the server would not start when using the --log-slave-updates option without also starting the server with the --log-bin option, and would fail with an error; in MySQL 5.5, only a warning is generated. (Bug #44663) --log-slave-updates is used when you want to chain replication servers. For example, you might want to set up replication servers using this arrangement:

A -> B -> C

   

Here, A serves as the master for the slave B, and B serves as the master for the slave C. For this to work, B must be both a master and a slave. You must start both A and B with --log-bin to enable binary logging, and B with the --log-slave-updates option so that updates received from A are logged by B to its binary log. 

a) M01同步从M02同步数据过来的时候,log_slave_updates参数用来控制M01是否把所有的操作写入到binary log,默认的情况下mysql是关闭的;

b) R01数据的更新需要通过读取到M01的binary log才能进行更新,这个时候M01是没有写binary log的,所以当数据从M02写入的时候,R01也就没有更新了。。

 

问题的解决方法:

 

log_slave_updates:默认值为OFF;

Dynamic Variable:NO

 

处理方法:修改/etc/my.cnf,增加一行log_slave_updates=1,重启数据库后就可以了;

 

总结:设置完该参数后,数据库的架构就可以设置成M01和M02为主主同步,R01通过M01进行主从同步;

应用的写操作中M02上面进行,读操作中R01上面进行(如果读操作很多的话,可以在M01上面架设多台只读数据库),当M02发生故障后,系统的写操作自动迁移到M01上面。这种架构基本可以保证大部分公司的应用需求;

<think>我们正在讨论MariaDB多主多从复制中`log_slave_updates`参数的作用。根据引用[1]和引用[4]的信息,我们可以分析:1.**`log_slave_updates`参数的作用**:-当设置为`ON`(或1)时,从库会将从中继日志中执行的事件记录到自己的二进制日志中。-这在多级复制(级联复制)中非常重要,因为从库可能需要作为其他从库的主库。 2. **在MariaDB多主多从复制中的必要性**:-在多主复制中,每个节点既是主库又是从库,因此必须开启`log_slave_updates`(如引用[1]中配置所示),这样它才能将接收到的更新传递到其他节点。-如果不开启,从库执行的事件不会写入二进制日志,其他节点就无法从该节点复制数据。 3. **`log_slave_updates=1`与`log_slave_updates`的区别**:-在MariaDB配置文件中,参数可以有两种写法:-`log_slave_updates`:这等同于`log_slave_updates=ON`,表示开启。-`log_slave_updates=1`:数字1也代表开启(0代表关闭)。-因此,两者在功能上没有区别,只是配置的写法不同。4.**与GTID复制的关系**(参考引用[3][4]):-在MySQL5.6的GTID复制中,必须开启`log_slave_updates`,因为从库需要在二进制日志中记录GTID信息,以便其他从库识别。-但MariaDB10和MySQL5.7改进了GTID实现,不再强制要求开启`log_slave_updates`(引用[3]提到MySQL5.7开启GTID模式后不需要开启`log_slave_updates`参数,MariaDB同理)。 **结论**:-在多主多从复制中,如果节点需要作为其他节点的数据源(即级联复制),必须开启`log_slave_updates`。-配置方式上,`log_slave_updates=1`和`log_slave_updates`(或`log_slave_updates=ON`)效果相同。**配置示例**(参考引用[1]):```ini[mysqld]log-bin=mysql-binlog-slave-updates#或log-slave-updates=1server-id=10```**注意事项**:-开启该参数会增加磁盘I/O(因为从库需要写二进制日志),需确保磁盘性能足够[^4]。-在纯从库(不参与级联)且无GTID的场景下,可关闭此参数以节省资源。 §§相关问题§§1. MariaDB多主复制中如何避免数据冲突?2.如何监控MariaDB复制延迟? 3. GTID复制相对于传统复制有哪些优势?</think>### MariaDB 多主多从复制中 `log_slave_updates=1` 与 `log_slave_updates` 的区别详解 在 MariaDB 多主多从复制架构中,`log_slave_updates` 参数是关键配置项。其两种写法 `log_slave_updates=1` 和 `log_slave_updates` **在功能上完全等价**,都表示开启从库的二进制日志记录功能。区别仅在于语法形式: | **配置写法** | **含义** | **适用场景** | |----------------------|--------------------------------------------------------------------------|----------------------------------| | `log_slave_updates=1` | 显式启用参数(数字`1`表示开启) | 所有 MariaDB 版本 | | `log_slave_updates` | 隐式启用参数(省略值默认为`ON`) | MariaDB 5.5+ / MySQL 5.6+ | | `log_slave_updates=0` | 显式禁用参数(数字`0`表示关闭) | 需要关闭功能的场景 | --- ### 核心作用解析 1. **核心功能** 开启后,从库会将自己执行的中继日志(Relay Log)事件**写入本地二进制日志(Binlog)**。这使得该从库可成为其他从库的主库,实现级联复制[^1]。 2. **多主多从复制的必要性** - 在环形或多主架构中(如双主复制),每个节点既是主库又是从库 - 若不开启此参数,节点接收的更新**不会传递到下级节点**,导致复制链断裂 - 典型配置示例: ```ini [mysqld] server-id = 10 log-bin = mysql-bin log-slave-updates # 或 log-slave-updates=1 ``` 3. **与 GTID 复制的关系** - 在 MySQL 5.6/MariaDB 10.0 的 GTID 复制中,**必须开启**此参数(引用[3][4]) - 否则从库无法在 Binlog 中记录 GTID 信息,导致复制失败 - MySQL 5.7+/MariaDB 10.2+ 优化了 GTID 实现,不再强制依赖此参数[^3] --- ### 性能影响与最佳实践 1. **资源消耗** - ✅ 优势:支持复杂拓扑(如环形、星形复制) - ⚠️ 代价:增加磁盘 I/O(需额外写入 Binlog),在写入密集场景可能成为瓶颈(引用[4]) 2. **配置建议** | **场景** | **推荐配置** | |------------------------------|----------------------------| | 单级主从复制 | 关闭(减少 I/O 开销) | | 多级复制(级联) | 必须开启 | | 多主环形复制 | 必须开启 | | GTID 复制(旧版本) | 必须开启 | 3. **验证方法** 检查参数状态: ```sql SHOW VARIABLES LIKE 'log_slave_updates'; -- 返回 Value = ON 表示生效 ``` --- ### 典型问题解决 **场景**:级联复制中断 **原因**:中间从库未开启 `log_slave_updates` **解决步骤**: 1. 修改配置文件: ```ini [mysqld] log-slave-updates=1 # 显式启用 ``` 2. 重启 MariaDB: ```bash systemctl restart mariadb ``` 3. 重新配置复制链路(引用[2]): ```sql CHANGE MASTER TO MASTER_HOST='192.168.11.31', MASTER_USER='repl_user', MASTER_PASSWORD='secure_pass', MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=358; ``` ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值