【MySQL】binlog_format以及binlog事务记录分析

MySQL官方对于binlog_format参数的说明：

http://dev.mysql.com/doc/refman/5.5/en/binary-log-setting.html

binlog_format可以动态修改，官网对于动态修改主库配置时提醒谨慎操作，会导致复制关系异常。

【主库flush logs，binlog_format=‘STATEMENT‘】
【从库flush logs，binlog_format=‘MIXED‘】

【主库】
# at 107
#140919 14:17:50 server id 16024  end_log_pos 178       Query   thread_id=13    exec_time=0     error_code=0
SET TIMESTAMP=1411107470/*!*/;
BEGIN
/*!*/;
# at 178
#140919 14:17:50 server id 16024  end_log_pos 281       Query   thread_id=13    exec_time=0     error_code=0
use jiangxu/*!*/;
SET TIMESTAMP=1411107470/*!*/;
delete from t1 where c1 in (50,51,52)
/*!*/;
# at 281
#140919 14:17:50 server id 16024  end_log_pos 353       Query   thread_id=13    exec_time=0     error_code=0
SET TIMESTAMP=1411107470/*!*/;
COMMIT/*!*/;
【从库】
# at 107
#140919 14:17:50 server id 16024  end_log_pos 178       Query   thread_id=13    exec_time=253   error_code=0
SET TIMESTAMP=1411107470/*!*/;
BEGIN
/*!*/;
# at 178
#140919 14:17:50 server id 16024  end_log_pos 281       Query   thread_id=13    exec_time=253   error_code=0
use `jiangxu`/*!*/;
SET TIMESTAMP=1411107470/*!*/;
delete from t1 where c1 in (50,51,52)
/*!*/;
# at 281
#140919 14:17:50 server id 16024  end_log_pos 353       Query   thread_id=13    exec_time=253   error_code=0
SET TIMESTAMP=1411107470/*!*/;
COMMIT/*!*/;

【主库flush logs，binlog_format=‘MIXED‘】
【从库flush logs，binlog_format=‘MIXED‘】

【主库】
# at 107
#140919 14:28:52 server id 16024  end_log_pos 178       Query   thread_id=1     exec_time=0     error_code=0
SET TIMESTAMP=1411108132/*!*/;
BEGIN
/*!*/;
# at 178
#140919 14:28:52 server id 16024  end_log_pos 281       Query   thread_id=1     exec_time=0     error_code=0
use jiangxu/*!*/;
SET TIMESTAMP=1411108132/*!*/;
delete from t1 where c1 in (40,41,42)
/*!*/;
# at 281
#140919 14:28:52 server id 16024  end_log_pos 308       Xid = 14
COMMIT/*!*/;
【从库】
# at 353
#140919 14:28:52 server id 16024  end_log_pos 412       Query   thread_id=1     exec_time=253   error_code=0
SET TIMESTAMP=1411108132/*!*/;
BEGIN
/*!*/;
# at 412
#140919 14:28:52 server id 16024  end_log_pos 515       Query   thread_id=1     exec_time=253   error_code=0
SET TIMESTAMP=1411108132/*!*/;
delete from t1 where c1 in (40,41,42)
/*!*/;
# at 515
#140919 14:28:52 server id 16024  end_log_pos 542       Xid = 25540
COMMIT/*!*/;

【主库flush logs，binlog_format=‘ROW‘】
【从库flush logs，binlog_format=‘MIXED‘】

