MySQL binlog_rows_query_log_events在线设置无效

本文探讨了MySQL 5.7.10版本中binlog_rows_query_log_events参数的作用及使用方法。该参数允许在binlog中记录原始SQL语句,但实测表明,尽管官方文档称其为动态参数,实际应用中却需要重启MySQL服务才能生效。

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

binlog_rows_query_log_events 对binlog_format=row有效,设为true后可以在binary log中记录原始的语句

官方文档显示binlog_rows_query_log_events是动态参数,可以在线设置生效,但是测试中发现只有重启才可以生效

版本信息

22:25:13[test](;)> select version();
+------------+
| version()  |
+------------+
| 5.7.10-log |
+------------+

[root@mysql-bcc03 3309_test]# mysqlbinlog --version
mysqlbinlog Ver 3.4 for linux-glibc2.5 at x86_64

在线变更测试

22:22:32[test](;)> set global binlog_rows_query_log_events=1;
Query OK, 0 rows affected (0.00 sec)

22:24:59[test](;)> update t6 set id=3 where id =2;

# mysqlbinlog -v -v  mysql-bin.000002 --base64-output='decode-rows'
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#171113 22:13:35 server id 10211192  end_log_pos 123 CRC32 0x106f7540   Start: binlog v 4, server v 5.7.10-log created 171113 22:13:35
# at 123
#171113 22:13:35 server id 10211192  end_log_pos 154 CRC32 0xdb6b8ed7   Previous-GTIDs
# [empty]
# at 154
#171113 22:13:48 server id 10211192  end_log_pos 219 CRC32 0x837c9303   GTID    last_committed=0        sequence_number=1
SET @@SESSION.GTID_NEXT= '95bd577a-5fbd-11e7-ab42-fa163eef641d:1'/*!*/;
# at 219
#171113 22:13:48 server id 10211192  end_log_pos 291 CRC32 0x7cffa554   Query   thread_id=6982929       exec_time=0     error_code=0
SET TIMESTAMP=1510582428/*!*/;
SET @@session.pseudo_thread_id=6982929/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1344798720/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 291
#171113 22:13:48 server id 10211192  end_log_pos 336 CRC32 0x73164254   Table_map: `test`.`t6` mapped to number 8329
# at 336
#171113 22:13:48 server id 10211192  end_log_pos 512 CRC32 0xddf3d784   Update_rows: table id 8329 flags: STMT_END_F
### UPDATE `test`.`t6`
### WHERE
###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
### SET
###   @1=3 /* INT meta=0 nullable=1 is_null=0 */

 binlog中显示# [empty]   正常应该是原始语句

测试重启再配置文件中添加global binlog_rows_query_log_events=1,执行同样的操作查看binlog

BEGIN
/*!*/;
# at 776
#171113 22:22:32 server id 10211192  end_log_pos 835 CRC32 0xc7f76055   Rows_query
# update t6 set id=1 where id is null
# at 835
#171113 22:22:32 server id 10211192  end_log_pos 880 CRC32 0x96cc634f   Table_map: `test`.`t6` mapped to number 133
# at 880
#171113 22:22:32 server id 10211192  end_log_pos 922 CRC32 0x68f485cf   Update_rows: table id 133 flags: STMT_END_F
### UPDATE `test`.`t6`
### WHERE
###   @1=NULL /* INT meta=0 nullable=1 is_null=1 */
### SET
###   @1=1 /* INT meta=0 nullable=1 is_null=0 */

总结就是需要重启才可生效(不知道是否是自己遗漏了什么)

