MySQL 5.6测试之Replication

一、简述
MySQL 5.6版本相比以前新增了很多令人激动的特性，简要介绍见：转：MySQL 5.6新特性。性能方面已经做过测试了，详细请见：MySQL 5.6 vs MariaDB 5.5 vs Percona(5.5 & 5.6) 之TPCC性能测试。接下来继续测试其Replication(主从复制)功能，看看是否依旧能让人激动。

二、测试环境
2.1 测试环境和之前一样，详细见下图：

一、简述
是由原来 MySQL 的作者 Michael Widenius 创办的公司所开发的免费开源的数据库服务器。MariaDB基于事务的Maria存储引擎，替换了MySQL的MyISAM存储引擎，它使用了Percona的 XtraDB，InnoDB的变体。这个版本还包括了 PrimeBase XT (PBXT) 和 FederatedX 存储引擎。(摘自：http://baike.baidu.com/view/2521908.htm)
简单的说：MariaDB是MySQL的一个变种，可以作为官方MySQL版本的一个替代品，并且在一些特性上做了增强。
MariaDB的官网见：http://mariadb.org

二、测试环境
2.1 详细测试环境见下图：

一、准备工作
自从2009年测试MySQL Cluster 7.0之后，就没怎么关注过它，发展实在太慢了，还有很多不靠谱的地方。前阵子退出7.2.7版本后，看了看新特性介绍，号称性能比以往版本高了很多，于是再关注并进行测试。
部署过程不多说，下载PRM包后直接安装即可。共10个节点，其中1个管理节点，其他9个节点同时作为数据和SQL节点，所有节点服务器配置图：

MySQL Cluster管理节点关键配置见下：

一、前言
Innodb Plugin引擎开始引入多种格式的行存储机制，目前支持：Antelope、Barracuda两种。其中Barracuda兼容Antelope格式。
另外，Innodb plugin还支持行数据压缩特性，不过前提是采用Barracuda行存储格式。
表空间启用压缩的前提是innodb表空间文件存储格式修改成：Barracuda，需要修改2个选项：
innodb_file_format = "Barracuda"
innodb_file_format_max = "Barracuda"

下面是对比测试结果
二、表空间压缩比
1. 某项目数据表压缩比
2.1 数据表tabA
压缩之前
-rw-rw---- 1 mysql mysql 19038208 Mar 21 13:59 tabA.ibd（18.1G）
压缩之后
-rw-rw---- 1 mysql mysql 9.2G Mar 21 19:11 tabA.ibd
相差：12414976 ~= 12124 MB ~= 11.83 Gb，节约49.32%

1. 目的
通过对比测试，分析某数据表tabC拆分方案前后性能对比，确定拆分方案的可行性。

2. 方法
对拆分方案前后两种类型进行对比测试。
同时，每次测试中采用两种更新方式：
1. 和原来类似，对数据表所有字段的更新分多次
2. 对数据表所有字段的更新一次性完成

3. 环境
本次测试采用线上实际数据导入。tabC表共有132万行记录，全表共100G。
将所有字段重新组合，确保每个分表的实际行长度不高于8KB，拆分成3个子表，大小分别是：
tabC_1.ibd 796M
tabC_2.ibd 10.2G
tabC_3.ibd 8.4G

之后再进行全表随机更新，每轮测试都在脚本中并发调用存储过程来完成，最大10个并发进程。
每次测试之前都重启mysqld，且无其他额外压力，确保环境公平。

4. 结果

目录：

• 1、前言
• 2、安装
•  2.1 LVS 安装、配置
•  2.2 MySQL Cluster安装
• 3、测试
•  3.1 mysqlslap测试结果
•  3.2 sysbench测试结果

1、前言

随着数据量规模的扩大，企业对 MySQL 的要求就不仅仅是能用了，也在寻求各种高可用方案。以前我们的大部分高可用方案其实还存在一定缺陷，例如 MySQL Replication 方案，Master 是否存活检测需要一定时间，而和 Slave 的切换也需要时间，因此其高可用程度较大依赖监控软件或自动化管理工具。而早先的 MySQL Cluster 实在不能令人满意，性能差的不行，也让我们的期待一次次落空。本次 MySQL Cluster 7.0 的推出，终于实现了质的飞跃，性能上得到了很大提高。MySQL Cluster 7.0 新特性主要体现在以下几个方面：

• 数据节点多线程
• 可以在线增加节点
• 大记录存取改进
• 支持windows平台

本身MySQL Cluster已经实现了高可用，不过由于SQL节点无法对外部负载均衡，因此我们采用 LVS 来实现这一需求。

MySQL 5.1中增加了分区(partition)功能，有了这个功能，以前很头疼的分表方案，现在就变得不再那么麻烦了。不过，如果采用了MyISAM引擎，而且在数据量较大的情境下，并发读写仍然是个问题，尤其是对索引的更新。为此，可以在分区表中采用MyISAM和InnoDB引擎混用的方法，大致如下：

前言

InnoDB存储引擎满足了MVCC和ACID特性，在需要支持事务的环境下必不可少。有些环境下，采用InnoDB可能效果比MyISAM还要来的好。不过，在很多人眼中看来，InnoDB表空间文件由于无法实现跨服务器平滑迁移，因此不愿意使用。实际情况真是这样吗？本文就来探讨一下InnoDB表空间文件的平滑迁移可能性。

如何迁移？

从MySQL文档中我们了解到，InnoDB的表空间可以是共享的或独立的。如果是共享表空间，则所有的表空间都放在一个文件里：ibdata1,ibdata2..ibdataN，这种情况下，目前应该还没办法实现表空间的迁移，除非完全迁移，因此不在本次讨论之列；我们只讨论独立表空间的情况。

参考文章：Making MySQL more usable: InnoDB save/restore buffer pool patch。
Jeremy Cole同学写了个补丁，用于将InnoDB 缓冲池(buffer pool)里的列表在关闭mysqld时保存到本地文件中，重启启动时再加载到内存中去。该补丁目前只适用于MySQL 5.1版本。作者计划该补丁至少应具备以下几点要求：

• 可以自定义本地文件名
• 可以在启动时自主选择是否需要加载到内存中
• 支持在接受用户请求前先加载一部分，剩下的可以放到后台进程中继续加载

原文出自：The new cool MySQL patch has landed! Check your queries performance!，本文做只部分翻译。

MySQL微秒慢查询(microtime slow query)补丁包具有以下特色：

• 识别连接

每个慢查询结果中都记录了是哪个连接线程引起的，如下：

# Thread_id: 571