binlog_error_action测试

最新推荐文章于 2024-01-04 18:32:51 发布
最新推荐文章于 2024-01-04 18:32:51 发布
阅读量1.1k 收藏 1
点赞数
分类专栏： MySQL 文章标签： mysql 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ianhol/article/details/51580889
版权

binlog_error_action测试

 

场景一：磁盘空间满，导致binlog无法写入

准备测试环境:

主机

数据库实例

角色

Sip

Binlog_format

10.186.24.105

Test1

Master

10.186.24.224

Row

10.186.24.106

Test2

Slave

10.186.24.223

Row

刷盘环境

准备溢出盘：

挂载test1的binlog目录到/disk_test_bea

当binlog_error_action=ignore_error时：

当前binlog所处盘状态：

从sip利用sysbench写入数据

一直卡在这里不动，此时的磁盘占用如下：

无法再写入数据，SQL被阻塞：

主从未发生不一致现象。umount后可正常插入数据

：

结论

磁盘空间满与binlog_error_action两者关联度不高。

场景二：发生抢盘操作

环境准备测试环境：

主机

数据库实例

角色

Sip

共享存储设备号

192.168.59.138

Test1

Master

192.168.59.111

Sdc

192.168.59.139

Test2

Slave

192.168.59.112

Sdc

刷盘环境

测试时的相关资源：

共享存储在138上的设备号：

[root@node2 ianhol]# ll /dev/disk/by-path/

total 0

lrwxrwxrwx. 1 root root  9 Jun 3 10:46 ip-192.168.59.139:3260-iscsi-iqn.2016-04.dev.iscsi-target:iscsidisk2-lun-1-> ../../sdc

共享存储在139上的设备号：

[root@node3 ianhol]# ll /dev/disk/by-path/

total 0

lrwxrwxrwx. 1 root root  9 Jun 3 10:46 ip-192.168.59.139:3260-iscsi-iqn.2016-04.dev.iscsi-target:iscsidisk2-lun-1-> ../../sdc

139上的抢占测试脚本：

[root@machine2 ~]# cat test.sh

#!/bin/bash

 

PHASE=test

exit_on_error(){

    echo $PHASE: $1;

    exit 1;

}

umount /dev/sdc

sg_persist -o -n -C -K 0x1 -d /dev/sdc

sg_persist -n -o -I -S 0x1 -d /dev/sdc

sg_persist -n -o -P -T 5 -K 0x1 -S 0x2 -d /dev/sdc

mount /dev/sdc /mnt/test

 

echo '-----------------------------------------'

sg_persist -n -i -k -d /dev/sdc

sg_persist -n -i -r -d /dev/sdc

 

echo '-----------------------------------------'

for i in {1..10}

do

    mysql -h192.168.59.111 -uianhol -pyoung -P13306 test -e "insert into test values($i)";

    if [ $? != 0 ]

    then

        exit_on_error ERROR

    fi

    echo "sleep $i - 1s";

    sleep 1

done

 

138重新抢占的脚本：

[root@machine1 ~]# cat test.sh

#!/bin/bash

 

umount /dev/sdc

sg_persist -o -n -C -K 0x1 -d /dev/sdc

sg_persist -n -o -I -S 0x1 -d /dev/sdc

echo '-----------------'

sleep 1

sg_persist -n -o -P -T 5 -K 0x1 -S 0x2 -d /dev/sdc

sleep 1

echo '-----------------'

sg_persist -n -i -k -d /dev/sdc

sg_persist -n -i -r -d /dev/sdc

echo '-----------------'

mount /dev/sdc /usr/local/mysql/binlog

 

在138注册sdc

[root@node2 data]# sg_persist -n -o -I -S0x1 -d /dev/sdc

在138预留sdd

[root@node2 data]# sg_persist -n -o -R -T 5-K 0x1 -d /dev/sdc

查看注册预留状态：

[root@node2 data]# sg_persist -n -i -k -d/dev/sdc

  PRgeneration=0x1, 1 registered reservation key follows:

0x1

[root@node2 data]# sg_persist -n -i -r -d/dev/sdc

  PRgeneration=0x1, Reservation follows:

   Key=0x1

scope:LU_SCOPE,  type: Write Exclusive,registrants only

在139上查看注册预留状态：

