MYSQL binlog简述及简单操作

本文深入探讨MySQL二进制日志的主要作用、开启与关闭方法、大小调整、清理策略以及如何利用binlog进行数据恢复。通过实际操作演示,包括配置、检查、关闭binlog、切换日志、清理binlog、使用mysqlbinlog解析日志等步骤,确保数据安全性和恢复能力。

binlog主要两大作用

  1. 高可用
  2. 数据恢复。

如何开启binlog

在my.cnf中配置:log-bin =/home/data/mysql/binlog/mysql-bin

检查是否开启

关闭binlog

my.cnf注销#log-bin =/home/data/mysql/binlog/mysql-bin
需要restart数据库

线上开启binlog

SET sql_log_bin=1|0 (1为开启,0为关闭)
ps:重启数据库失效

切换binlog命令

在mysql中执行flush logs;

修改二进制日志文件(binlog)大小

my.cnf中配置max_binlog_size

binlog 清理

主从模式下需要关闭主从

设置有效天数清理binlog

my.cnf设置expire_logs_days=10;意思是保留10天的binlog滚动清理。

手动清除binlog文件

根据日志文件名:PURGE MASTER LOGS TO ′MySQL-bin.010′;
根据日志时间: PURGE MASTER LOGS BEFORE '2015-03-02 13:00:00';
根据日志天数: PURGE MASTER LOGS BEFORE DATE_SUB(NOW(), INTERVAL 1 DAY);
清除binlog时,注意slave保持一致,不能清除正在复制的日志。

使用mysqlbinlog 进行二进制解析

执行mysqlbinlog可能会遇到的错误
ERROR: Error in Log_event::read_log_event(): ‘Found invalid event in binary log’, data_len: 77, event_type: 19Could not read entry at offset 306709:Error in log format or read error,将最新安装的mysql bin目录放到环境变量中就可以了。或使用全路径: /usr/local/mysql/bin/mysqlbinlog

解析出来的格式(隔离级别rc模式):read-commit

statement -> sql语句
mixed -> dml(记录所有行的变更)  ddl(sql语句)
row  ->记录所有行的变更

rr模式不受此限制

使用binlog恢复数据

恢复条件:

  1. 旧表:全备份sql文件 + binlog日志
  2. 新表:binlog日志(在此binlog录入期间create)

binlog恢复命令

/usr/local/mysql/bin/mysqlbinlog  --no-defaults --base64-output=decode-rows -v mysql-bin.000030 | /usr/local/mysql/bin/mysql -uroot -p

管道符的作用是先执行前面的语句,然后通过后面的语句导入数据库

定点恢复

--start-position 开始点 --stop-position 结束点
--start-date 开始时间 --stop-date  结束时间
eg:
/usr/local/mysql/bin/mysqlbinlog --start-datetime="2015-02-26 20:05:00" --stop-datetime="2015-02-26 20:07:00" mysql-bin.000067 | /usr/local/mysql/bin/mysql -uroot -p

实战手记

在测试之前,需要保证my.cnf中几个关键配置是关闭的,因为如果我打开指定忽略和指定写入binlog的配置,测试表将无法写入binlog,也有一种情况是写入了。但是无法将数据恢复到表中。

#不写入binlog二进制日志中的数据库
#binlog-ignore-db
#写入binlog二进制日志中数据库
#binlog-do-db
#指定只复制哪个库的数据
#replicate-do-db

旧表:全备份sql文件 + binlog日志

1.以前录入的表数据:

create table test(id int,name varchar(20)) engine=innodb charset=utf8;
insert into test(id,name)values(1,'a');
insert into test(id,name)values(233,'bbbb');

2.全备份

/usr/local/mysql/bin/mysqldump -uroot -p --opt --default-character-set=utf8 --extended-insert=false --triggers -R --hex-blob --all-databases --flush-logs   > /tmp/alldb.sql

3.建表
– 录入数据
insert into test(id,name)values(3,'c');
//新开一个binlog日志,现在会生成一个新的binlog日志,下面的操作会记录在新的binlog日志中

mysql> select * from test;
+------+------+
| id   | name |
+------+------+
|    1 | a    |
|    2 | b    |
|    3 | c    |
|    1 | a    |
|  233 | bbbb |
|    3 | c    |
+------+------+
6 rows in set (0.00 sec)

4.切换日志
以便将完整的操作保存到单独的binlog中
flush logs;

5.删除数据

select * from test; #有数据
delete from test;
drop table test;

6.恢复数据
先查看上一个binlog里面的内容:

/usr/local/mysql/bin/mysqlbinlog --no-defaults  --base64-output=decode-rows -v  mysql-bin.000042 | more

7.查看新的binlog里面的内容

/usr/local/mysql/bin/mysqlbinlog --no-defaults  --base64-output=decode-rows -v  mysql-bin.000043 | more

8.先恢复全备份集合:
/usr/local/mysql/bin/mysql -uroot -p </tmp/alldb.sql
9.恢复数据

/usr/local/mysql/bin/mysqlbinlog  --no-defaults --base64-output=decode-rows -v mysql-bin.000042 | /usr/local/mysql/bin/mysql -uroot -p

10.查看表中变化

新表新表:binlog日志(在此binlog录入期间create)

1.切换日志
flush logs;
2.建立新表

create table test2(id int,name varchar(20)) engine=innodb charset=utf8;
insert into test2(id,name)values(1,'a');
insert into test2(id,name)values(2,'b');

