想要查看TokuDB某个表占了多少磁盘空间，目前还没有太好的方法。 如果你使用’show table status’命令，得到的结果只会让你更迷茫:

1
2
3
4
5
6
7
8
9
10

           Name: toku
         Engine: TokuDB
        Version: 10
     Row_format: tokudb_zlib
           Rows: 28874059
 Avg_row_length: 30
    Data_length: 868159449
Max_data_length: 9223372036854775807
   Index_length: 2099497463
      Data_free: 0

问题出现

我们在线上巡检中发现，一个实例的pg_xlog目录，增长到4G，很是疑惑。刚开始怀疑是日志归档过慢，日志堆积在pg_xlog目录下面，未被清除导致。于是检查归档目录下的文件，内容如下。但发现新近完成写入的日志文件都被归档成功了（即在pg_xlog/archive_status里面，有对应的xxx.done文件）。

Listen 和 Notify 是PG很有意思的一个功能，可以用来进行多应用间的通信。它们可以在SQL中使用，也可以用C、JDBC里面的API调用。下面介绍一下其使用方法和内核实现。

背景

从 MairaDB 10.0.5 开始，MariaDB 开始提供 Role（角色）的功能，补全了大家一直吐槽的 MySQL 不能像 Oracle 一样支持角色定义的功能。

一个角色就是把一堆的权限捆绑在一起授权，这个功能对于有很多用户拥有相同权限的情况可以显著提高管理效率。在有角色之前，这种情况只能为每个用户都做一大堆的授权操作，或者是给很多个需要相同权限的用户提供同一个账号去使用，这又会导致你要分析用户行为的时候不知道哪个操作是哪个具体用户发起的。

有了角色，这样的管理就太容易了。例如，可以把权限需求相同的用户赋予同一个角色，只要定义好这个角色的权限就行，要更改这类用户的权限，只需要更改这个角色的权限就可以了，变化会影响到所有这个角色的用户。

问题描述

RDS 有个任务叫做恢复到任意时间点，相当于一个数据时光机，可以将数据恢复到过去任意一个时间点，在用户出现误操作需要将数据找回时非常有用。这个功能主要是通过备份集恢复 + binlog回放实现，在用备份集恢复出的实例上应用 binlog 到指定时间点。

然而最近线上重放binlog时遇到了这样一个错误：

1

Table xxxx already exists

背景

6.5号，小编在 Aliyun 的论坛中发现一位开发者提的一个问题，说 RDS 发现了一个超级大BUG，吓的小编一身冷汗 = =!! 赶紧来看看，背景是一个RDS用户创建了一张表，在一个都是NULL值的非索引字段上进行了排序并分页，用户发现第二页和第一页的数据有重复，然后以为是NULL值的问题，把这个字段都更新成相同的值，发现问题照旧。详细的信息可以登录阿里云的官方论坛查看。

小编进行了尝试，确实如此，并且5.5的版本和5.6的版本行为不一致，所以，必须要查明原因。

问题描述

在RDS生产环境中，一个MySQL实例莫名地被shutdown了, 日志中有如下信息：

1
2
3
4
5
6
7
8
9
10
11

150525 15:30:52 [Note] User 'userxx' issued shutdown command
150525 15:30:52 [Note] /path/to/mysqld: Normal shutdown
150525 15:30:52 [Note] Stop asynchronous binlog_dump to slave (server_id: xxxxx)
150525 15:30:52 [Note] Event Scheduler: Killing the scheduler thread, thread id xxx
150525 15:30:52 [Note] Event Scheduler: Waiting for the scheduler thread to reply
150525 15:30:52 [Note] Event Scheduler: Stopped
150525 15:30:52 [Note] Event Scheduler: Purging the queue. 0 events
150525 15:30:53 [Note] User 'userxx' issued shutdown command
150525 15:31:07 [Note] Slave I/O thread exiting, read up to log 'log.xxxxx', position xxxxxx
150525 15:31:07 [Note] Error reading relay log event: slave SQL thread was killed
150525 15:31:09 [Note] User 'userxx' issued shutdown command

背景

我们知道当一张表的某个字段存在重复值时，这个字段没办法直接加UNIQUE KEY，但是MySQL提供了一个 ALTER IGNORE TABLE的方式，可以忽略修改表结构过程中出现的错误，但是要忽略UNIQUE重复值，就需要打开old_alter_table，也就是拷贝表的方式来ALTER TABLE。

唯一键是数据库设计中常用的索引类型，主要用于约束数据，不允许出现重复的键值记录。可以想象，如果唯一键约束失效了，将可能产生可怕的逻辑错误。本文主要讨论下最近MySQL爆出来的两个唯一键约束失效导致二级索引corruption的问题。

在前面两期月报中，我们详细介绍了 InnoDB redo log 和 undo log 的相关知识，本文将介绍 InnoDB 在崩溃恢复时的主要流程。

本文代码分析基于 MySQL 5.7.7-RC 版本，函数入口为 innobase_start_or_create_for_mysql，这是一个非常冗长的函数，本文只涉及和崩溃恢复相关的代码。