[root@node3 ~]# sg_persist -n -i -k -d/dev/sdc

  PRgeneration=0x1, 1 registered reservation key follows:

   0x1

[root@node3 ~]# sg_persist -n -i -r -d/dev/sdc

  PRgeneration=0x1, Reservation follows:

   Key=0x1

scope:LU_SCOPE,  type: Write Exclusive,registrants only

查看binlog目录挂载状态：

[root@node2 ianhol]# df -h

Filesystem      Size Used Avail Use% Mounted on

/dev/sda2        18G 4.1G   13G  25% /

tmpfs           931M   84K 931M   1% /dev/shm

/dev/sda1       291M  40M  237M  15% /boot

/dev/sdc         20G 172M   19G   1% /usr/local/mysql/binlog

 

 

 

查看主从状态：

当binlog_error_action=ignore_error时

139运行抢占脚本：

打印信息如下

抢盘成功

139端操作：

138端操作：

尝试再次插入数据：可成功插入数据

再次返回139端操作：发现数据没有同步

此时的binlog为只读：

kill掉MySQL进程并重新抢回共享存储：

启动MySQL，发现master在binlog文件只读时插入的数据已落盘，binlog文件不包含这些数据。并且binlog损坏。

观察从机复制情况，报如下错误：

删除掉多余的脏数据，删除旧binlog重启MySQL，从机清空binlog与relaylog，重新搭建主从。

结论

验证表明：在binlog_error_action的模式为IGNORE_ERROR的情况下，二进制变成只读时，后续数据能在忽略二进制日志的情况下继续正常的数据提交。并且主从伪健康。

当binlog_error_action=abort server时

其余参数不变，主从复制正常。并且test.test数据为空：

执行抢占脚本：

抢占成功，master报错binlog损坏并退出。查看slave数据：

仅插入一条数据。查看binlog：

 # at390

#160603 17:03:55 server id 1  end_log_pos 438 CRC32 0x1a72646f  GTID [commit=yes]

SET @@SESSION.GTID_NEXT= '31cefd71-2942-11e6-9fe6-000c29e3aa8a:2'/*!*/;

# at 438

#160603 17:03:55 server id 1  end_log_pos 510 CRC32 0xc176d56a  Query  thread_id=3     exec_time=0     error_code=0

SET TIMESTAMP=1464944635/*!*/;

BEGIN

/*!*/;

# at 510

#160603 17:03:55 server id 1  end_log_pos 557 CRC32 0x6149878a  Table_map: `test`.`test` mapped to number 70

# at 557

#160603 17:03:55 server id 1  end_log_pos 597 CRC32 0x44c1c50b  Write_rows: table id 70 flags: STMT_END_F

 

BINLOG '

+0dRVxMBAAAALwAAAC0CAAAAAEYAAAAAAAEABHRlc3QABHRlc3QAAQMAAYqHSWE=

+0dRVx4BAAAAKAAAAFUCAAAAAEYAAAAAAAEAAgAB//4BAAAAC8XBRA==

'/*!*/;

### INSERT INTO`test`.`test`

### SET

###  @1=1 /* INT meta=0 nullable=1 is_null=0 */

# at 597

#160603 17:03:55 server id 1  end_log_pos 628 CRC32 0x60ae865d  Xid = 22

COMMIT/*!*/;

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

DELIMITER ;

# End of log file

ROLLBACK /* added by mysqlbinlog */;

/*!50003 SETCOMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

/*!50530 SET@@SESSION.PSEUDO_SLAVE_MODE=0*/;：

 

？

还有个现象，不知道怎么解释：抢过来的binlog与在主机上的binlog有差别：

抢来的binlog少了一条insert语句。

蓝色为相同部分，黑色为不同部分。

 

主机binlog：

[root@node2ianhol]# df -h

Filesystem      Size Used Avail Use% Mounted on

/dev/sda2        18G 4.0G   13G  24% /

tmpfs           931M   72K 931M   1% /dev/shm

/dev/sda1       291M  40M  237M  15% /boot

/dev/sdc         20G 172M   19G   1% /usr/local/mysql/binlog

[root@node2ianhol]# mysqlbinlog -vv /usr/local/mysql/binlog/mysql-bin.000002

# at 199

#160603 16:58:27server id 1  end_log_pos 267 CRC320x749d1053  Query   thread_id=1     exec_time=0     error_code=0

