半年之前我有幸参加了MySQL2010用户大会，Oracle/Sun在会上公布了MySQL5.5的新特性，这次MySQL5.5改进的地方非常之多，当中引入的Google patch for MySQL中的半同步Semi-synchronous Replication，一个可用于高可用解决方案的新特性。谭俊青@MySQL实验室

MySQL5.5的在复制/同步方面的改进：

• 保证主从服务器上数据的一致性（同步）
• 能立检测到复制的异常
• Crashed Salve能自动从错误中恢复同步
• 在环形复制中用户能够指定跳过某实例事件
• 主从复制中能自动适应字段类型的转换

MySQL半同步复制(semi-synchronous replication)

复制心跳（用户检测复制是否中断）

MySQL5.5提供的新的配置master_heartbeat_period，能够在复制停止工作和出现网络中断的时候帮助我们迅速发现问题。

启用方法：

STOP SLAVE;

CHANGE MASTER TO master_heartbeat_period= milliseconds;

START SLAVE;

Slave自动恢复同步

在MySQL5.5版本之前，MySQL Slave实例在异常终止服务之后，可能导致复制中断，并且relay binlog可能损坏，在MySQL再次启动之后并不能正常恢复复制。在MySQL5.5中这一问题得到了解决，MySQL可以自行丢弃顺坏的而未处理的数据，重新从master上获取源数据，进而回复复制。

跳过指定复制事件

在多Master或环形复制的情况下，处于复制链条中间的服务器异常，可以通过

CHANGE MASTER TO MASTER_HOST=xxx IGNORE_SERVER_IDS=y

跳过出问题的MySQL实例。

自动转换字段类型

MySQL5.1在基于语句的复制下，支持部分的字段转换，但是行级的会报错。MySQL5.5语句和行级复制都已支持。还可以通过 SLAVE_TYPE_CONVERSIONS 控制转换的方向。

相信有不少同仁已经做过过SSD作为存储对IO瓶颈的数据库性能测试，在得到可喜的成绩之余，在用于生产环境之前需要解决一些问题。

InnoDB共享表空间包含：
Data dictonary
Double write buffer
Insert buffer
Rollback segments
UNDO space … 【阅读全文·MySQL实验室】

距离Matthew Yonkovit发布Waffle Grid已经有一年多了，最近看到qlks发布了Secondary Buffer Pool in InnoDB，又让我想起来了waffle。waffle做的事情也是InnoDB的二级缓存，但是用的不是SSD，而是Memcached。如果将所有的buffer都用memcached实现，进一步就可以实现内存的分布式共享，进而实现MySQL RAC。需要做的工作会不少，但应该是个可行的办法… … 【阅读全文·MySQL实验室】

这次2010 MySQL UC上MySQL在MySQL5.5-m3发布没多久之后紧急发布了MySQL5.5-m4及InnoDB Plugin 1.0.7 (GA) 和 InnoDB Plugin 1.1。敏感的人应该发现了这点，其实这背后是因为 Percona给了MySQL官方和InnoDB Team太多的压力。早在InnoDB Plugin 1.0.7 和 1.1发布之前，XtraDB的性能一度超越Built InnoDB及InnoDB plugin高达30%。让我们先看看Percona XtraDB之前都已经具备了哪些些特性：By ivan@mysqlab.net … 【阅读全文·MySQL实验室】

自从Sun被Oracle收购之后，大家对MySQL的前途抱有或多或少的担忧。下面是我重新整理下MySQL5.5的一些让人激动的新特新，来表明MySQL的活力，希望籍此能让大家对MySQL充满信心。

之前介绍过MySQL5.x的一些特性(MySQL新版5.x及特性, MySQL 5.5 表分区功能增强, MySQL 5.5 Released非GA等)，先整理下，让大家对MySQL5.5有个整体的认识。 By Ivan@mysqlab.net, 谭俊青@MySQL实验室 … 【阅读全文·MySQL实验室】

InnoDB Plugin 1.0.7 已经GA了，最让人兴奋的当属crash recovery时间大大的缩短，以后redo log可以顶着4G用了(xtraDB可以超过4G)，这样可以很大程度上降低IO需求（为什么？）、从而极大地提高InnoDB的写性能。

另外MySQL5.5+InnoDB plugin 1.1改进的几个地方确实让人兴奋，比如Multiple Rollback Segments(不再有1024并发事务的限制), Split Buffer Pools(这个以后发展下去可以指定某些表常住内存，相当于事务安全的内存表，还没有表锁限制，又是变长字段，相比现在内存表来说优秀太多了)，InnoDB Performance Schema，还有Replication durability等,再加行已有的semi-replication, MySQL5.5GA真是让人迫不及待。 … 【阅读全文·MySQL实验室】

