概述

在RocksDB中每一次数据的更新都会涉及到两个结构，一个是内存中的memtable(后续会刷新到磁盘成为SST),第二个是WAL(WriteAheadLog)。 本篇文章主要就是来介绍WAL.

WAL主要的功能是当RocksDB异常退出后，能够恢复出错前的内存中(memtable)数据,因此RocksDB默认是每次用户写都会刷新数据到WAL. 每次当当前WAL对应的内存数据(memtable)刷新到磁盘之后，都会新建一个WAL.

所有的WAL文件都是保存在WAL目录(options.wal_dir),为了保证数据的状态，所有的WAL文件的名字都是按照顺序的(log_number).

bug描述

这是5.6中和gtid相关的一个bug，当 mysqld 收到 sighup 信号 （比如 kill -1） 的时候，会 flush binlog，但是新生成binlog开头没写 Previous_gtids_log_event，这会导致下面 2 个问题：

这个时候 mysqld 重启的话，会发现再也起不来了，error log 里有这样的错 The binary log file ‘mysql/mysql-bin.000020’ is logically corrupted: The first global transaction identifier was read, but no other information regarding identifiers existing on the previous log files was found.

这个时候主库继续更新，然后从库来拉取 binlog 的时候，io 线程会停下来 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Error reading header of binary log while looking for the oldest binary log that contains any GTID that is not in the given gtid set’

bug 描述

这是一个和 GTID 相关的Bug，也就是说5.6才会有，并且出现这个 bug 需要满足条件：

1

做修改性质的表管理操作，如 OPTIMIZE/ANALYZE/REPAIR 可以，CHECK 就不可以 操作对应的表不存在 gtid_next 被设置为一个固定的值，并且 binlog 开启 在同时满足这3种条件下，会发现记录binlog时，对应的 Gtid_log_event 中的UUID会记为 00000000-0000-0000-0000-000000000000，并且这个对应的 gtid 不会记入 Executed_Gtid_Set。

概述

首先我们知道在RocksDB中，最终数据的持久化都是保存在SST中，而SST则是由Memtable刷新到磁盘生成的，因此这次我们就主要来分析在RocksDB中何时以及如何来Flush内存数据(memtable)到SST.

简单来说在RocksDB中，每一个ColumnFamily都有自己的Memtable,当Memtable超过固定大小之后(或者WAL文件超过限制)，它将会被设置为immutable,然后会有后台的线程启动来刷新这个immutable memtable到磁盘(SST).

TokuDB除了有着较好的写性能外，还有一个重要的特性：压缩，而且大部分情况下压缩效果很不错。

目前TokuDB有４种压缩算法：

1
2
3
4

tokudb_lzma:	压缩比高，CPU消耗也高
tokudb_zlib:	压缩比和CPU消耗持中(默认压缩算法)
tokudb_quicklz:	压缩比低，CPU消耗低
tokudb_uncompressed:无压缩

命令的输出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

MariaDB> analyze select * from tbl1 where key1 between 10 and 200 and col1 like 'foo%'\G
*************************** 1\. row ***************************
id: 1
select_type: SIMPLE
table: tbl1
type: range
possible_keys: key1
key: key1
key_len: 5
ref: NULL
rows: 181
r_rows: 181
filtered: 100.00
r_filtered: 10.50
Extra: Using index condition; Using where

提要

长久以来，server层和InnoDB层都保存了表的元数据，server使用frm文件保存了column，data_types等信息，而InnoDB使用data dictionary来保存meta data。

由于server层使用文件系统，而InnoDB使用事务引擎，所以经常会存在两者不一致的情况，比如：

提要

相对于纳秒级的内存访问延时，普通的机械盘达到了毫秒级的随机访问延时，对于OLTP应用来说，物理IO绝对是目前数据库管理系统的最大性能杀手，所以增加内存的大小，提高IO的命中率无疑可以作为一种降低时延的常用优化手段。

针对使用InnoDB引擎的MySQL实例来说，增加buffer pool的大小，尽可能的提高buffer pool的命中率，减少物理IO的概率，能极大的提升系统的吞吐量。

但是，随着内存越来越大，面临着一个很严重的问题：当内存突然失效，或者实例异常crash后，面对相同的请求压力，或者突然的大压力，系统由于内存未命中会耗尽IO资源，并导致request响应变慢，形成雪崩效应。

bug背景

官方最近发布的版本(5.7.5)修复了这样一个bug，主备复制场景下，如果主库和备库对应的表结构中有数据类型不一致，并且主库的 binlog 是 row 格式的，这时候如果主库对不一致的表做了一个大事务更新，备库在应用 relay-log 的时候报OOM(Out of Memory)。bug地址在这里，主备数据类型不一致主要发生在这2种情况下：

主备库版本不一致，不同版本之间的数据类型可能存在不一致。用户在报这个bug时，就是在5.5到5.6的复制场景下，用到了时间类型，时间类型在5.6.4版本时发生了变化 人为直接的连上从库 alter 表