SETTIMESTAMP=1464944307/*!*/;

SET@@session.pseudo_thread_id=1/*!*/;

SET@@session.foreign_key_checks=1, @@session.sql_auto_is_null=0,@@session.unique_checks=1, @@session.autocommit=1/*!*/;

SET @@session.sql_mode=1075838976/*!*/;

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=8/*!*/;

SET @@session.lc_time_names=0/*!*/;

SET@@session.collation_database=DEFAULT/*!*/;

BEGIN

/*!*/;

# at 267

#160603 16:58:27server id 1  end_log_pos 314 CRC320x304ca232  Table_map: `test`.`test`mapped to number 70

# at 314

#160603 16:58:27server id 1  end_log_pos 359 CRC320x5a47430d  Delete_rows: table id 70flags: STMT_END_F

 

BINLOG '

s0ZRVxMBAAAALwAAADoBAAAAAEYAAAAAAAEABHRlc3QABHRlc3QAAQMAATKiTDA=

s0ZRVyABAAAALQAAAGcBAAAAAEYAAAAAAAEAAgAB//4BAAAA/gEAAAANQ0da

'/*!*/;

### DELETE FROM`test`.`test`

### WHERE

###   @1=1 /* INT meta=0 nullable=1 is_null=0 */

### DELETE FROM`test`.`test`

### WHERE

###   @1=1 /* INT meta=0 nullable=1 is_null=0 */

# at 359

#160603 16:58:27server id 1  end_log_pos 390 CRC320xecb49fc7  Xid = 4

COMMIT/*!*/;

# at 390

#160603 17:03:55 server id 1  end_log_pos 438 CRC32 0x1a72646f  GTID [commit=yes]

SET @@SESSION.GTID_NEXT='31cefd71-2942-11e6-9fe6-000c29e3aa8a:2'/*!*/;

# at 438

#160603 17:03:55 server id 1  end_log_pos 510 CRC32 0xc176d56a  Query  thread_id=3     exec_time=0     error_code=0

SET TIMESTAMP=1464944635/*!*/;

BEGIN

/*!*/;

# at 510

#160603 17:03:55 server id 1  end_log_pos 557 CRC32 0x6149878a  Table_map: `test`.`test` mapped to number 70

# at 557

#160603 17:03:55 server id 1  end_log_pos 597 CRC32 0x44c1c50b  Write_rows: table id 70 flags: STMT_END_F

 

BINLOG '

+0dRVxMBAAAALwAAAC0CAAAAAEYAAAAAAAEABHRlc3QABHRlc3QAAQMAAYqHSWE=

+0dRVx4BAAAAKAAAAFUCAAAAAEYAAAAAAAEAAgAB//4BAAAAC8XBRA==

'/*!*/;

### INSERT INTO`test`.`test`

### SET

###  @1=1 /* INT meta=0 nullable=1 is_null=0 */

# at 597

#160603 17:03:55 server id 1  end_log_pos 628 CRC32 0x60ae865d  Xid = 22

COMMIT/*!*/;

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

DELIMITER ;

# End of log file

ROLLBACK /* added bymysqlbinlog */;

/*!50003 SETCOMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

/*!50530 SET@@SESSION.PSEUDO_SLAVE_MODE=0*/;

 

 

 

从机抢夺的binlog：

[root@node3ianhol]# df -h

Filesystem      Size Used Avail Use% Mounted on

/dev/sda2        18G 4.1G   13G  25% /

tmpfs           491M   84K 491M   1% /dev/shm

/dev/sda1       291M  34M  242M  13% /boot

/dev/sdc         20G 172M   19G   1% /mnt/test

[root@node3ianhol]# mysqlbinlog -v -v /mnt/test/mysql-bin.000002 

# at 267

#160603 16:58:27server id 1  end_log_pos 314 CRC320x304ca232  Table_map: `test`.`test`mapped to number 70

# at 314

#160603 16:58:27server id 1  end_log_pos 359 CRC320x5a47430d  Delete_rows: table id 70flags: STMT_END_F

 

BINLOG '

s0ZRVxMBAAAALwAAADoBAAAAAEYAAAAAAAEABHRlc3QABHRlc3QAAQMAATKiTDA=

s0ZRVyABAAAALQAAAGcBAAAAAEYAAAAAAAEAAgAB//4BAAAA/gEAAAANQ0da

