1197多语句事务要求更大的max_binlog_cache_size报错

mysqlbinlog参数设置

原文:

mysql binlog日志优化及思路

  binlog_cache_size:为每个session
分配的内存,在事务过程中用来存储二进制日志的缓存,提高记录bin-log的效率。没有什么大事务,dml也不是很频繁的情况下可以设置小一点,如果事务大而且多,dml操作也频繁,则可以适当的调大一点。

1.mysql有很多系统变量可以设置,系统变量设置不同,会导致系统运行状态的不同。因此mysql提供两组命令,分别查看系统设置和运行状态。

1、系统设置:

SHOW [GLOBAL | SESSION] VARIABLES [like_or_where]
SHOW VARIABLES shows the values of MySQL system variables.
2、运行状态:
SHOW [GLOBAL | SESSION] STATUS [like_or_where]
SHOW STATUS provides server status information.

备注:SHOW XXX
可能会显示很多内容,类似Linux下内容太多了,往往需要grep来过滤,那么mysql也考虑到了这点,使用LIKE字句可以过滤。

在安装完MySQL之后,肯定是需要对MySQL的各种参数选项进行一些优化调整的。虽然MySQL系统的伸缩性很强,既可以在有很充足的硬件资源环境下高效的运行,也可以在极少资源环境下很好的运行,但不管怎样,尽可能充足的硬件资源对MySQL的性能提升总是有帮助的。在这一节我们主要分析一下MySQL的日志(主要是Binlog)对系统性能的影响,并根据日志的相关特性得出相应的优化思路。

日志产生的性能影响

由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。

在之前介绍MySQL物理架构的章节中,我们已经了解到了MySQL的日志包括错误日志(ErrorLog),更新日志(UpdateLog),二进制日志(Binlog),查询日志(QueryLog),慢查询日志(SlowQueryLog)等。当然,更新日志是老版本的MySQL才有的,目前已经被二进制日志替代。

在默认情况下,系统仅仅打开错误日志,关闭了其他所有日志,以达到尽可能减少IO损耗提高系统性能的目的。但是在一般稍微重要一点的实际应用场景中,都至少需要打开二进制日志,因为这是MySQL很多存储引擎进行增量备份的基础,也是MySQL实现复制的基本条件。有时候为了进一步的性能优化,定位执行较慢的SQL语句,很多系统也会打开慢查询日志来记录执行时间超过特定数值(由我们自行设置)的SQL语句。

一般情况下,在生产系统中很少有系统会打开查询日志。因为查询日志打开之后会将MySQL中执行的每一条Query都记录到日志中,会该系统带来比较大的IO负担,而带来的实际效益却并不是非常大。一般只有在开发测试环境中,为了定位某些功能具体使用了哪些SQL语句的时候,才会在短时间段内打开该日志来做相应的分析。所以,在MySQL系统中,会对性能产生影响的MySQL日志(不包括各存储引擎自己的日志)主要就是Binlog了。

同事报告说有个cdb
mysql实例最近很慢,写入速度巨慢,而且是间歇性的有的时候每隔7到8分钟就卡一会,有的时候每隔12分钟就卡一会,问他们是否有定时任务在拉数据?他们说没有。 

 

max_binlog_cache_size设置的参考标准

2.Binlog 相关参数及优化策略。

binlog_cache_size

Binlog_cache_disk_use

Binlog_cache_use

max_binlog_cache_size

max_binlog_size

sync_binlog

“binlog_cache_size”:在事务过程中容纳二进制日志SQL语句的缓存大小。二进制日志缓存是服务器支持事务存储引擎并且服务器启用了二进制日志(—log-bin选项)的前提下为每个客户端分配的内存,注意,是每个Client都可以分配设置大小的binlogcache空间。如果读者朋友的系统中经常会出现多语句事务的华,可以尝试增加该值的大小,以获得更有的性能。当然,我们可以通过MySQL的以下两个状态变量来判断当前的binlog_cache_size的状况:Binlog_cache_use和Binlog_cache_disk_use。

Binlog_cache_disk_use:表示因为我们binlog_cache_size设计的内存不足导致缓存二进制日志用到了临时文件的次数

Binlog_cache_use :表示 用binlog_cache_size缓存的次数

当对应的Binlog_cache_disk_use 值比较大的时候 我们可以考虑适当的调高
binlog_cache_size 对应的值

show global status like ‘bin%’;

上述语句我们可以得到当前 数据库binlog_cache_size的使用情况

mysql> show status like ‘binlog_%’;
+———————–+———–+
| Variable_name | Value |
+———————–+———–+
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use | 120402264 |
+———————–+———–+

“max_binlog_cache_size”:和”binlog_cache_size”相对应,但是所代表的是binlog能够使用的最大cache内存大小。当我们执行多语句事务的时候,max_binlog_cache_size如果不够大的话,系统可能会报出“Multi-statementtransactionrequiredmorethan’max_binlog_cache_size’bytesofstorage”的错误。

“max_binlog_size”:Binlog日志最大值,一般来说设置为512M或者1G,但不能超过1G。该大小并不能非常严格控制Binlog大小,尤其是当到达Binlog比较靠近尾部而又遇到一个较大事务的时候,系统为了保证事务的完整性,不可能做切换日志的动作,只能将该事务的所有SQL都记录进入当前日志,直到该事务结束。这一点和Oracle的Redo日志有点不一样,因为Oracle的Redo日志所记录的是数据文件的物理位置的变化,而且里面同时记录了Redo和Undo相关的信息,所以同一个事务是否在一个日志中对Oracle来说并不关键。而MySQL在Binlog中所记录的是数据库逻辑变化信息,MySQL称之为Event,实际上就是带来数据库变化的DML之类的Query语句。

