关于超大binlog事件的问题
我手里维护了一个项目，其功能是用Java模拟一个MariaDB的slave库连接到主库，对从主库传输过来的binlog事件进行监听与分析
碰到一个问题是：
如果主库做了一个很大的修改操作（比方说直接delete了一个百万条数据的表），那么会产生一个很大的binlog事件，这个binlog事件会在我们的binlog监听器中被处理，然后组装成一个很大的对象（含有这100万条数据）
问题就出在这里，这个对象太大了（占用上g的heap毫不费力），然后我们在对这个对象的分析过程中，会产生更多的对象，而这些对象都是强引用，占用的是实打实的内存。于是就OOM了
我接受这个项目的时候，前人提出的方案很简单：禁止用户执行过大的操作。
很暴力的方案，而且确实也可以解决问题。
但是我觉得应该有更好的解决方法
第一反应是修改binlog监听器模块的代码
由于binlog事件是通过网络传输，我们也许可以在接收binlog事件的时候，对监听到的超大binlog事件进行拆分，将其逐步拆分为多个等效的小binlog事件
但是这一块的代码风格很差，很难修改
于是在Google上搜了一下相关的关键词，发现有一个叫做binlog-row-event-max-size的神奇启动参数，其英文注释如下
The maximum size in bytes of a row-based binary log event. Should be a multiple of 256. Minimum 256, maximum 18446744073709547520.
似乎正好是我需要的？
但是很不幸，这个参数只在MariaDB 10.0.17之后有效
而公司的生产环境用的是MariaDB 10.0.10
对比一下两者的效果吧
MariaDB 10.0.10，delete一个百万元素的表
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info | mysql-bin.000319 | 446952048 | Gtid | 90174306 | 446952086 | BEGIN GTID 17186-90174306-429975571 |
| mysql-bin.000319 | 446952086 | Table_map | 90174306 | 446952126 | table_id: 14520 (cc.t1) |
| mysql-bin.000319 | 446952126 | Delete_rows_v1 | 90174306 | 455952146 | table_id: 14520 flags: STMT_END_F |
| mysql-bin.000319 | 455952146 | Xid | 90174306 | 455952173 | COMMIT /* xid=489278797 */
可以看到这个delete事件对应于一个很大的binlog事件
MariaDB 10.1.22，binlog-row-event-max-size设置为262144，同样delete一个百万元素的表
mysql> SHOW BINLOG EVENTS IN 'mysqld-bin.000001';
+-------------------+---------+-------------------+-----------+-------------+-----------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+-------------------+---------+-------------------+-----------+-------------+-----------------------------------------------------+
| mysqld-bin.000001 | 4 | Format_desc | 1 | 249 | Server ver: 10.1.22-MariaDB-1~jessie, Binlog ver: 4 |
| mysqld-bin.000001 | 249 | Gtid_list | 1 | 274 | [] |
| mysqld-bin.000001 | 274 | Binlog_checkpoint | 1 | 314 | mysqld-bin.000001 |
| mysqld-bin.000001 | 314 | Gtid | 1 | 352 | BEGIN GTID 0-1-1 |
| mysqld-bin.000001 | 352 | Table_map | 1 | 394 | table_id: 19 (test.t1) |
| mysqld-bin.000001 | 394 | Delete_rows_v1 | 1 | 262557 | table_id: 19 |
| mysqld-bin.000001 | 262557 | Delete_rows_v1 | 1 | 524720 | table_id: 19 |
| mysqld-bin.000001 | 524720 | Delete_rows_v1 | 1 | 786883 | table_id: 19 |
| mysqld-bin.000001 | 786883 | Delete_rows_v1 | 1 | 1049046 | table_id: 19 |
| mysqld-bin.000001 | 1049046 | Delete_rows_v1 | 1 | 1311209 | table_id: 19 |
| mysqld-bin.000001 | 1311209 | Delete_rows_v1 | 1 | 1573372 | table_id: 19 |
| mysqld-bin.000001 | 1573372 | Delete_rows_v1 | 1 | 1835535 | table_id: 19 |
| mysqld-bin.000001 | 1835535 | Delete_rows_v1 | 1 | 2097698 | table_id: 19 |
| mysqld-bin.000001 | 2097698 | Delete_rows_v1 | 1 | 2359861 | table_id: 19 |
| mysqld-bin.000001 | 2359861 | Delete_rows_v1 | 1 | 2622024 | table_id: 19 |
| mysqld-bin.000001 | 2622024 | Delete_rows_v1 | 1 | 2884187 | table_id: 19 |
| mysqld-bin.000001 | 2884187 | Delete_rows_v1 | 1 | 3146350 | table_id: 19 |
| mysqld-bin.000001 | 3146350 | Delete_rows_v1 | 1 | 3408513 | table_id: 19 |
| mysqld-bin.000001 | 3408513 | Delete_rows_v1 | 1 | 3670676 | table_id: 19 |
| mysqld-bin.000001 | 3670676 | Delete_rows_v1 | 1 | 3932839 | table_id: 19 |
| mysqld-bin.000001 | 3932839 | Delete_rows_v1 | 1 | 4195002 | table_id: 19 |
| mysqld-bin.000001 | 4195002 | Delete_rows_v1 | 1 | 4457165 | table_id: 19 |
| mysqld-bin.000001 | 4457165 | Delete_rows_v1 | 1 | 4719328 | table_id: 19 |
| mysqld-bin.000001 | 4719328 | Delete_rows_v1 | 1 | 4981491 | table_id: 19 |
| mysqld-bin.000001 | 4981491 | Delete_rows_v1 | 1 | 5243654 | table_id: 19 |
| mysqld-bin.000001 | 5243654 | Delete_rows_v1 | 1 | 5505817 | table_id: 19 |
| mysqld-bin.000001 | 5505817 | Delete_rows_v1 | 1 | 5767980 | table_id: 19 |
| mysqld-bin.000001 | 5767980 | Delete_rows_v1 | 1 | 6030143 | table_id: 19 |
| mysqld-bin.000001 | 6030143 | Delete_rows_v1 | 1 | 6292306 | table_id: 19 |
| mysqld-bin.000001 | 6292306 | Delete_rows_v1 | 1 | 6554469 | table_id: 19 |
| mysqld-bin.000001 | 6554469 | Delete_rows_v1 | 1 | 6816632 | table_id: 19 |
| mysqld-bin.000001 | 6816632 | Delete_rows_v1 | 1 | 7078795 | table_id: 19 |
| mysqld-bin.000001 | 7078795 | Delete_rows_v1 | 1 | 7340958 | table_id: 19 |
| mysqld-bin.000001 | 7340958 | Delete_rows_v1 | 1 | 7603121 | table_id: 19 |
| mysqld-bin.000001 | 7603121 | Delete_rows_v1 | 1 | 7865284 | table_id: 19 |
| mysqld-bin.000001 | 7865284 | Delete_rows_v1 | 1 | 8127447 | table_id: 19 |
| mysqld-bin.000001 | 8127447 | Delete_rows_v1 | 1 | 8389610 | table_id: 19 |
| mysqld-bin.000001 | 8389610 | Delete_rows_v1 | 1 | 8651773 | table_id: 19 |
| mysqld-bin.000001 | 8651773 | Delete_rows_v1 | 1 | 8913936 | table_id: 19 |
| mysqld-bin.000001 | 8913936 | Delete_rows_v1 | 1 | 9001409 | table_id: 19 flags: STMT_END_F |
| mysqld-bin.000001 | 9001409 | Xid | 1 | 9001436 | COMMIT /* xid=3000082 */ |
+-------------------+---------+-------------------+-----------+-------------+-----------------------------------------------------+
可以看到这个delete事件已经被拆分成了30多个稍小的binlog事件
看来只能尽量推动数据库的升级工作了。
关于超大binlog事件的问题的更多相关文章
- 【文档】三、Mysql Binlog事件类文件和类型
在内部,服务器使用C++类文件来表示binlog事件.标准在log_event.h文件中,这些类的方法代码在log_event.cc中. log_event是基础类.其他的详细的事件子类都是来源于他. ...
- 【文档】五、Mysql Binlog事件结构
这个部分描述了事件被写入binlog或者delay log中的属性.所有的事件有相同的整体结构,也就是包含事件头和事件数据: +===================+ | event header ...
- 【文档】四、Mysql Binlog事件含义详解
下面对binlog中事件做个简单说明: UNKNOWN_EVENT 这个事件类型应该永远不会出现.它从不会写入binlog中.如果binlog中的事件没法被识别成其他已知事件,他被当做UNKNOWN_ ...
- 不同复制模式下，如何忽略某些binlog事件
在MySQL复制中,如果slave节点上遇到错误,比如数据不存在或者主键冲突等错误时,想要忽略这些错误,可以采用以下几种方法: 1.未启用GTID模式时 只需通过设定 SQL_SLAVE_SKIP_C ...
- [转]mysql binlog in realtime
原文:http://guweigang.com/blog/2013/11/18/mysql-binlog-in-realtime/ 众所周知,MySQL是最受欢迎的互联网数据库(没有之一)—————— ...
- MYSQL-- binlog事件详解
mysqlbinlog -vvv log.000001 # at # :: server id end_log_pos CRC32 sequence_number= SET @@SESSION.GTI ...
- load data 方式导入的数据不可以用binlog日志进行恢复，因为binlog里面不产生insert sql语句。
QQ群里面有人问起这个问题: 用load data 导入数据的时候,在binlog文件中记录的不是insert 语句,这样的话,如果用load data 导入数据,当需要恢复数据库的时候 bi ...
- 腾讯工程师带你深入解析 MySQL binlog
欢迎大家前往云+社区,获取更多腾讯海量技术实践干货哦~ 本文由 腾讯云数据库内核团队 发布在云+社区 1.概述 binlog是Mysql sever层维护的一种二进制日志,与innodb引擎中的red ...
- 教你MySQL Binlog实用攻略
本文由云+社区发表 1.概述 binlog是Mysql sever层维护的一种二进制日志,与innodb引擎中的redo/undo log是完全不同的日志:其主要是用来记录对mysql数据更新或潜在发 ...
随机推荐
- Nearest Common Ancestors POJ - 1330 （LCA）
Nearest Common Ancestors Time Limit: 1000MS Memory Limit: 10000K Total Submissions: 34657 Accept ...
- Python入职面试，可能会被企业HR问到的问题，你准备好了吗
整理了一下这两次面试问的问题先说简单的: 1.是否了解互联网协议七层模型 2.简单说一下TCP协议 3.你写的项目里用户数据安全如何保证?(比如用户密码加密处理一下)开放式问题,回 ...
- flex遭遇text-overflow:hidden，white-space:nowrap
最近在项目中遇到使用flex的时候,在flex-item元素中使用text-overflow:hidden:white-space:nowrap:进行省略文字的操作. 发现flex-item失控了,长 ...
- C 语言 习题 1-12
练习 1-12 编写一个程序,以每行一个单词的形式打印其输入. #include <stdio.h> #define IN 1 #define OUT 0 int main(int arg ...
- Python+Selenium基础篇之5-第一个完整的自动化测试脚本
前面文章,我们介绍了如何采用XPath表达式去定位网页元素,在掌握了如何抓取或者如何书写精确的XPath表达式后,我们可以开始写自己的第一个真正意义上的webui 自动化测试脚本,就相当于,你在学习P ...
- Selenium-java 中 对于下拉框 对于网页上的下拉框 如何定位
WebElement e1 = driver.findElement(By.cssSelector("#s_province")); Select se1 = new Select ...
- python week09 Mysql 数据库基础知识
第一篇:初识数据库 注:<基础概念,不再赘述,点开链接查看> 第二篇:库相关操作 一 系统数据库 information_schema: 虚拟库,不占用磁盘空间,存储的是数据库启动后的一些 ...
- 区分 Cookie, LocalStorage 与 SessionStorage
基本概念 Cookie Cookie 的大小限制为4KB左右,是网景公司的前雇员 Lou Montulli 在1993年3月的发明.它的主要用途有保存登录信息,比如你登录某个网站市场可以看到“记住密码 ...
- Mac OS 添加 MySQL 环境变量
1.打开终端,输入: cd ~ 会进入~文件夹 2.如果 ~ 文件夹中已经存在 .bash_profile 文件,则在 : 后面追加你想要添加的路径, 3. 否则输入:touch .bash_prof ...
- 非旋Treap总结 ： 快过Splay 好用过传统Treap
非旋$Treap$ 其高级名字叫$Fhq\ Treap$,既然叫$Treap$,它一定满足了$Treap$的性质(虽然可能来看这篇的人一定知道$Treap$,但我还是多说几句:$Fhp\ Treap$ ...