一个参数引起的mysql从库宕机血案
2016-10-14 09:46
357 查看
一个参数引起的MySQL从库宕机血案
Part1:max_binlog_cache_sizemax_binlog_cache_size 表示的是binlog 能够使用的最大cache 内存大小当我们执行多语句事务的时候 所有session的使用的内存超过max_binlog_cache_size的值时就会报错:“Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage”Part2:为什么它能引起宕机[b]Warning:警[/b][b]告1[/b]max_binlog_cache_size在主从设置不一致的情况下,主库参数值大于从库参数值,在主库进行大事务操作时,主库顺利进行,从库因max_binlog_cache_size值低于该事物所需,从库会抛出“Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage”错误号为1197。[b]Warning:警[/b][b]告2[/b]max_binlog_cache_size在主从参数设置一样的情况下,主库执行大事务操作,如主库提示需提高该参数以顺利执行SQL,但DBA只调整了主库的max_binlog_cache_size而忘记调整从库的max_binlog_cache_size,则同样从库会爆出1197错误,导致主从不同步。
Part3:该设置值为多少具体值设置为多少,不能纸上谈兵,还需要看公司的具体业务以及硬件内存大小,这里除了不设置该值使用默认值(默认值很大)以外,个人推荐值为4G,基本已经足够应付大部分场合,但无论是否指定该值,在对大表进行操作时,都需注意上述的警告内容,避免该值设置不合理引起从库无法执行报1197的问题。具体命令如下:set global max_binlog_cache_size =4294967296;
——总结——[b][b]该值为动态参数,可以随时利用上述命令进行调整,所以别忘记将该参数加入到my.cnf中以防止重启数据库后失效。[/b][/b]
相关文章推荐
- 一个参数引起的 MySQL 从库宕机血案(max_binlog_cache_size)
- 一个参数引起的mysql从库宕机血案
- 一个参数引起的mysql从库宕机血案
- 一个空格引起的血案,记在servlet和mysql使用字符串的一次经验
- 一个MySQL-JDBC驱动bug引起的血案……
- mysql一个冷门参数引起的同步故障
- 一个MySQL-JDBC驱动bug引起的血案……
- javascript 的参数有长度限制吗?一个细节引起的误区
- 一个ID引起的血案
- 一个笔误引起的血案
- mysql修改用户表引起的血案
- 一个变量定义引起的血案
- 一个引号引起的血案
- 一个非常简单的分页技术MYSQL+JSP 利用了mysql的LIMIT参数
- MySQL 内存交换区引起的一场“血案” 推荐
- 一个引号引起的血案,ORACLE SQL 分页语句的错误
- mysql 基础-对一个已经编译好的mysqld,如何查看编译参数?如何看是32/64位环境编译的?如何确认mysqld程序依赖哪些库?
- 一个ID引起的血案
- 一个长事务引起的血案——Informix 长事务回滚失败引起的阻塞故障处理
- javascript 的参数有长度限制吗?一个细节引起的误区