“sync_binlog”:这个参数是对于MySQL系统来说是至关重要的,他不仅影响到Binlog对MySQL所带来的性能损耗,而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下:

sync_binlog=0,当事务提交之后,MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘,而让Filesystem自行决定什么时候来做同步,或者cache满了之后才同步到磁盘。

sync_binlog=n,当每进行n次事务提交之后,MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

在MySQL中系统默认的设置是sync_binlog=0,也就是不做任何强制性的磁盘刷新指令,这时候的性能是最好的,但是风险也是最大的。因为一旦系统Crash,在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候,是最安全但是性能损耗最大的设置。因为当设置为1的时候,即使系统Crash,也最多丢失binlog_cache中未完成的一个事务,对实际数据没有任何实质性影响。从以往经验和相关测试来看,对于高并发事务的系统来说,“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

1.mysql有很多系统变量可以设置,系统变量设置不同,会导致系统运行状态的不同。因此mysql提供两组命令,分别查看系统…

那是否有很多比较慢的sql把io资源消耗光了呢,去看慢查询记录,结果发现一条select都没有,反而是有很多insert语句,见鬼啦,这咋回事呢?

在数据库安装完毕,对于binlog日志参数设置,有一些参数的调整,来满足业务需求或使性能最大化。Mysql日志主要对io性能产生影响,本次主要关注binlog
日志。

 
Binlog_cache_disk_use表示因为我们binlog_cache_size设计的内存不足导致缓存二进制日志用到了临时文件的次数;Binlog_cache_use
表示用binlog_cache_size缓存的次数,当对应的Binlog_cache_disk_use
值比较大的时候 我们可以考虑适当的调高 binlog_cache_size
对应的值

慢查询有很多记录,如下所示,insert on duplicate key
update,粗粗一看,肯定是on duplicate key update的问题,如下:

 

【故障情景】

# User@Host: hsh_ext[hsh_ext] @  [devtest.yikan.com]  Id: 37459
# Query_time: 1.170256  Lock_time: 0.000118 Rows_sent: 0  Rows_examined: 0
SET timestamp=1504065495;
/*id:57539043*/insert into hy_deive(record_time, platform, device_id,
    install_id, device_token, push_enabled,
    `uid`, model, app_version, is_login, device_type, created_at,
    updated_at)
    values

      (
      1504065494, 'android', '863049030002995',
      '417e03c9-b879-4741-86b6-beb8c1f42497', 'Anj6kMy77g-2sKlb7idPuxAQ58eXdE_JILDvT-xITBfb', 0,
      4234883169, 'OPPO', '3.36.2', 1, 'umeng',
      1504065494, 1504065494
      )
     , 
      (
      1504065494, 'android', '863049030002995',
      '417e03c9-b879-4741-86b6-beb8c1f42497', 'F5nrlikA1gCLSrLZ7Xby1ASn+fXqSJZ3xATxvkJtXzU=', 0,
      4234883169, 'OPPO', '3.36.2', 1, 'xiaomi',
      1504065494, 1504065494
      )
     , 
      (
      1504065494, 'android', '863049030002995',
      '417e03c9-b879-4741-86b6-beb8c1f42497', '0863049030002995200000184200CN01', 0,
      4234883169, 'OPPO', '3.36.2', 1, 'huawei',
      1504065494, 1504065494
      )

    on duplicate key update
    record_time = IF(record_time > values(record_time), record_time, values(record_time)),
    platform = IF(record_time > values(record_time), platform, values(platform)),
    install_id = IF(record_time > values(record_time), install_id, values(install_id)),
    device_token = IF(record_time > values(record_time), device_token, values(device_token)),
    push_enabled = IF(record_time > values(record_time), push_enabled, values(push_enabled)),
    model = IF(record_time > values(record_time), model, values(model)),
    app_version = IF(record_time > values(record_time), app_version, values(app_version)),
    is_login = IF(record_time > values(record_time), is_login, values(is_login)),
    updated_at = IF(record_time > values(record_time), updated_at, values(updated_at));

查一下二进制日志相关的参数  

 
通过脚本以load的方式导入数据时,出现多行事务需要的max_binlog_cache_size空间不足。该数据文件HAOHUAN.txt只包含以逗号分隔的500万行左右的数据,每行四列,文件大小为270M。

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40

 

1 [root@172-16-3-190 shells]# bash +x load_data_into.sh 
2                 文件的总数为:1 
3                 文件名为:/tmp/load/HAOHUAN.txt 
4 当前正在处理的文件是:/tmp/load/HAOHUAN.txt
5 load data infile '/tmp/load/HAOHUAN.txt' into table practice.temp_baofoo_unbind fields terminated by ',' lines terminated by '\n' (merchant_no,bank_code,bank_card,protocol_no)
6 Warning: Using a password on the command line interface can be insecure.
7 ERROR 1197 (HY000) at line 1: Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again

但是实际上,准备2条无用的insert
into … values… on duplicate key update
…..,很快就执行完了,不到0.01s,那为啥那个时候,还有那么多的慢查询记录呢?

   mysql> show variables like ‘%binlog%’;

【故障排查】

去查看了cdb的监控记录,select、udpate、insert没有啥间隙性的尖刀出现,虽然有起伏有上升空间,但是都比较平稳,没有尖刀,大家看下面的图L 
图片 1

+——————————–+———————-+

Author

发表评论

电子邮件地址不会被公开。 必填项已用*标注