虽然PG 9.4发布不过半年时间，下一个大版本9.5却已经进入人们的视野。按目前的情况，2015年上半年可能发布beta版本，下半年正式发布PG 9.5。9.5里面最令人瞩目的一个新功能恐怕是BRIN索引了。下面这个commit加入了对BRIN索引的支持：

bug描述

在binlog_format=row模式下，事务中create或drop临时表后，后面再执行DML（影响多行的DML)如果失败，那么失败的DML会回滚，但DML仍然记录了binlog。这个 binlog 应用到备库后会导致主备不一致。 此bug已提给官方bug#76940。 以下是重现的测例：

背景

MySQL保存了两份元数据，一份在server层，保存在FRM文件中，另外一份在引擎层，比如InnoDB的数据字典中，这样也就造成了DDL语句经常导致元数据不一致的情况，下面介绍两个近期出现的因为DDL产生的bug。

bug 背景

RDS的备份工具用的是 Percona-XtraBackup（后面简称PXB），这个工具包里有2个重要的工具，innobackupex和xtrabackup，后者是C编译出的二进制文件，负责备份 InnoDB 数据，前者是一个Perl 脚本，对后者进行封装，同时负责备份非 InnoDB 数据。xtrabackup 二进制里内嵌了InnoDB引擎，所以能很好的处理InnoDB数据。

在2.2版本之前，PXB 分别针对不同版本的 MySQL 源码（5.1/5.5/5.6）编译了不同版本的xtrabackup，以便备份不同版本的MySQL数据，然而在2.2之后，PXB官方觉得5.6已经可以很好的兼容5.1和5.5，所以就只针对 5.6.22 版本的代码编译了一个 xtrabackup 二进制文件，关于这个改动可以看官方的BP #single binary。故事就由此发生。。。

背景

MySQL 非 GTID 协议主备同步原理： 主库在执行 SQL 语句时产生binlog，在事务 commit 时将产生的binlog event写入binlog文件，备库IO线程通过 com_binlog_dump 用文件位置协议从主库拉取 binlog，将拉取的binlog存储到relaylog, SQL线程读取 relaylog 然后进行 apply，实现主备同步，在这个过程中有以下几个问题：

1. 主库什么时间将产生的 binlog 真正刷到文件中？
2. 备库IO线程从哪个位置读取主库的 binlog event 的？
3. 备库SQL线程如何记录执行到的 relaylog 的位点？
4. 备库IO线程何时将cache中的event 刷到relay log 文件中的\?

背景

最近有同事问，set names 时会同时设置了3个session变量

1
2
3

SET character_set_client = charset_name;
SET character_set_results = charset_name;
SET character_set_connection = charset_name;

就从变量名字来看，character_set_client 是设置客户端相关的字符集，character_set_results 是设置返回结果相关的字符集，character_set_connection 这个就有点不太明白了，这个有啥用呢？

背景

目前，IO 仍然是数据库的性能杀手，为了提高 IO 利用率和吞吐量，不同的数据库都设计了不同的方法，本文就介绍下 InnoDB 提供的预读(read-ahead)功能，以及 Oracle 提供的多块读(multiblock-read)功能，并进行一些对比。

问题背景

我们在管理繁忙的 MySQL 数据库时，可能都有碰到 SYS CPU 高的经历：系统突然 SYS CPU 高起来，甚至比 USER CPU 高很多，这时系统 QPS、TPS 急剧下降。

SYS CPU高是什么造成的呢？主要有2种可能：

1. context switch 不高，但在内核态 spin，导致 SYS CPU 高
2. context switch 高，每秒超过 200K，有时超过1M，过多 context switch 导致 SYS CPU 高

下面我们对这两种情况逐一分析。

压缩很任性

TokuDB有着出色的压缩特性，这不是”盖”的： RDS上有个InnoDB实例，1天的数据将近700GB空间，换成TokuDB后(默认zlib压缩)，同样的700GB可以保存５天的数据，业务读写性能也无任何影响，空间成本直线下降。

为什么TokuDB的压缩这么给力？ 因为TokuDB一个“页”的大小为4MB，压缩起来，这酸爽…

前言

InnoDB 有两块非常重要的日志，一个是undo log，另外一个是redo log，前者用来保证事务的原子性以及InnoDB的MVCC，后者用来保证事务的持久性。

和大多数关系型数据库一样，InnoDB记录了对数据文件的物理更改，并保证总是日志先行，也就是所谓的WAL，即在持久化数据文件前，保证之前的redo日志已经写到磁盘。