mysql flush binlogs_mysqlbinlog 技巧

常用命令

1. 解析 binlog 排查问题

如果只是解析出来查看,可以加 --base64-output=decode-rows 不显示行格式的内容:

mysqlbinlog --no-defaults -vv --base64-output=decode-rows mysql-bin.000201

2. 解析指定 GTID 的事务

用来分析某个事务做了什么:

mysqlbinlog --no-defaults -vv --base64-output=decode-rows --include-gtids='b0ca6715-7554-11ea-a684-02000aba3dad:614037' mysql-bin.000199

3. 解析指定范围的 binlog

a. 时间范围

--start-datetime、--stop-datetime 解析出指定时间范围内的 binlog,这个只适合粗略的解析,不精准,因此不要用来回放 binlog。有个小技巧:如果只能确定大概的时间范围,而且不确定在哪个 binlog 中,可以直接解析多个 binlog。比如大概在 11:20-12:00 内做了个表删除操作,但这个时间内有多个 binlog,可以这样:

mysqlbinlog --no-defaults -vv --base64-output=decode-rows --start-datetime='2020-08-18 11:20:00' --stop-datetime='2020-08-18 12:00:00' mysql-bin.000203 mysql-bin.000204 mysql-bin.000205

b. 偏移量范围

--start-position、--stop-position 解析 binlog 指定偏移量范围内的 binlog。如果同时指定了 --start-position 和 --stop-position,并且是解析多个 binlog,则 --start-position 只对第一个 binlog 生效,--stop-position 只对最后一个 binlog 生效。

这个常用场景是:已经解析过一次 binlog 并取得目标事务的 起始 postion 后,精确的解析这一段 binlog:

mysqlbinlog --no-defaults -vv --base64-output=decode-rows --start-position='537' --stop-position='945' mysql-bin.000204

# at 537 "起始位置是 GTID event 前的这个 position"

#200818 11:29:03 server id 3 end_log_pos 602 CRC32 0x7f07dd8c GTID last_committed=1 sequence_number=2 rbr_only=yes

/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

SET @@SESSION.GTID_NEXT= 'b0ca6715-7554-11ea-a684-02000aba3dad:614061'/*!*/;

...

...

#200818 11:29:03 server id 3 end_log_pos 945 CRC32 0xedf2b011 Query thread_id=3 exec_time=0 error_code=0 SET TIMESTAMP=1597721343/*!*/;

COMMIT /*!*/;

# at 945 "结束位置是 COMMIT event 后的这个 position"

c. GTID 范围

--include-gtids、--exclude-gtids 详细看参数解释。

4. 回放 binlog

回放一定不能加 --base64-output=decode-rows 参数,因为不会解析出行格式(这是binlog真正有效的部分);

回放也可以用上面指定范围的参数;

解析 binlog 回放到本实例,不需要修改 server id,但要注意 GTID 是否已存在;

GTID 已经存在,回放不会报错,但也不会真正回放这些事务,可以通过 --skip-gtids 参数跳过 GTID 的限制;

mysqlbinlog --no-defaults --skip-gtids mysql-bin.000203 | mysql -S /data/mysql/data/3306/mysqld.sock -proot

参数解释

1. --no-defaults

可以避免 my.cnf 里配了 [client] 某些 mysqlbinlog 没有的参数导致 mysqlbinlog 失败

2. -v

不加,只显示行格式(即那一串字符串),无法得到伪SQL:

0b2194899e95

加 -v,从行格式中重建伪SQL(带注释),不显示 binlog_rows_query_log_events 参数效果:

0b2194899e95

加 -vv,从行格式中重建伪SQL并添加字段数据类型的注释,可以显示 binlog_rows_query_log_events 参数效果:

0b2194899e95

3. 加 --base64-output=decode-rows

不显示行格式,如果同时加 -v 参数,可以从行格式中解码为带注释的伪SQL:

0b2194899e95

4. --skip-gtids

不保留 GTID 事件信息,这样回放 binlog 时会跟执行新事物一样,生成新的 GTID。对比如下:

0b2194899e95

5. --include-gtids

只解析出指定的 GTID 的事务:

[root@localhost 3306]# mysqlbinlog --no-defaults -vv --base64-output=decode-rows \

> --include-gtids='b0ca6715-7554-11ea-a684-02000aba3dad:614037-614040' mysql-bin.000199 |grep GTID

#200807 17:32:17 server id 2 end_log_pos 194 CRC32 0xc840be04 Previous-GTIDs