<think>好的,用户现在想根据之前生成的binlog_analysis.sql文件找到执行删除操作的账号。之前我已经介绍了如何通过binlog恢复数据,现在需要补充如何追踪操作者账号的信息。首先,我得回忆一下MySQLbinlog中是否记录了执行操作的账号信息。 一般来说,binlog中会记录每个事务的上下文信息,包括时间戳、服务器ID、线程ID等。但是默认情况下,binlog可能不会直接记录用户名和主机信息。不过,如果开启了特定的参数,比如log_bin_trust_function_creators或者binlog_annotate_row_events,可能会有更多的信息。不过这些参数可能不是默认开启的,需要用户确认。 接下来,用户可能需要通过binlog中的信息间接找到账号。比如,通过线程ID(thread_id)结合系统表来查找。在MySQL中,每个连接都有一个线程ID,而performance_schema中的processlist表或者information_schema.processlist可以查看当前连接的线程信息,包括用户和主机。但问题是,binlog中的事件发生时对应的线程ID可能已经不存在了,除非用户当时有记录或者有监控。 另外,用户可能需要检查是否有审计日志(audit log)开启,因为审计日志通常会记录详细的操作信息,包括执行者账号。但如果没有开启审计日志,就需要依赖其他方法。 还有一种情况是,如果数据库使用的是ROW格式的binlog,可能不会直接记录执行者信息,而STATEMENT格式的binlog会记录原始SQL语句,但同样可能不包含用户信息。需要用户确认binlog格式。 总结下来,可能的步骤是:首先检查binlog是否包含用户信息,如果没有,通过线程ID结合历史数据或监控日志找到对应的用户,或者检查是否有审计日志。同时,用户需要确认他们的MySQL配置是否支持记录这些信息,或者是否有其他途径可以追踪账号。 需要注意的是,如果用户的环境没有开启相关日志或监控,可能无法直接通过binlog找到操作账号,这时候可能需要其他方法,比如检查应用程序日志,或者数据库的访问日志等。此外,提醒用户未来如何配置MySQL以便记录这些信息,比如开启审计日志或者调整binlog参数,也是必要的。</think>通过binlog定位操作账号的步骤如下(需满足MySQL特定配置条件): 1. 确认必要信息记录 ```sql SHOW VARIABLES LIKE 'binlog_rows_query_log_events%'; ``` - 若为ON时,binlog会记录原始客户端信息 2. 关键字段解析(在binlog事件头中查找): ```log # at 1234 #240601 14:30:00 server id 1 end_log_pos 1356 CRC32 0xabcd1234 # Thread_id=5 exec_time=0 error_code=0 # User@Host: root[root] @ [192.168.1.100] Id: 5 # Query_time: 0.123 Lock_time: 0.000 Rows_sent: 0 Rows_examined: 0 SET TIMESTAMP=1717216200/*!*/; BEGIN /*!*/; ``` 3. 具体查找步骤: ```bash grep -A 5 "DELETE FROM \`数据库名\`.\`表名\`" binlog_analysis.sql ``` 在找到的DELETE语句上方: - `User@Host` 显示执行账号(格式:用户名[数据库账号] @ 客户端地址) - `Thread_id` 对应连接线程ID 4. 若未直接显示账号: ```sql -- 通过线程ID关联系统表(需在操作发生时存在连接) SELECT * FROM performance_schema.threads WHERE THREAD_ID = [binlog中的thread_id]; -- 或查询历史连接记录(需开启general_log) SELECT * FROM mysql.general_log WHERE thread_id = [thread_id] AND command_type = 'Query'; ``` 5. 审计日志配合查询(需开启审计插件): ```sql SELECT * FROM mysql.audit_log WHERE command_class = 'delete' AND event_time BETWEEN '开始时间' AND '结束时间'; ``` 必要条件说明: 1. 需要满足以下至少一项: - 开启`binlog_rows_query_log_events`(5.6+版本可用) - 启用审计日志(企业版功能) - 开启`init_connect`参数记录登录信息 2. 若使用MySQL 8.0+,可通过以下配置增强追踪: ```ini [mysqld] binlog_metadata=full # 记录完整元数据 log_bin_trust_function_creators=ON ``` 常见限制及解决方法: 1. 若显示`User@Host: root[root] @ localhost []`: - 检查是否通过本地socket连接 - 确认应用使用数据库账号 2. 若只能获取thread_id: - 结合监控系统(如Zabbix)的历史进程列表 - 检查同一时间段的其他SQL操作特征 3. 若账号显示为`[system user]`: - 可能是后台线程或事件调度程序 - 检查是否有定时任务(`SHOW EVENTS`) 预防性配置建议: ```sql -- 开启连接审计(所有版本可用) SET GLOBAL general_log = 'ON'; -- 创建审计表(社区版替代方案) CREATE TABLE cmd_audit ( id INT AUTO_INCREMENT PRIMARY KEY, user_host VARCHAR(256) NOT NULL, event_time DATETIME(6) NOT NULL, command TEXT ) ENGINE=ARCHIVE; DELIMITER // CREATE TRIGGER audit_trigger AFTER INSERT ON mysql.general_log FOR EACH ROW BEGIN INSERT INTO cmd_audit VALUES (NEW.user_host, NOW(6), NEW.argument); END// DELIMITER ; ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值