2014.12.11 MySQL技术分享之:《深入浅出MySQL GTID》

2014.12.11 MySQL技术分享之:《深入浅出MySQL GTID》

分享时间:2014年12月11日20:30

分享嘉宾:冯浩|ISADBA

现chinaunix.net MySQL版主,原51CTO.com Linux版主

6年互联网工作经验,关注数据库,自动化运维,电子商务.

BLOG:http://isadba.com

新浪微薄:@ISADBA

在如今的互联网行业里,数据库可用性、扩展性、性能都非常重要。

MySQL数据库很多的高可用及scale out方案都是基于replication实现的,相对其他方案整体性价比会高出很多。

从MySQL 5.6.2新增GTID特性,利用GTID以让我们更加容易的管理MySQL复制,并有效提高数据库一致性。

这次的分享主要针对MySQL GTID展开,主要的分享内容如下:

1、MySQL集群方案

2、MySQL Classic Replication

3、MySQL GTID Replication

4、Oracle MySQL GTID

5、MariaDB GTID

6、Oracle MySQL GTID VS MariaDB GTID

通过这次分享,大家可以GET到如下技能:

1、GTID和原来的复制有什么区别.

2、如何从原来的复制切换到GTID复制.

3、GTID复制的使用限制.

4、选择那个数据库版本或者分支开始使用GTID复制.

 

建议听众:

DBA,SA、程序员,架构师等MySQL相关从业人员

感兴趣的同学请提前加入QQ群:125572178,更多精彩分享等着你 :)

[技术分享] MySQL线上SQL捕获及分析

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

分享题目:MySQL线上SQL捕获及分析

分享者: 吴炳锡

时间: 2014年11月21日, 20:30-10:30
分享方式: 在线分享,利用QQ+YY,参加同学,提前加入QQ群:373900864 (暗号: 群主是帅哥)

该PPT是在2014 Oracle技术嘉年华上的一个分享,分享后,很多同学在QQ找我聊,怎么做线上SQL的分析之类。当然也有很多同学没能参加,我就是借着网络在此做一次分享,利用网络和大家做一个交流。分享的方式: QQ+YY (没有YY的同学需要注册一个)

优化是DBA或是架构师们在不断追求的方向,也是大家热忠追求的技术,如果说优化是技术里面的屠龙技术,要想去屠龙很重要的技术是要学会寻龙,在分本享中,通过线上SQL捕获,和大家一块讨论一下如何寻找SQL优化中的大龙。

分享内容:

  • 线上捕获SQL方法
  • 基于tcpdump线上SQL抓取
  • 基于查询日志记录
  • 基于慢日志记录全量日志
  • 捕获的SQL分析方法
  • 线上SQL抓取及分析平台化实现

感兴趣的同学请提前加入QQ群: 373900864 更多精彩分享等着你。

redis-oom-command-not-allowed报错

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

OOM command not allowed when used memory > ‘maxmemory’ 报错排查

grep “OOM command not allowed when used memory > ‘maxmemory'” * -r
src/redis.c: “-OOM command not allowed when used memory > ‘maxmemory’.\r\n”));

查看src/redis.c

从代码确认报这个错,大概是内存达到最大限时不能释放出来内存报的错。

做一个简单的验证:

配置一个10M大小的Redis,利用一个python程序往里面写数据,很快得到报错:

结论:

  1. Redis运行中监控内存的使用情况.
  2. 如果只做缓存使用,需要配置上lru策略,如

    如果做持久化存储说明,内存也不够用了。需要考虑增加内存。
  3. 故障现场要看一下Redis的info输出,看看内存配是否达到了上限。

varchar和text说不清的那些事

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

最近有几个同学问我varchar和text有啥别吗,这个问题,以前说真的也没太多的整理,以前遇到text在设计中就是尽可能的拆到另一个表中,保持主表尽量的瘦小,可以让innodb bp缓存更多的数据。

今天借次机会系统整理一下,主要从存储上,最大值,默认值几个方面进行比较。

BTW: 从ISO SQL:2003上讲VARCHAR是一个标准型,但TEXT不是(包括tinytext).varchar在MySQL 5.0.3之前只支持0-255byte, 在5.0.3之后才支持到0-65535byte.

从存储上讲:

说完存储后,说一下使用这些大的变长字段的缺点:

那问题来了? 为什么varchar(255+)存储上和text很相似了,但为什么还要有varchar, mediumtext, text这些类型?
(从存储上来讲大于255的varchar可以说是转换成了text.这也是为什么varchar大于65535了会转成mediumtext)

我理解:这块是一方面的兼容,另一方面在非空的默认值上varchar和text有区别。从整体上看功能上还是差别的。

这里还涉及到字段额外开销的:

备注 overhead是指需要几个字节用于记录该字段的实际长度。

从处理形态上来讲varchar 大于768字节后,实质上存储和text差别不是太大了。 基本认为是一样的。
另外从8000byte这个点说明一下: 对于varcahr, text如果行不超过8000byte(大约的数,innodb data page的一半) ,overflow不会存到别的page中。基于上面的特性可以总结为text只是一个MySQL扩展出来的特殊语法有兼容的感觉。