3.切换日志
flush logs;
4.之后drop表;
drop table test2;

5.然后利用二进制日志进行恢复

/usr/local/mysql/bin/mysqlbinlog  --no-defaults --base64-output=decode-rows -v mysql-bin.000044 | /usr/local/mysql/bin/mysql -uroot -p

定点恢复

定位:

--start-position #开始点 --stop-position #结束点
--start-date #开始时间 --stop-date  #结束时间

按照起始时间来恢复

/usr/local/mysql/bin/mysqlbinlog --start-datetime="2015-02-26 20:05:00" --stop-datetime="2015-02-26 20:07:00" mysql-bin.000067 | /usr/local/mysql/bin/mysql -uroot -p

按照起始位置来进行恢复

/usr/local/mysql/bin/mysqlbinlog --start-position="20" --stop-position="2000" mysql-bin.000067 | /usr/local/mysql/bin/mysql -uroot -p
<think> 我们正在讨论BinlogMySQL主从复制中的角色。根据引用[1][2][3][4][5],Binlog(二进制日志)是MySQL主从复制的核心组件,它记录了所有对数据库的更改操作。在主从复制架构中,主库(Master)将数据更改事件写入Binlog,从库(Slave)通过IO线程读取这些事件并写入自己的中继日志(Relay Log),然后SQL线程执行这些事件以实现数据同步。 具体来说,Binlog的角色包括: 1. **数据记录**:记录所有更改数据的SQL语句(Statement格式)或行更改(Row格式)[^1][^3]。 2. **数据同步**:从库通过Binlog获取主库的更新,实现异步复制(默认)或半同步复制[^4]。 3. **数据恢复**:可用于时间点恢复(PITR),通过重放Binlog修复数据[^1]。 例如,在配置主从复制时,从库需指定主库的Binlog位置: ```sql CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=678; -- 引用自[^5] ``` Binlog的格式设置(如`binlog_format=ROW`)会影响复制的安全性和效率,Row格式可避免函数调用歧义,保证数据一致性[^3][^4]。 **Binlog工作流程**: 1. 主库事务提交时写入Binlog。 2. 从库IO线程拉取Binlog事件并写入Relay Log。 3. 从库SQL线程解析并执行Relay Log中的事件。 **关键点**: - 异步复制:主库不保证Binlog事件及时传递给从库(可能丢数据)[^4]。 - 半同步复制:主库至少需一个从库确认收到事件才返回成功,提高数据安全性。 §§相关问题§§ 1. Binlog的三种格式(Statement/Row/Mixed)在数据一致性方面有何差异? 2. 如何配置MySQL半同步复制以减少数据丢失风险? 3. 为什么Row格式的Binlog对数据恢复更可靠? 4. MySQL中如何利用Binlog实现误删除数据的快速恢复? </think> ### BinlogMySQL主从复制中的核心角色 Binlog(二进制日志)在MySQL主从复制中扮演着**数据传输中介**和**数据变更记录器**的核心角色,其工作流程可分为以下关键环节: #### 1. **数据变更记录(主库端)** - 所有**数据修改操作**(INSERT/UPDATE/DELETE等)在执行后会被记录为Binlog事件 - 通过三种格式实现: - **Statement**:记录原始SQL语句(可能存在函数执行差异问题) - **Row**:记录受影响行的数据变化(推荐格式,保证一致性) - **Mixed**:混合模式自动切换 - 日志位置由`MASTER_LOG_FILE`和`MASTER_LOG_POS`标识(用于从库同步定位)[^5] #### 2. **数据同步传输(主从交互)** ```mermaid graph LR A[主库事务提交] --> B[写入Binlog] B --> C[Binlog Dump线程] C --> D[从库IO线程] D --> E[写入Relay Log] ``` - **主库线程**:`Binlog Dump线程`主动推送事件(非轮询)[^3] - **从库线程**: - **IO线程**:拉取Binlog写入Relay Log - **SQL线程**:解析Relay Log执行SQL[^2] #### 3. **复制模式控制** | **复制模式** | **Binlog传输机制** | **数据安全性** | |--------------|--------------------------------|---------------------| | 异步复制 | 主库提交即返回(默认模式) | 可能丢数据(主库宕机时)[^4] | | 半同步复制 | 至少一个从库确认后才返回 | RPO≈0(需插件支持) | ```sql -- 配置半同步复制示例(主库) INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; SET GLOBAL rpl_semi_sync_master_enabled=1; ``` #### 4. **关键特性与影响 - **数据一致性**:Row格式消除函数/触发器执行差异(如`RAND()`或`NOW()`)[^3] - **故障恢复**:通过`show master status`获取日志位置实现断点续传[^2] - **性能影响**: - 开启Binlog增加~5%写入负载 - Row格式日志量更大但更安全 > 📌 **设计启示**: > 生产环境建议`binlog_format=ROW` + `半同步复制`,平衡性能与数据可靠性。当主库宕机时,通过`MASTER_LOG_POS`可精确重建数据状态[^1][^4]。 --- ### Binlog的衍生价值 1. **数据恢复**:解析Binlog实现时间点恢复(PITR) ```bash mysqlbinlog --start-position=678 binlog.000001 | mysql -u root ``` 2. **逻辑备份**:配合`mysqldump`实现增量备份[^1] 3. **数据分析**:通过Binlog审计数据变更流水
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值