'/*!*/;

### DELETE FROM`test`.`test`

### WHERE

###   @1=1 /* INT meta=0 nullable=1 is_null=0 */

### DELETE FROM`test`.`test`

### WHERE

###   @1=1 /* INT meta=0 nullable=1 is_null=0 */

# at 359

#160603 16:58:27server id 1  end_log_pos 390 CRC32 0xecb49fc7  Xid = 4

COMMIT/*!*/;

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

DELIMITER ;

# End of log file

ROLLBACK /* added bymysqlbinlog */;

/*!50003 SETCOMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

 

结论：

binlog_error_action参数在ABORT_SERVER模式下能触发mysql进程自动关闭，并可以保证数据一致性。

ianhol
关注
专栏目录
MySQL binlog发送
敖尔其楞的专栏
06-10 387
sql_parser.cc 中处理语句 case COM_BINLOG_DUMP_GTID: // TODO: access of protocol_classic should be removed error= com_binlog_dump_gtid(thd, (char *)thd->get_protocol_classic()->get_raw_packet(), thd->get_protocol_classic()
binlog关闭事务记录_关于参数binlog_error_action
weixin_39694264的博客
12-21 279
一、问题描述8月14日收到报警，有一台MySQL主从同步停止了，遂登录slave通过show slave status\G查看错误原因，Last_IO_Error显示如下：Gotfatalerror1236frommasterwhenreadingdatafrombinarylog:'binlogtruncatedinthemiddleofevent;...
MySQL binlog_error_action分析
Enmotech的博客
10-14 1168
墨墨导读：MySQL生态中服务层的二进制日志有着非常重要的作用，MVCC机制不用的binlog，是否可以去掉？本文作者详述对MySQL的binlog cache的理解。数据技术嘉年华，十...
mysql error log 分析_MySQL binlog_error_action分析
weixin_42302872的博客
01-27 227
MySQL生态中服务层的二进制日志有着非常重要的作用，有人问过MVCC机制不用的binlog，是否可以去掉，答案是否。binlog用于记录用户对数据库操作的SQL语句(除了数据查询语句)，但同时用于保障高可用架构中的复制方式。本文从一个日常不太关心的参数开始，了解一下mysql的binlog cache。crash的截图内容：从上述错误信息中了解到奥binlog flush无法进行下去，抛出bin...
106.’binlog_error_action’ is set to ‘ABORT_SERVER
最新发布
weixin_43346403的博客
01-04 466
建议做好备份，业务切换到备库，更换存储设备,重新同步后，再切换回主库。磁盘出现问题前，一般都会有IO突然变慢，或磁盘写入故障等问题。dm-0 是 rhel-root 这个逻辑卷的。rhel-root 挂载在根目录 /，/opt目录在 根目录 / 下。所以DM-0有问题，就整个根目录会有问题。这两个过程基本跟刷磁盘有关联，一般出现问题的情况是硬盘空间出现坏道，或则 刷盘过程中出现外部原因导致服务器突然crash。’ 无法写入binlog,且会导致宕机。，所以偶发性出现mysql写入异常并重启。
MYSQL log_error_verbosity 和 Binlog_error_action
sql server的专栏
12-08 670
MYSQL 的错误日志的详细度其实不少人是忽略的,实际上MYSQL这边的关于告警和错误日志本身也是有一些注意的地方.在PERCONA MYSQL5.7.2X中发现一个问题,当在MY.CN...
mysql参数配置binlog
大蚊子
12-23 2405
当在复制源服务器上启用此变量（这是默认设置）时，向存储引擎发出的事务提交指令将在单个线程上序列化，因此事务的提交顺序始终与写入二进制日志的顺序相同。如果此变量为 1（启用），则服务器使用版本 1 日志记录事件（以前版本中使用的二进制日志事件的唯一版本）写入二进制日志，从而生成可由较旧副本读取的二进制日志。）在许多情况下，这并不重要，因为在单独的事务中执行的操作应该产生一致的结果，如果不是这种情况，则应该使用单个事务。启用二进制日志记录后，服务器会将所有更改数据的语句记录到二进制日志中，用于备份和复制。
max_binlog_cache_size 导致数据数据更新失败的原因分析
Edward_developer的专栏
06-11 1439
max_binlog_cache_size 导致数据数据更新失败的原因分析
mysql 主从复制架构简述
向前行走的人
03-12 432
mysql 主从复制架构简述1 简述2 架构模式图3 功能优点4 主从复制原理5 重点参数 1 简述     MySql 主从复制，通过将一台主机的数据复制到其他一台或多台主机上，并重新应用日志(relay log) 中的SQL语句来实现复制功能，它是构建数据库高可用集群架构的基础。 MySql 支持单向、双向、链式级联、异步复制，根据版本的更新又增加了半同步复制(5.5)、GTID 复制(5.6...
MySQL binlog相关参数
灯火觅阑珊
10-11 1998
binlog_cache_size 每个线程的binlog cache大小，如果超过了会将binlog暂存到磁盘上，影响性能。 binlog_checksum binlog校验码，默认是采用CRC32，会为每一个binlog event写一个校验码；可指定为none关闭，关闭后只通过binlog event的长度来校验一致性。 binlog_direct_non_transactional_u...
mysql的binlog日志
jkzyx123的博客
09-28 2442
mysql中binlog日志，mysqlbinlog的使用
故障分析 | binlog flush 失败导致的 Crash
ActionTech的博客
02-21 1496
作者：xuty 开个坑，记录自己平时由于解决问题需要或是兴趣研究进行的 MySQL 源码跟踪学习过程。 一、问题现象 某项目上出现 MySQL Crash，相关 errorlog 日志如下，从日志可以看出是 binlog error 导致的问题，但是无法确认具体原因，网上大部分资料都说是由于空间已满导致，后来在系统日志(/var/log/message)中确实找到了 / 分区空间已满的信息，所...
MySQL参数列表
陈玉博的技术博客
05-15 1546
名称 含义 值 activate_all_roles_on_login OFF admin_address admin_port 33062 auto_generate_certs ON auto_increment_increment 1 auto_increment_offset 1 autocommit ON automatic_sp_priv...
9.mysql主从复制主要参数
wulinpingailxr的博客
08-29 256
主从复制中的重点参数： log-bin:搭建主从复制，必须开启二进制日志。 server-id：在同一组主从结构中的唯一标识（主从上参数不能一致） server-uuid:数据库启动中，自动生成，每台不一样，存放于数据目录auto.cnf文件下 read only:设置从库只读状态，避免从库写操作，mysql5.7后新增super_read_only，开启参数，超管都无法进行写操作 binlog_...
MySQL的binlog日志
weixin_30681615的博客
10-11 94
binlog 基本认识 MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。 一般来说开启二进制日志大概会有1%的性能损耗(参见MySQL官方中文手册 5.1.24版)。二进制有两个最重要的使用场景: 其一：MySQL Replication...
查看MySQL4种日志参数及配置
zyb378747350的专栏
12-06 7579
1 查看版本 mysql> show variables like '%version'; +------------------+---------------+ | Variable_name    | Value         | +------------------+---------------+ | innodb_version   | 5.7.20        |
Mysql binlog 无法删除(purge命令无法删除)
渔夫数据库笔记
01-17 2156
1.版本 1)操作系统 cat /etc/issue CentOS release 6.6 (Final) Kernel \r on an \m cat /proc/version Linux version 2.6.32-504.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red ...
SCSI PRs命令研究总结2 - PRs命令规范
weixin_33769125的博客
09-21 1311
2019独角兽企业重金招聘Python工程师标准>>> ...
Mysql8.0&Mysql5.7&Mysql5.6&Mysql5.5特性对比
热门推荐
MYSQL轻松学的专栏
08-17 6万+
Mysql5.5 特性，相对于Mysql5.1 性能提升 默认InnoDB plugin引擎。具有提交、回滚和crash恢复功能、ACID兼容。 行级锁(一致性的非锁定读 MVCC)。 表与索引存储在表空间、表大小无限制。 支持dynamic(primary key缓存内存 避免主键查询引起的IO )与compressed(支持数据及索引压缩)行格式。 ...
MySQL binlog配置：binlog_do_db与binlog_ignore_db详解
"MySQL binlog_ignore_db 参数的使用方法" MySQL 的 binlog（二进制日志）功能是数据库复制和恢复的重要组成部分，它记录了对数据库的所有改变操作，如 DDL（Data Definition Language）和 DML（Data Manipulation ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值