忽如一夜春风来，人人开口NoSQL。NoSQL现在是火了，可大家有想过没，其实NDB, InnoDB是很好的NoSQL数据库，InnoDB有double write buffer可以保证数据的安全性而且身经百战，NDB提供API可供直接调用。而且如果你愿意，你可以在InnoDB前面加上MySQL，它就变成了关系型数据库；NDB加上ndb引擎，结合MySQL摇身一变，也成了关系型数据库。

　　MySQL 5.1.42 预计在今年(2009）12月18日发布，其中会包含最新的Innodb Plugin。新的InnoDB Plugin在除了支持Data compression和Fast index create特性之外，兼容之前的表空间，并加入了大量Google的patch，极大的提高了Innodb的性能。

MySQL 5.4 GA 预计可能在明年夏季，roadmap如下图：

MySQL 5.5 会加入Google semi-replication patch,Google原链接。

MySQL Cluster Manager 加入自动管理功能，不过应该会收费。

———————————————-
这几天去fetion看了他们的DB，服务器奢侈(可能穷惯了)，性能也很强劲30k+的QPS。不过构架有些问题，以后我想应该会改；另外还去了现场帮客户解决问题。至此来北京的计划全部打乱。下次一定提前安排，组织一次MySQL实验室聚会。

前段时间看innodb plugin源码的时候，看到有如下一段
include/univ.i

尝试将 UNIV_PAGE_SIZE_SHIFT 改成13 (相当于page size为8K)，编译通过并可以正常使用。
后来找到Google的MySQL团队发表的一篇文章，文中的介绍 Innodb page size 可以选择 8K、 16K、 32K、 64K。不过因为Innodb每个page都有不小的冗余空间，从空间和内存利用的角度来讲，page size越大越好。但是从checkpoint的角度来讲恰恰相反，page size越小，性能越好（上次演讲的时候我介绍过原理）。所以最后选择多大的page size可以根据实际的业务测试而定。

InnoDB Plugin 1.0.4 这次加入了不少第三方的代码，个人比较在意的是 Google 和 Percona 提供的部分。Innodb从而实现了性能上很大的提升，不想以前在并发稍大（比如>8)，吞吐量升值会下将，现在却又很大的提升。

个人关注的改进部分有：

1： Multiple Background Threads

最初由Google提供的补丁，参数 innodb_file_io_threads 可以设置io threads的数量，之前是假的…

2：Master Thread I/O Capacity Tuning

之前innodb在代码里面写死了 innodb_io_capacity 为100，但是现在db服务器很多都是用多块硬盘做raid10，IOPS 一般都远不止100，因此这次改进之后  innodb_io_capacity 变成可以动态调整的参数，用于DBA选择一个合适的值。

3：Group Commit

这个据说以前4.x之前就支持的，现在又回来了，支持多个事务同时提交（主要是redo log，之前是因为binlog的2-phase commit protocal的原因中止的），从而提高吞吐量。

4：Adaptive Flushing

这个非常有用，大家知道在脏数据到达设置的阀值比例之后，会开始主动做checkpoint，当checkpoint无可避免的时候，这时候会堵塞用户线程，从而出现性能的突然下降。现在这个问题得到巧妙的解决，会根据算法动态的调整checkpoint的速率，避免出现性能的突然降低。

REFERENCE:

http://www.innodb.com/wp/2009/08/11/innodb-plugin-104-released/

http://www.innodb.com/wp/products/innodb_plugin/license/third-party-contributions-in-innodb-plugin-1-0-4/

Yasufumi 提供了一个用户在innodb crash后快速恢复的补丁

如果最后该补丁能够纳入官方体系，那么Innodb将在性能上又有很大的提升。

上次MySQL中文实验室的聚会中介绍了buffer大小，redo log大小，checkpoint对性能的影响。那么如果大的redo log能在crash后快速回复的话，我们可以将redo log设置到最大，这样可以尽可能降低checkpoint的次数，来提升数据库的性能。

再者还可以将redo log 4G的限制从源码上解决，从而适应现在动则上10G的buffer。

随着数据量的增大,在数据库的扩展上通常遇到切分时保证键值的唯一性问题，遇到这种情况，通常有如下几种相对简单的解决方案：

1  UUID 这种方案的优点是实现和管理简单，缺点是占用空间大，查询效率低下。

2  Sequence Number 优点是实现和管理简单，确定是有性能瓶颈和单点问题。

3  不同的集群采用的起始点或者增长间隔不同 这种方案实现简单，但是后期管理麻烦。