RDS最佳实践(五)—Mysql大字段的频繁更新导致binlog暴增

背景:RDS Mysql采用的binlog 格式默认为ROW,在Mysql 5.6的版本之前,Mysql每次列的修改(update)都需要记录表中所有列的值。这样就存在一个问题,如果表中包含很多的大字段,表的单行长度就会非常长,这样每次update就会导致大量的 binlog空间生成。针对这个问题,在mysql 5.6中进行了改进,复制支持”row image control” ,只记录修改的列而不是行中所有的列,这对一些包含 BLOGs 字段的数据来说可以节省很大的处理能力,因此此项改进不仅节省了磁盘空间,同时也提升了性能:

binlog_row_image Before image After image
minimal All columns where a value was specified, and the autoincrement column if there is one
noblob All columns where a value was specified, and the autoincrement column if there is one, and all non-blob columns
full All columns

测试如下:

mysql> show global variables like ‘%binlog_row_image%’;
+——————+——-+
| Variable_name | Value |
+——————+——-+
| binlog_row_image | FULL |
+——————+——-+

CREATE TABLE `t_text_56` (
`id` int(11) NOT NULL DEFAULT ‘0’,
`c1` text,
`c2` text,
`c3` text,
`c4` text,
`c5` text,
`gmt_modified` datetime DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

insert into t_text_56 values (3,repeat(‘test_text’,500),repeat(‘test_text’,500),repeat(‘test_text’,500),repeat(‘test_text’,500),repeat(‘test_text’,500),now());

表的单行记录是16K:

mysql> show table status like ‘%tex%’\G;
*************************** 1. row ***************************
Name: t_text_56
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 1
Avg_row_length: 16384
Data_length: 16384
进行一次update操作:

update t_text_56  set gmt_modified=now() where id=3;

### UPDATE `test`.`t_text_56`

### WHERE
### @1=3 /* INT meta=0 nullable=0 is_null=0 */
### @2=’test_texttest……………..’/* BLOB/TEXT meta=2 nullable=1 is_null=0 */
### @3=’test_texttest……………..’ /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
### @4=’test_texttest……………..’ /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
### @5=’test_texttest……………..’ /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
### @6=’test_texttest……………..’ /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
### @7=’2014-08-04 22:32:54′ /* DATETIME(0) meta=0 nullable=1 is_null=0 */
### SET
### @1=3 /* INT meta=0 nullable=1 is_null=0 */
### @2=’test_texttest……………..’/* BLOB/TEXT meta=2 nullable=1 is_null=0 */
### @3=’test_texttest……………..’ /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
### @4=’test_texttest……………..’ /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
### @5=’test_texttest……………..’ /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
### @6=’test_texttest……………..’ /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
### @7=’2014-08-04 22:32:58′ /* DATETIME(0) meta=0 nullable=1 is_null=0 */

5.6新增的binlog_row_image参数:minimal

mysql> set global binlog_row_image=minimal;
Query OK, 0 rows affected (0.00 sec)

mysql> update t_text_56 set gmt_modified=now() where id=3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

### UPDATE `test`.`t_text_56`
### WHERE
### @1=3 /* INT meta=0 nullable=0 is_null=0 */
### SET
### @7=’2014-08-04 22:33:32′ /* DATETIME(0) meta=0 nullable=1 is_null=0 */

binlog_row_image参数:NOLOB

mysql> set global binlog_row_image=noblob;

mysql> alter table t_text_56 add column gmt_create datetime;
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> update t_text_56 set gmt_create=now() where id=3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

### UPDATE `test`.`t_text_56`
### WHERE
### @1=3 /* INT meta=0 nullable=0 is_null=0 */
### @7=’2014-08-04 22:41:22′ /* DATETIME(0) meta=0 nullable=1 is_null=0 */
### @8=NULL /* DATETIME(0) meta=0 nullable=1 is_null=1 */
### SET
### @1=3 /* INT meta=0 nullable=0 is_null=0 */
### @7=’2014-08-04 22:41:22′ /* DATETIME(0) meta=0 nullable=1 is_null=0 */
### @8=’2014-08-04 22:43:44′ /* DATETIME(0) meta=0 nullable=1 is_null=0 */

可以看到,mysql 5.6中binlog_row_image:

当设置为minimal时候,binlog只记录了要修改的列的记录;

当设置为nolob的时候,在minimal的基础上binlog中加上非lob字段;

当binlog_row_image默认设置为了full,与5.5,5.1的日志格式保持一致,binlog记录上有的行记录信息;

所以在5.6中binlog_row_image设置为minimal,这样就可以大大减小了binlog的长度,进而减少了空间的使用。

敬请大家期待RDS 5.6的上线。

时间: 2024-11-01 16:46:05

RDS最佳实践(五)—Mysql大字段的频繁更新导致binlog暴增的相关文章

RDS最佳实践(四)—如何处理Mysql的子查询

早上值班同事在旺旺群里面贴了一条非常复杂的SQL,用户从本地迁移到RDS Mysql出现严重性能下降,同样的数据和表结构下,在本地的数据库上只要不到1s的时间,但是在rds上好几分钟都没响应. 碰到这类问题需要考虑以下一些因素: a.数据库的版本不同(不同的版本优化器策略不一样,或者异构数据库间的迁移:oracle–>mysql,sqlserver–>mysql),导致sql执行计划不同,最后导致sql执行时间不同: b.数据库的配置不同(不同的内存配置,参数设置–query cache是否打

RDS最佳实践(一)–如何选择RDS

在去年双11之前,为了帮助商家准备天猫双11的大促,让用户更好的使用RDS,把RDS的性能发挥到最佳,保障双11当天面对爆发性增加的压力,不会由于RDS的瓶颈导致系统出现问题,编写了RDS的最佳实践.该文档的内容全部出自于生产实践,但由于篇幅的限制,我只是把其中的概要罗列到了ppt中,并没有展开详细的介绍,后续计划写一个系列,把ppt中的内容进一步展开来讲一讲,也算是对RDS用户的一个交代.   我该如何选择RDS?我要购买多大规格的RDS?RDS的连接数,iops指的是什么?上诉这些问题相信是

感受开源之力,参加“阿里开源项目最佳实践”峰会5大理由!

开源是孵化新技术领域的容器,开源是技术演进的强大推动力.多年来,阿里巴巴集团一直积极拥抱开源事业,无论是开源软件的应用.回馈以至自研技术的开源都非常活跃.2016年更是阿里技术开源的丰收年:73款产品开源.JStorm.RocketMQ.Weex三连捐Apache基金会.Weex在GitHub上Star破万.阿里云成为MySQL开源分支 WebScaleSQL 的发起成员:不仅量多而且质精:在开源中国公布的"2016年最受欢迎中国开源软件评选"的结果中,阿里巴巴独占TOP20中的4席.

RDS最佳实践(三)—如何制定相关的流程来规范RDS的使用

上一篇文章中,我们介绍了如何快速的把本地自建的数据库迁移入云,那是不是把数据库迁移到RDS后,用户就什么都不需要做了?比如RDS帮你的数据库做到了高可用,在主库出现down机后能够快速切换到备库,立刻恢复应用:每天会定时的备份数据和日志,如果出现误操作能够帮你恢复到任意时间点:如果担心黑客攻击或者sql注入漏洞,RDS能够帮助你进行sql注入的拦截:当数据库使用中出现bug时,后端有专业的源码和DBA团队帮助用户实例打上patch,让用户无后顾之忧:当实例的性能出现瓶颈的时候,可以进行快速的弹性

RDS最佳实践(二)—如何快速平稳的迁入RDS

在上一篇中大致介绍RDS的一些基本参数,包括数据库类型,版本,存储空间,规格:内存,连接数,io,地域等基本含义,本篇中将介绍如何快速平稳的迁入RDS. 用户在购买完RDS后,接下来就可以开始往RDS迁入数据了.在RDS刚刚对外提供服务的时候,用户只能通过将自己的数据库dump成为sql文件,然后再将sql文件source到RDS中去:数据迁移至RDS-MySQL之使用MySQLdump工具,数据迁移至RDS-SQLserver之利用SQL Server客户端工具,这两种方法是最简单的方法,但是

RDS MySQL空间优化最佳实践

在前三期介绍了RDS for MySQL参数优化,锁问题以及延迟优化最佳实践之后,本期将介绍存储空间相关的最佳实践. 存储空间是RDS很重要的一个指标,在RDS的工单问题中,空间问题的咨询可以排在top 5,当RDS的实际使用空间超过了购买的空间后,实例就会被锁定了,这样就会导致应用无法再写入,更新数据,造成应用的报错.在RDS的控制台中可以设定空间的报警阀值,当实例空间到达报警阀值后用户就会收到报警短信,这个时候用户则需要对判断当前的空间增长是否合理.如果增长合理则需要对实例的进行弹性升级,这

MySQL · 最佳实践 · 空间优化

在前三期介绍了RDS for MySQL参数优化,锁问题以及延迟优化最佳实践之后,本期将介绍存储空间相关的最佳实践. 存储空间是RDS很重要的一个指标,在RDS的工单问题中,空间问题的咨询可以排在top 5,当RDS的实际使用空间超过了购买的空间后,实例就会被锁定了,这样就会导致应用无法再写入,更新数据,造成应用的报错.在RDS的控制台中可以设定空间的报警阀值,当实例空间到达报警阀值后用户就会收到报警短信, 这个时候用户则需要对判断当前的空间增长是否合理. 如果增长合理则需要对实例的进行弹性升级

MySQL 的 20+ 条最佳实践_Mysql

数据库操作是当今 Web 应用程序中的主要瓶颈. 不仅是 DBA(数据库管理员)需要为各种性能问题操心,程序员为做出准确的结构化表,优化查询性能和编写更优代码,也要费尽心思. 在本文中,我列出了一些针对程序员的 MySQL 优化技术. 在我们开始学习之前,我补充一点:你可以在 Envato Market 上找到大量的 MySQL 脚本和实用程序. 1.优化查询的查询缓存 大部分MySQL服务器都有查询缓存功能.这是提高性能的最有效的方法之一,这是由数据库引擎私下处理的.当同一个查询被多次执行,结

MySQL · 最佳实践 · RDS 只读实例延迟分析

前言 只读实例是目前 RDS 用户实现数据读写分离的一种常见架构,用户只需要将业务中的读请求分担到只读节点上,就可以缓解主库查询压力,同时也可以把一些 OLAP 的分析查询放到另外的只读节点上,减小复杂统计查询对主库的冲击,RDS只读节点架构图如下: 由于RDS只读节点采用原生的MySQL Binlog复制技术,那么延迟必然会成为其成立之初就会存在的问题.延迟会导致只读节点与主库的数据出现不一致,进而可能造成业务上逻辑的混乱或者数据不正确. 最近也收到了很多用户关于只读实例延迟的问题反馈,下面将