【主库】
# at 107
#140919 14:41:21 server id 16024  end_log_pos 178       Query   thread_id=1     exec_time=0     error_code=0
SET TIMESTAMP=1411108881/*!*/;
BEGIN
/*!*/;
# at 178
# at 225
#140919 14:41:21 server id 16024  end_log_pos 225       Table_map: `jiangxu`.`t1` mapped to number 33
#140919 14:41:21 server id 16024  end_log_pos 275       Delete_rows: table id 33 flags: STMT_END_F
### DELETE FROM jiangxu.t1
### WHERE
###   @1=30 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘a‘ /* VARSTRING(15) meta=15 nullable=1 is_null=0 */
### DELETE FROM jiangxu.t1
### WHERE
###   @1=31 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘a‘ /* VARSTRING(15) meta=15 nullable=1 is_null=0 */
### DELETE FROM jiangxu.t1
### WHERE
###   @1=32 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘a‘ /* VARSTRING(15) meta=15 nullable=1 is_null=0 */
# at 275
#140919 14:41:21 server id 16024  end_log_pos 302       Xid = 13
COMMIT/*!*/;
【从库】
# at 542
#140919 14:41:21 server id 16024  end_log_pos 601       Query   thread_id=1     exec_time=253   error_code=0
SET TIMESTAMP=1411108881/*!*/;
BEGIN
/*!*/;
# at 601
# at 648
#140919 14:41:21 server id 16024  end_log_pos 648       Table_map: `jiangxu`.`t1` mapped to number 1168
#140919 14:41:21 server id 16024  end_log_pos 698       Delete_rows: table id 1168 flags: STMT_END_F
### DELETE FROM `jiangxu`.`t1`
### WHERE
###   @1=30 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘a‘ /* VARSTRING(15) meta=15 nullable=1 is_null=0 */
### DELETE FROM `jiangxu`.`t1`
### WHERE
###   @1=31 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘a‘ /* VARSTRING(15) meta=15 nullable=1 is_null=0 */
### DELETE FROM `jiangxu`.`t1`
### WHERE
###   @1=32 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘a‘ /* VARSTRING(15) meta=15 nullable=1 is_null=0 */
# at 698
#140919 14:41:21 server id 16024  end_log_pos 725       Xid = 25542
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET [email protected]_COMPLETION_TYPE*/;

【主库flush logs，binlog_format=‘MIXED‘】
【从库flush logs，binlog_format=‘ROW‘】

注意动态修改从库binlog_format因为原session是MIXED，所以需要重建复制关系线程。【主库】
# at 554
#140919 16:44:50 server id 16024  end_log_pos 625       Query   thread_id=3     exec_time=0     error_code=0
SET TIMESTAMP=1411116290/*!*/;
BEGIN
/*!*/;
# at 625
#140919 16:44:50 server id 16024  end_log_pos 728       Query   thread_id=3     exec_time=0     error_code=0
SET TIMESTAMP=1411116290/*!*/;
delete from t1 where c1 in (13,14,15)
/*!*/;
# at 728
#140919 16:44:50 server id 16024  end_log_pos 755       Xid = 44
COMMIT/*!*/;
【从库】
# at 296
#140919 16:44:50 server id 16024  end_log_pos 355       Query   thread_id=3     exec_time=253   error_code=0
SET TIMESTAMP=1411116290/*!*/;
BEGIN
/*!*/;
# at 355
# at 402
#140919 16:44:50 server id 16024  end_log_pos 402       Table_map: `jiangxu`.`t1` mapped to number 1168
#140919 16:44:50 server id 16024  end_log_pos 452       Delete_rows: table id 1168 flags: STMT_END_F
### DELETE FROM `jiangxu`.`t1`
### WHERE
###   @1=13 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘a‘ /* VARSTRING(15) meta=15 nullable=1 is_null=0 */
### DELETE FROM `jiangxu`.`t1`
### WHERE
###   @1=14 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘a‘ /* VARSTRING(15) meta=15 nullable=1 is_null=0 */
### DELETE FROM `jiangxu`.`t1`
### WHERE
###   @1=15 /* INT meta=0 nullable=0 is_null=0 */
###   @2=‘a‘ /* VARSTRING(15) meta=15 nullable=1 is_null=0 */
# at 452
#140919 16:44:50 server id 16024  end_log_pos 479       Xid = 25570
COMMIT/*!*/;

在binlog_format=MIXED时候，哪种改变会被按照ROW进行记录到binlog，参考官方说明：

http://dev.mysql.com/doc/refman/5.5/en/binary-log-mixed.html

所以看得出在MIXED的状态下基本上对于主库的DDL操作无法按照行变化进行记录。

对于行变化的日志记录磁盘IO肯定要比语句复制消耗要大，可以根据架构酌情配置。

时间： 2024-11-07 02:27:13

【MySQL】binlog_format以及binlog事务记录分析的相关文章

Mysql数据库之Binlog日志使用总结

binlog二进制日志对于mysql数据库的重要性有多大,在此就不多说了.下面根据本人的日常操作经历,并结合网上参考资料,对binlog日志使用做一梳理: 一.binlog日志介绍1)什么是binlogbinlog日志用于记录所有更新了数据或者已经潜在更新了数据(例如,没有匹配任何行的一个DELETE)的所有语句.语句以"事件"的形式保存,它描述数据更改. 2)binlog作用因为有了数据更新的binlog,所以可以用于实时备份,与master/slave主从复制结合. 3)和binl

mysql binlog_format row and Statement 比较

