Binlog日志的三种模式介绍及模式修改

Binlog日志的三种模式介绍

 

一、Binlog日志的三种模式

 

1.1 Statement Level模式

 

每一条修改数据的sql都会记录到master的bin_log中slave在复制的时候sql进程会解析成master端执行过的相同的sql在slave库上再次执行。

 

优点:statement level下的优点首先就是解决了row level下的缺点,不需要记录每一行的变化,较少bin-log日志量,节约IO,提高性能。因为它只需要记录在master上所执行的语句的细节,以及执行语句时候的上下文信息。

 

缺点:由于它是记录执行语句,所以,为了让这些语句在slave端也能正确执行,那么它还必须记录每条语句在执行的时候的一些相关信息,也就是上下文信息,来保证所有语句在slave端能够得到和在master端相同的执行结果。由于mysql更新较快,使mysql的赋值遇到了不小的挑战,自然赋值的时候就会涉及到越复杂的内容,bug也就容易出现。在statement level下,目前就已经发现了不少情况会造成mysql的复制出现问题,主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现。比如:sleep()函数在有些版本中就不能正确赋值,在存储过程中使用了last_insert_id()函数,可能会使slave和master上得到不一致的id等等。由于row level是基于每一行记录的裱花,所以不会出现类似的问题。

 

总结:

Statement level优点:

1、解决了row level的缺点,不需要记录每一行的变化。

2、日志量少,节约IO,从库应用日志块。

Statement level缺点:一些新功能同步可能会有障碍,比如函数、触发器等。

 

1.2 Row Level模式

 

日志中会记录成每一行数据修改的形式,然后在slave端再对相同的数据进行修改。

 

优点:在row level的模式下,bin_log中可以不记录执行的sql语句的上下文信息,仅仅只需要记录哪一条记录被修改,修改成什么样。所以row level的日志内容会非常清楚的记录每一行数据修改的细节,非常容易理解。而且不会出现某些特定情况下的存储过程,或fuction,以及trigger的调用或处罚无法被正确复制的问题

 

缺点:row level模式下,所有的执行语句都会记录到日志中,同时都会以每行记录修改的来记录,这样可能会产生大量的日志内容。

 

总结:

row level的优点:

1、记录详细

2、解决statement level模式无法解决的复制问题。

row level的缺点:日志量大,因为是按行来拆分。

 

1.3 Mixed模式(混合模式)

 

实际上就是前两种模式的结合,在mixed模式下,mysql会根据执行的每一条具体的sql语句来区分对待记录的日志形式,也是在statement和row之间选择一种。

 

新版本中的mysql中对row level模式也做了优化,并不是所有的修改都会以row level来记录,像遇到表结构变更的时候就会以statement模式来记录,如果sql语句确实就是update或者delete等修改数据的语句,那么还是会记录所有行的变更。

 

二、调整binlog日志模式

 

binlog日志默认模式:

Server version: 5.6.17 Source distribution

mysql> show variables like "%binlog_format%";

+---------------+-----------+

| Variable_name | Value     |

+---------------+-----------+

| binlog_format | STATEMENT |

+---------------+-----------+

1 row in set (0.00 sec)

 

方法一:在线修改立即生效

mysql> set global binlog_format='MIXED';

Query OK, 0 rows affected (0.00 sec)

 

退出mysql,查看当前mysql日志模式

 

mysql> show variables like "%binlog_format%";

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | MIXED |

+---------------+-------+

1 row in set (0.00 sec)

 

方法二:在配置文件中参数如下:

[mysqld]

log-bin=/var/lib/mysql/mysql-bin

#binlog_format="ROW"

binlog_format="MIXED"   #开启MIXED模式

#binlog_format="STATEMENT"

 

修改后重启mysql服务日志模式:

mysql> show variables like "%binlog_format%";

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | MIXED |

+---------------+-------+

1 row in set (0.00 sec)

 