#200807 17:32:17 server id 2 end_log_pos 3818435 CRC32 0x9fdea913 GTID last_committed=3 sequence_number=5 rbr_only=yes

SET @@SESSION.GTID_NEXT= 'b0ca6715-7554-11ea-a684-02000aba3dad:614037'/*!*/;

#200807 17:32:17 server id 2 end_log_pos 5726909 CRC32 0x51b51cc1 GTID last_committed=4 sequence_number=6 rbr_only=yes

SET @@SESSION.GTID_NEXT= 'b0ca6715-7554-11ea-a684-02000aba3dad:614038'/*!*/;

#200807 17:32:17 server id 2 end_log_pos 5727523 CRC32 0x758852f1 GTID last_committed=6 sequence_number=7 rbr_only=yes

SET @@SESSION.GTID_NEXT= 'b0ca6715-7554-11ea-a684-02000aba3dad:614039'/*!*/;

#200807 17:32:17 server id 2 end_log_pos 7635997 CRC32 0x47c43f83 GTID last_committed=6 sequence_number=8 rbr_only=yes

SET @@SESSION.GTID_NEXT= 'b0ca6715-7554-11ea-a684-02000aba3dad:614040'/*!*/;

SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;

6. --exclude-gtids

不解析指定的 GTID 的事务

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: innodb_flush_log_at_trx_commit 是 MySQL 中 InnoDB 引擎的一个参数。它控制事务提交时日志缓冲区的刷新频率。当该参数设置为 1 时,每次事务提交都会将日志缓冲区刷新到磁盘上,这样可以保证事务的 ACID 特性。如果该参数设置为 0 或 2,则日志缓冲区可能不会立即刷新到磁盘上,这样可以提高性能,但会增加事务数据丢失的风险。 ### 回答2: innodb_flush_log_at_trx_commit 参数用于控制InnoDB存储引擎的日志刷新策略。其含义如下: 1. 参数值为0:表示将日志缓存在内存中,每秒将日志批量刷新到磁盘上。这种设置可以提高写入性能,但在断电等意外情况下可能会造成数据丢失。 2. 参数值为1:表示每次事务提交时都将日志立即刷新到磁盘上。这种设置可以保证在发生故障时不会丢失任何事务的数据,但会对性能产生一定的影响。 3. 参数值为2:表示将日志缓存在内存中,每秒将日志立即刷新到磁盘上。这种设置可以兼顾写入性能和数据的持久性,是默认的值,也是推荐的配置。 当需要强制保证数据完整性和一致性时,可以将该参数设置为1。而在一些对数据实时性要求较高的场景下,可以将该参数设置为0以提高写入性能,但这样会增加数据丢失的风险。对于一般的应用场景,推荐使用默认值2。 需要注意的是,innodb_flush_log_at_trx_commit 参数对事务日志的刷盘行为进行控制,而不是控制数据的持久化。InnoDB存储引擎通过redo log来保证事务的持久性,而innodb_flush_log_at_trx_commit参数决定了什么时候将日志持久化到磁盘,从而影响了事务的持久性保证和写入性能。 ### 回答3: innodb_flush_log_at_trx_commit是MySQL InnoDB存储引擎的一个参数。 innodb_flush_log_at_trx_commit参数的含义是控制InnoDB存储引擎在事务提交时将事务日志(redo log)写入磁盘的时机。 该参数有三个可选值: 1. 0:表示事务提交时不立即将事务日志写入磁盘,而是将日志写入操作系统缓存,然后由操作系统根据自己的策略异步写入磁盘。这种方式具有最高的性能,但最小的数据持久性,即在数据库崩溃时可能会丢失一部分事务数据。 2. 1:表示默认值,事务提交时将事务日志立即写入磁盘。这种方式具有较高的数据持久性,即数据库崩溃时只会丢失最后一次提交的事务数据。但写入磁盘的操作会增加IO的开销,可能会影响系统的性能。 3. 2:表示事务提交时将事务日志先写入操作系统缓存,并标记为需要每秒写入磁盘(写back校对点),然后由后台线程按照每秒一次的频率将缓存中的日志写入磁盘。这种方式牺牲了一部分数据的持久性,但在性能和数据持久性之间做了平衡。 根据应用的需求和对数据持久性的要求,可以调整innodb_flush_log_at_trx_commit参数的值,以达到最佳的性能和数据安全性的平衡。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值