MySQL · myrocks · myrocks写入分析

WriteBatch与Myrocks事务处理密切相关，事务中的记录提交前都以字符串的形式存储在WriteBatch- rep_中，要么都提交，要么都回滚。 回滚的逻辑比较简单，只需要清理WriteBatch- rep_即可。详见TransactionImpl::Rollback

#0 rocksdb::InlineSkipList rocksdb::MemTableRep::KeyComparator const ::Insert

#1 rocksdb::(anonymous namespace)::SkipListRep::Insert

#2 rocksdb::MemTable::Add

#3 rocksdb::MemTableInserter::PutCF

#4 rocksdb::WriteBatch::Iterate

#5 rocksdb::WriteBatch::Iterate

#6 rocksdb::WriteBatchInternal::InsertInto

#7 rocksdb::DBImpl::WriteImpl

#8 rocksdb::DBImpl::Write 

#9 rocksdb::TransactionImpl::Commit

#10 myrocks::Rdb_transaction_impl::commit_no_binlog

#11 myrocks::Rdb_transaction::commit

#12 myrocks::rocksdb_commit

#13 ha_commit_low

#14 TC_LOG_MMAP::commit 

#15 ha_commit_trans

#16 trans_commit_stmt

#17 mysql_execute_command

#18 mysql_parse

#19 dispatch_command

#20 do_command

#21 do_handle_one_connection

提交流程及优化

这里只分析rocksdb引擎的提交流程，实际MyRocks提交时还需先写binlog(binlog开启的情况).

rocksdb引擎提交时就完成两个事情
1. 写WAL日志(WAL开启的情况下rocksdb_write_disable_wal=off)
2. 将之前的WriteBatch写入到memtable中

然而，写WAL是一个串行操作。为了提高提交的效率， rocksdb引入了group commit机制。

待提交的事务都依次加入到提交的writer队列中，这个writer队列被划分为一个一个group. 每个group有一个leader， 其他为follower，leader负责批量写WAL。每个group由双向链表link_older， link_newer链接。如下图所示

每个writer可能的状态如下

writer的状态变迁跟group是否并发写memtable有关
当开启并发写memtable(rocksdb_allow_concurrent_memtable_write=on)且group中的writer至少有两个时，group才会并发写。

group并发写时writer的状态变迁图如下：

group非并发写时writer的状态变迁图如下：

源码结构图如下（图片来自林青）

上面的图是在group内writer并发写memtable的情形。
非并发写memtable时，没有LaunchParallelFollowers/CompleteParallelWorker, Insertmemtable是由leader串行写入的。
这里group commit有以下要点
1. 同一时刻只有一个leader, leader完成操作后，才设置下一个leader
2. 需要等一个group都完成后,才会进行下一个group
3. group中最后一个完成的writer负责完成提交和设置下一个leader
4. Leader 负责批量写WAL
5. 只有leader才会去调整双向链表link_older,link_newer.

注意这里2，3 应该可以优化改进为

WAL日志满，WAL日志超过rocksdb_max_total_wal_size，会从所有的colomn family中找出含有最老日志(the earliest log containing a prepared section)的column family进行flush, 以释放WAL日志空间 Buffer满，全局的write buffer超过rocksdb_db_write_buffer_size时，会从所有的colomn family中找出最先创建的memtable进行切换，详见HandleWriteBufferFull 某些条件会触发延迟写 max_write_buffer_number 3且 未刷immutable memtable总数 =max_write_buffer_number-1 自动compact开启时，level0的文件总数 = level0_slowdown_writes_trigger
未刷immutable memtable总数 =max_write_buffer_number 自动compact开启时，level0的文件总数 = level0_stop_writes_trigger
MySQL · RocksDB · TransactionDB 介绍 1. 概述 得益于LSM-Tree结构，RocksDB所有的写入并非是update in-place，所以他支持起来事务的难度也相对较小，主要原理就是利用WriteBatch将事务所有写操作在内存缓存打包，然后在commit时一次性将WriteBatch写入，保证了原子，另外通过Sequence和Key锁来解决冲突实现隔离。
MySQL · myrocks · collation 限制 MyRocks中的数据是按索引列以memcmp方式进行排序的。对于一些数字类型，需要进行转化才能直接通过memcmp进行比较， 例如有符号数在计算机中是用补码表示的，那么如果负数和正数直接按字节比较，结果负数会比正数大，实际存储时会将符号会反转存储，读取时再转化回来。
MySQL · RocksDB · 写入逻辑的实现 在RocksDB中，每次写入它都会先写WAL,然后再写入MemTable,这次我们就来分析这两个逻辑具体是如何实现的. 首先需要明确的是在RocksDB中，WAL的写入是单线程顺序串行写入的，而MemTable则是可以并发多线程写入的。
MySQL · 引擎分析 · InnoDB行锁分析 理解InnoDB行锁，分析一条SQL语句会加什么样的行锁，会锁住哪些数据范围对业务SQL设计和分析线上死锁问题都会有很大帮助。对于InnoDB的行锁，已经有多篇月报进行了介绍，这里笔者借鉴前面月报的内容，综合自己的理解，对源码的基础实现做一个介绍（会包含部分表锁介绍），然后结合具体SQL语句分析加锁类型和加锁范围。
MySQL · myrocks · 事务锁分析 MyRocks中RocksDB作为基于快照的事务引擎，其在事务支持上有别于InnoDB，有其自身的特点。在早期的月报[myrocks之事务处理] 中，我们对锁的实现有过简单的分析，本文会以一些例子来介绍MyRocks是如果来加锁解锁的。
MySQL · myrocks · myrocks监控信息 rocksdb本身提供了丰富的监控信息，myrocks通过information_schema下的表和show命令等将这些信息展示出来，下面主要以示例的形式来简单介绍下 先创建测试表 CREATE TABLE t1 (a INT, b CHAR(8), pk INT AUTO_INCREMENT ,PRIMARY KEY(pk) comment cf_1 , key idx2(b) comm
db匠 rds内核团队秘密研发的全自动卖萌机. 追加特效: 发数据库内核月报. 月报传送: http://mysql.taobao.org/monthly/