默认值问题:

总结:

源码中类型:

(末完待续,也希望大家一块讨论一下)

参考:

http://yoshinorimatsunobu.blogspot.com/2010/11/handling-long-textsblobs-in-innodb-1-to.html

http://nicj.net/mysql-text-vs-varchar-performance/

http://www.pythian.com/blog/text-vs-varchar/

 

测试SQL及方法

 

MySQL 二进制日志格式基础(一)

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.
MySQL二制进日志用于记录数据库的变更记录,这里从结构上讨论一下日志的格式。

每个日志都包含4个字节的magic number 和event的描述包

  1. 日志有前四个字节是magic number: oxfe ox62 0x69 0x6e = 0xfe ‘b”i”n’ 转成整数:1852400382  用处就是读4个字节对比不是这个数,说明就不是二进制日志,就不用处理了。
  2. 每个event的header大概如下:
  3. 第一个event称为:format descriptor event(Event描述结构:FDE) 用于说明日志的格式
  4. 其它event就是依赖于描述结构不同,用不同的结构记录数据
  5. 最后一个event是: 日志切换事件(log-rotation event)用于指点定下个日志的文件名

每个event的结构大概如下:

现在大多使用的V4结构,从MySQL 5.0起,具体如下:

第一个event是FDE结构没有extra_headers部分,所以固定为19个字节。

FDE的event_data中定长部分为:

  • 2字节的的日志格式版本,从MySQL 5.0后都是4
  • 50字节 用于记录MySQL的版本号 如:5.6.16-64.2-rel64.2-log 不够50字节用0x00填充
  • 4字节 日志产生的时间
  • 1字节 header长度。一般是19,如果大于19,则下面的event都有extra_header字段
    对于FDE变长部分一般为空

其它Event计算

  • header length = x byte
  • data length = (event_lenth -x )byte
  • 数据区里定长部分长度

如果给定的X不是19,则存extra_header里面有内存
Y依赖于event_type有不同的大小,需要参考不同的event进行特别处理
参考:http://dev.mysql.com/doc/internals/en/event-data-for-specific-event-types.html

MySQL免费技术分享《百万级在线MySQL架构分享》

作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

随着传统企业去IOE的声音越来越大,也有很多朋友来咨询MySQL的架构设计问题,所以决定做这个分享让决定或是想使用MySQL的朋友能从整体上了解一下如何利用MySQL构建一个百万级在线(或是百万并发的架构)
分享时间:2014年8月14日 20:30  在线技术分享

参加朋友加QQ群:159636401 
分享者介绍
吴炳锡 新媒传信 数据库架构师
Blog: http://mysqlsupport.cn

公司数据库托管平台设计及核心开发者
公司海量数据平台设计及开发人员
熟悉MySQL高可用原理及技术实现
丰富的基于MySQL架构设计及规划经验
MySQL中国用户组核心人员 (http://acmug.com/)

建议听众:
面向DBA人员,架构师,基于MySQL开发人员

分享目标:
让大家深入了解MySQL的特性
供基于MySQL开发的同学们做出最佳实践
全面整体上认识MySQL在架构设计中如何进行拆分
了解NoSQL和MySQL是如何结合使用优化架构

想参加分享的同学请提前加入Q群: 159636401  更多精彩分享等着你 :)

这只是一个开始,更多分享,一块来交流。

[TIPS]安装数据库提示无法解析机器名处理

作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

在做MySQL初始化时,如果机器的名不能进行反解会出现以下错误:

/usr/local/mysql/bin/resolveip: Unable to find hostid for ‘node2′: host not found

处理过程如下

1. 查看机器的名

node2

2. 查看/etc/hosts文件

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

可见/etc/hosts中无相应的机器名

添ip(本机的ip) 到机器的对应到/etc/hosts中:

最终/etc/hosts内容如下:

3.使用resolveip确认是否ok

IP address of node2 is 10.10.60.148

4. 在次运行初始化程序

Good luck!

TIPS:MySQL 改库名操作

作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

MySQL在5.1引入了一个rename database操作,但在MySQL5.1.23后又不支持这个命令。可以说是一个实验性的功能,没有在生产中支持过(mysql-5.1 release在mysql-5.1.30),那么生产中我们有时为了追求完美需要改一下库名。怎么操作呢?
这里提供一个变通的方法。
1. 创建出新库名:

  1. 生成rename语句,从olddb里迁移,我这里olddb里sbtest;

3.执行生成的sql

就这么简单可以搞定了。
Good luck!

Antelope 和Barracuda区别

作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

Antelope是innodb-base的文件格式, Barracude是innodb-plugin后引入的文件格式,同时Barracude也支持Antelope文件格式。两者区别在于:

文件格式 支持行格式 特性
Antelope

(Innodb-base)

ROW_FORMAT=COMPACT

ROW_FORMAT=REDUNDANT

Compact和redumdant的区别在就是在于首部的存存内容区别。

compact的存储格式为首部为一个非NULL的变长字段长度列表