三、在日志模式当前为row的模式下,记录日志的形式内容。

mysql> show variables like "%binlog_format%";

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW   |

+---------------+-------+

1 row in set (0.00 sec)

 

[root@i-3vsptbun mysql]# mysqlbinlog --base64-output=decode-rows -v mysql-bin.000011

小结:执行sql部分的sql显示为base64编码格式

#171126 17:35:53 server id 1  end_log_pos 458 Table_map: `boy`.`tomcat1` mapped to number 15

#171126 17:35:53 server id 1  end_log_pos 571 Delete_rows: table id 15 flags: STMT_END_F

### DELETE FROM `boy`.`tomcat1`

### WHERE

###   @1=11

###   @2='huang1'

### DELETE FROM `boy`.`tomcat1`

### WHERE

###   @1=2

###   @2='huang2'

### DELETE FROM `boy`.`tomcat1`

### WHERE

###   @1=3

###   @2='huang3'

###   @2='zhang7'

# at 571

# End of log file

ROLLBACK /* added by mysqlbinlog */;

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

 

<think>嗯,我现在要了解MySQL的binlog三种模式。之前对binlog有点了解,知道它是二进制日志,用来记录数据库的更改,用于复制和恢复数据。不过具体的三种模式可能不太清楚,得仔细想想。 首先,用户提到的三种模式应该是基于不同的记录方式。可能包括基于语句的、基于行的,还有一种混合模式?记得之前好像听过STATEMENT、ROW和MIXED这三种。不过需要确认是否正确,以及每种模式的具体区别和应用场景。 那先从STATEMENT模式开始。这种模式应该是记录SQL语句本身,对吧?比如执行一个UPDATE语句,binlog里就保存这个语句。主从复制的时候,从库重新执行这个SQL。这样做的好处是日志量小,因为一条语句可能影响很多行,只需要记录一条语句。不过可能会有问题,比如使用一些不确定的函数,比如NOW()或者RAND(),主库和从库执行的时间或结果可能不一致,导致数据不一致。 然后是ROW模式。这时候binlog记录的不再是SQL语句,而是每一行数据的变更情况。比如UPDATE修改了10行,binlog里会有这10行修改前后的数据。这样做的好处是更精确,避免了STATEMENT模式中的不确定性问题,但日志量会大很多,尤其是批量操作的时候,比如大量UPDATE或DELETE,日志文件增长很快。另外,从库应用的时候可能需要更多的资源来处理这些行级变化。 第三种模式是MIXED,混合模式。应该是结合了STATEMENT和ROW的优点,根据情况选择使用哪种方式记录。比如一般情况下用STATEMENT,但当遇到可能引起不一致的语句时,自动切换到ROW模式。这样可以减少日志量,同时保证数据一致性。但需要了解什么情况下会触发切换,比如涉及系统函数或者用户自定义函数的时候? 另外,可能还有其他方面需要注意,比如不同模式下的主从同步延迟、存储空间占用、以及排查问题的难易程度。比如ROW模式虽然安全,但日志量大,恢复或同步的时候可能更慢,而STATEMENT模式日志小,但可能有隐藏的问题。 还要考虑版本差异,不同MySQL版本对这三种模式的支持是否有变化。比如某些版本可能推荐使用ROW模式作为默认,或者MIXED模式的具体实现是否有调整。此外,在设置复制的时候,如何选择适合的模式,需要根据业务需求来决定。比如对数据一致性要求高的场景用ROW,对日志量敏感且能控制不确定因素的场景用STATEMENT,而MIXED则是一个折中的选择。 总结一下,三种模式分别是STATEMENT、ROW、MIXED,各自的特点和适用场景需要明确区分。同时,可能还需要提到如何设置和切换这些模式,比如通过修改MySQL配置文件或者动态设置变量。另外,实际应用中的案例或问题,比如在STATEMENT模式下出现的主从不一致问题,如何通过切换到ROW模式来解决,这些都是需要考虑的点。 不过,有没有可能混淆了其他概念?比如binlog格式和复制模式是否有关联?应该没错,binlog的格式确实影响复制的行为。可能还需要补充每种模式的优缺点对比表格,但用户的问题可能不需要那么详细,但回答时应该结构清晰,分点说明。 现在,整理思路,确保每个模式的描述准确,优缺点明确,应用场景合适。可能需要查阅一下官方文档或可靠资料确认细节,比如哪些情况下MIXED会切换模式,或者ROW模式在什么版本成为默认选项等。不过根据现有的知识,应该可以组织成一个清晰的回答。</think>MySQL的`binlog`(二进制日志)有三种记录模式,分别为**STATEMENT**、**ROW**和**MIXED**。不同模式直接影响数据复制的行为、日志大小及数据一致性。以下是逐步说明: --- ### 1. **STATEMENT模式(基于语句的复制,SBR)** - **原理**:记录实际执行的SQL语句(如`UPDATE`、`INSERT`)。 $$ \text{示例:记录} \ UPDATE \ user \ SET \ age=30 \ WHERE \ id=1; $$ - **优点**: - 日志量小(一条SQL可能影响多行,但仅记录一条语句)。 - 兼容性较好(适合简单操作)。 - **缺点**: - **数据可能不一致**:若SQL依赖环境(如`NOW()`、`RAND()`),主从库执行结果可能不同。 - 对特殊语法(如`LOAD_FILE()`)或存储过程支持有限。 - **适用场景**: SQL简单且无不确定性函数的场景,或对日志存储敏感的环境。 --- ### 2. **ROW模式(基于行的复制,RBR)** - **原理**:记录每行数据的变更细节(修改前/后的完整数据)。 $$ \text{示例:记录} \ user表id=1的行,age字段从25改为30。 $$ - **优点**: - **数据一致性高**:避免不确定函数和上下文依赖问题。 - 支持所有SQL操作(如触发器、存储过程)。 - **缺点**: - **日志量大**:批量操作(如`UPDATE`影响百万行)会显著增加日志体积。 - 可读性差(需工具解析具体变更)。 - **适用场景**: 对数据一致性要求高的场景(如金融交易),或涉及复杂逻辑的操作。 --- ### 3. **MIXED模式(混合模式)** - **原理**:默认使用`STATEMENT`,仅在可能引发不一致时自动切换为`ROW`。 $$ \text{示例:普通SQL用STATEMENT记录,含RAND()时自动转ROW。} $$ - **优点**: - 平衡日志量和一致性。 - 减少人工干预(自动选择最优模式)。 - **缺点**: - 规则复杂:需依赖MySQL内部判断何时切换模式。 - 仍有极少数场景可能不一致。 - **适用场景**: 需要兼顾日志效率与一致性的通用场景(MySQL 5.1+默认模式,但后续版本可能调整)。 --- ### **对比总结** | 模式 | 日志大小 | 数据一致性 | 适用场景 | |-----------|----------|------------|------------------------------| | STATEMENT | 小 | 低 | 简单SQL,存储敏感 | | ROW | 大 | 高 | 强一致性需求(如金融) | | MIXED | 中等 | 中高 | 通用场景(默认推荐) | --- ### **设置方法** ```sql -- 查看当前模式 SHOW VARIABLES LIKE 'binlog_format'; -- 动态修改(需权限) SET GLOBAL binlog_format = 'ROW'; -- 可选STATEMENT/MIXED ``` --- ### **注意事项** - **主从一致性**:`STATEMENT`模式需严格避免不确定函数。 - **存储规划**:`ROW`模式需预留更多日志存储空间。 - **版本差异**:MySQL 5.7+默认模式可能因版本而异(建议查阅官方文档)。 通过合理选择模式,可优化复制效率并确保数据可靠性。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

东城绝神

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值