Google向MariaDB 10.1.13（暂未Release）贡献了这个补丁，可以对表/表空间进行加密。

加密过的表可以防止某些非授权用户访问或偷取磁盘然后通过访问原始数据文件来偷取数据。当然，假设你已经把密钥文件存储在另一个系统上。但是，使用加密可能会降低差不多10%的性能。目前，只有XtraDB/InnoDB引擎能完全支持加密。

TokuDB的日志跟InnoDB不一样，它有两类文件:

1. redo-log文件(以.tokulog[序号]为扩展名)
2. rollback日志文件(tokudb.rollback)

接下来就简单唠唠这两类文件的内部细节。

自MariaDB 10.1.2起，MariaDB提供了一种”Per-query variables的方式来为Query设置语句级变量，通过 SET STATEMENT 语句可以为接下来要执行的语句设置一些系统变量值。

问题描述

5.6.4及以上版本，datetime,time,timestamp的Binlog在5.6.4以下的备库无法执行，如：

5.6.16（主库）: create table t1(t datetime default now()); insert into t1 values(now());

5.5.18（备库）: show slave stauts\G ;

此时备库中断，报错：Last_Errno: 1677，

描述信息：Last_Error: Column 1 of table t1.t’ cannot be converted from type ‘’ to type ‘datetime’

详情见Bug#70085

背景

在上一期的月报中，我们在InnoDB自增列重复值问题中提到，InnoDB 自增列在重启后会丢失，因为MySQL没有持久化自增值，平时是存在内存表对象中的。如果实例重启的话，内存值丢失，其初始化过程是做了一个类似 select max(id) + 1 操作。实际上存在另外一种场景，实例即使不重启，也会导致自增值丢失。

背景

MySQL 5.6.6 版本新加了这样一个参数——log_bin_use_v1_row_events，这个参数用来控制binlog中Rows_log_event的格式，如果这个值为1的话，就用v1版的Rows_log_event格式（即5.6.6之前的），默认是0，用新的v2版本的格式，更详细看官方文档。这个参数一般保持默认即可，但是当我们需要搭 5.6->5.5 这要的主备的时候，就需要把主库的这个值改为1，不然5.5的备库不能正确解析Rows_log_event。最近在使用这个参数的时候发现了一个bug，导致主库binlog写坏，备库复制中断，报错如下：

PostgreSQL内核中引入了一个很有意思的插件，pg_prewarm。它可以用于在系统重启时，手动加载经常访问的表到操作系统的cache或PG的shared buffer，从而减少检查系统重启对应用的影响。这个插件是这个通过这个patch加入PG内核的。 pg_prewarm的开发者在设计pg_prewarm时，把它设计成一个执行单一任务的工具，尽求简单，所以我们看到的pg_prearm功能和实现都非常简单。下面我们对它进行性能实测并分析一下它的实现。

PostgreSQL 9.4 已于2014年底正式发布了（阿里云的RDS将支持PG 9.4）。在这个版本，我们看到了像Jsonb, Logical Decoding, Replication Slot等新功能。

本节摘取了MySQL5.6.23的几个和InnoDB相关的主要bugfix，简单阐述下问题及解决方案。

背景

我们知道InnoDB使用buffer pool来缓存从磁盘读取到内存的数据页。buffer pool通常由数个内存块加上一组控制结构体对象组成。内存块的个数取决于buffer pool instance的个数，不过在5.7版本中开始默认以128M（可配置）的chunk单位分配内存块，这样做的目的是为了支持buffer pool的在线动态调整大小。