redundant的存储格式为首部是一个字段长度偏移列表(每个字段占用的字节长度及其相应的位移)。

在Antelope中对于变长字段,低于768字节的,不会进行overflow page存储,某些情况下会减少结果集IO.

Barracuda

(innodb-plugin)

ROW_FORMAT=DYNAMIC

ROW_FORMAT=COMPRESSED

 

这两者主要是功能上的区别功能上的。 另外在行里的变长字段和Antelope的区别是只存20个字节,其它的overflow page存储。

另外这两都需要开启innodb_file_per_table=1

(这个特性对一些优化还是很有用的)

备注:

这里有一点需要注意,如果要使用压缩,一定需要先使用innodb_file_format =Barracuda格式,不然没作用。

下面我们看一下区别:

(testing)root@localhost [(none)]> use wubx;

Database changed

(testing)root@localhost [wubx]> CREATE TABLE t1

->  (c1 INT PRIMARY KEY)

->  ROW_FORMAT=COMPRESSED

->  KEY_BLOCK_SIZE=8;

Query OK, 0 rows affected, 4 warnings (0.01 sec)

报出来4个warnings查看一下报错:

(testing)root@localhost [wubx]> show warnings;

+———+——+———————————————————————–+

| Level   | Code | Message                                                               |

+———+——+———————————————————————–+

| Warning | 1478 | InnoDB: KEY_BLOCK_SIZE requires innodb_file_format > Antelope.        |

| Warning | 1478 | InnoDB: ignoring KEY_BLOCK_SIZE=8.                                    |

| Warning | 1478 | InnoDB: ROW_FORMAT=COMPRESSED requires innodb_file_format > Antelope. |

| Warning | 1478 | InnoDB: assuming ROW_FORMAT=COMPACT.                                  |

+———+——+———————————————————————–+

4 rows in set (0.00 sec)

从以上报错可以看出来不支持压缩。但看一下表结构如下:

(testing)root@localhost [wubx]> show create table t1;

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

| Table | Create Table                                                                                                                                  |

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

| t1    | CREATE TABLE t1 (

c1 int(11) NOT NULL,

PRIMARY KEY (c1)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8 |

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

1 row in set (0.00 sec)

这个是比较坑的地方,所以在使用压缩需要注意。

 

(testing)root@localhost [wubx]>create table t2 ( c1 int(11) NOT NULL, primary key(c1));

(testing)root@localhost [wubx]> insert into t2 select * from t1;

Query OK, 5417760 rows affected (37.12 sec)

Records: 5417760  Duplicates: 0  Warnings: 0

 

创建支持压缩的表:

(testing)root@localhost [wubx]>SET GLOBAL  innodb_file_per_table=1

(testing)root@localhost [wubx]>SET GLOBAL innodb_file_format=Barracuda;

(testing)root@localhost [wubx]>CREATE TABLE t3

(c1 INT PRIMARY KEY)

ROW_FORMAT=COMPRESSED

KEY_BLOCK_SIZE=8;

(testing)root@localhost [wubx]> insert into t3 select * from t1;

Query OK, 5417760 rows affected (1 min 10.98 sec)

Records: 5417760  Duplicates: 0  Warnings: 0

 

看一下表的物理大小如下:

-rw-rw—- 1 mysql mysql 8.4K Jul  5 16:58 t1.frm

-rw-rw—- 1 mysql mysql 136M Jul  5 19:40 t1.ibd

-rw-rw—- 1 mysql mysql 8.4K Jul  5 19:43 t2.frm

-rw-rw—- 1 mysql mysql 136M Jul  5 19:44 t2.ibd

-rw-rw—- 1 mysql mysql 8.4K Jul  5 19:46 t3.frm

-rw-rw—- 1 mysql mysql  96M Jul  5 19:47 t3.ibd

 

可见t1, t2都没进行压缩, t3是支持压缩的。

 

 

cpuspeed和irqbalance服务器的两大性能杀手

作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

最近在一个性能测试中遇到机器的CPU频率不对。查了一下原来是irqbalance和cpuspeed搞出来问题。
irqbalance 理论上:
启用 irqbalance 服务,既可以提升性能,又可以降低能耗。
irqbalance 用于优化中断分配,它会自动收集系统数据以分析使用模式,并依据系统负载状况将工作状态置于 Performance mode 或 Power-save mode。
处于 Performance mode 时,irqbalance 会将中断尽可能均匀地分发给各个 CPU core,以充分利用 CPU 多核,提升性能。
处于 Power-save mode 时,irqbalance 会将中断集中分配给第一个 CPU,以保证其它空闲 CPU 的睡眠时间,降低能耗。
但实际中往往影响cpu的使用均衡,建议服务器环境中关闭。

cpuspeed这个也算是遇到一个大坑,如果bios中已经开启了max performance但cpu主频还是不对,那就是cpuspeed搞出来的鬼(笔记本可以保留这些服务用于省电)。

其实相对一个数据库服务器对Linux服务可以进行以下操作:

最小化的开启服务,如果在需要其它可以手工再开启。

Good Luck.