两种模式的对比: Statement 优点历史悠久,技术成熟: 产生的 binlog 文件较小: binlog 中包含了所有数据库修改信息,可以据此来审核数据库的安全等情况: binlog 可以用于实时的还原,而不仅仅用于复制: 主从版本可以不一样,从服务器版本可以比主服务器版本高: Statement 缺点: 不是所有的 UPDATE 语句都能被复制,尤其是包含不确定操作的时候: 调用具有不确定因素的 UDF 时复制也可能出现问题: 运用以下函数的语句也不能被复制: * LOAD_FILE(

Mysql主从复制以及常见错误问题分析

Mysql主从复制以及常见错误问题分析一.主从复制简介: 1.mysql主从复制原理: Mysql主从复制的实现,主要依赖于二进制日志来实现,过程主要是根据把主的MySQL 的数据复制到其它主机( Slave )上.在复制过程中,可以理解为一台mysql服充当服务器,而其他的mysql服务器充当从服务器,而这种从服务器可以是一个或者是多个.在主从复制过程中,mysql-master会将更新写入二进制日志,并维护文件的一个索引以跟踪日志循环.开启的二进制,mysql主服务器就会安装你配置的二进制

MySQL · 引擎特性 · InnoDB 事务系统

MySQL · 引擎特性 · InnoDB 事务系统前言关系型数据库的事务机制因其有原子性,一致性等优秀特性深受开发者喜爱,类似的思想已经被应用到很多其他系统上,例如文件系统等.本文主要介绍InnoDB事务子系统,主要包括,事务的启动,事务的提交,事务的回滚,多版本控制,垃圾清理,回滚段以及相应的参数和监控方法.代码主要基于RDS 5.6,部分特性已经开源到AliSQL.事务系统是InnoDB最核心的中控系统,涉及的代码比较多,主要集中在trx目录,read目录以及row目录中的一部分,包括

mysql的innodb中事务日志ib_logfile

mysql的innodb中事务日志ib_logfile事务日志或称redo日志,在mysql中默认以ib_logfile0,ib_logfile1名称存在,可以手工修改参数,调节开启几组日志来服务于当前mysql数据库,mysql采用顺序,循环写方式,每开启一个事务时,会把一些相关信息记录事务日志中(记录对数据文件数据修改的物理位置或叫做偏移量);作用:在系统崩溃重启时,作事务重做:在系统正常时,每次checkpoint时间点,会将之前写入事务应用到数据文件中.引入一个问题:在m/s环境中,in

mysql从库Retrieved_Gtid_Set事务数比Executed_Gtid_Set事务数少的异常情况

今天从库crash重启后出现很有趣的现象: 可以发现: Retrieved_Gtid_Set值显示从库没有接收到部分事务,丢失了部分事务.但是从Executed_Gtid_Set显示从库没有丢失事务. 错误日志: 2017-03-08 10:41:12 118393 [ERROR] /usr/local/mysql/bin/mysqld: Sort aborted: Query execution was interrupted170308 10:55:38 mysqld_safe Number

mysql 5.6 binlog组提交实现原理

mysql 5.6 binlog组提交实现原理 http://blog.itpub.net/15480802/viewspace-1411356 Redo组提交 Redo提交流程大致如下 lock log->mutex write redo log buffer to disk unlock log->mutex fsync Fsync写磁盘耗时较长且不占用log->mutex,也就是其执行期间其他线程可以write log buffer: 假定一次fsync需要10ms,而写buffe

mysql 之主从binlog格式详解

binlog文件记录格式statement.row.rixed三种,5.7之前默认为statement模式,到5.7开始默认为row模式. statement就是语句模式,binlog记录对数据做变动的所有语句,要看binlog记录详细内容可以用mysqlbing查看,现在来对statement模式进行测试: 这里事先创建一个t2表做测试 mysql> show create table t2\G *************************** 1. row **************

【转】由浅入深探究mysql索引结构原理、性能分析与优化

摘要: 第一部分:基础知识第二部分:MYISAM和INNODB索引结构 1.简单介绍B-tree B+ tree树 2.MyisAM索引结构 3.Annode索引结构 4.MyisAM索引与InnoDB索引相比较第三部分:MYSQL优化 1.表数据类型选择 2.sql语句优化 (1) 最左前缀原则 (1.1) 能正确的利用索引 (1.2) 不能正确的利用索引 (1.3) 如果一个查询where子句中确实不需要password列,那就用“补洞”. (1.4) like (2)