MySQL内核月报 2014.09-TokuDB· 参数故事·数据安全和性能

提要 MySQL 5.5.39 Release版本正式从源码里删除了全局参数timed_mutexes.timed_mutexes原本用来控制是否对Innodb引擎的mutex wait进行计时统计,以方便进行性能诊断.为什么要删除这个参数呢? 下面介绍下相关背景: Innodb的同步锁机制 Innodb封装了mutex和rw_lock结构来保护内存的变量和结构,进行多线程同步,考虑可移植性, mutex使用lock_word或者OS mutex来保证原子操作,并使用event条件变量进行阻塞和

背景 GTID 可以说是 MySQL 5.6 版本的一个杀手级特性,它给主备复制带来了极大的便利,RDS只读实例就是强依赖于这个特性.然而GTID在给我们带来便利的同时,也埋下了许多坑,最近几期内核月报中GTID的频繁出现也说明了这一点,对其我们可以说是既爱又恨. GTID 并不是免费午餐,要使用它是要有代价的,为了保证GTID这个体系能够运转起来,需要做许多相关的工作,比如binlog里每个事务要多记 gtid_event 这种事件.写binlog的时候要生成 gtid.要维护几个GTID集合

TokuDB企业版提供热备功能(与社区版唯一的区别). 该功能以plugin方式提供,当backup plugin加载后,它会拦截所有的文件操作(比如文件读写/目录操作等),从而实现在备份的过程中增量同步,具体原理请看: http://www.tokutek.com/2013/09/tokudb-hot-backup-part-1/ http://www.tokutek.com/2013/09/tokudb-hot-backup-part-2/  社区版如何实现热备呢? 官方推荐的方式是mylv

MySQL在开启Binary Log的情况下,使用2PC(图1)来保证事务(XA)完整性的,每次提交事务需要做: 每个事务在提交的时候都要做3次fsync以确保日志真正的落盘,这样在log里,一个事务就会有3种状态: 这样,无论处于任何一个状态,事务的完整性都不会被破坏,但是每次提交会产生3次fsync,性能非常低. 为了提升性能,MySQL 5.6增加了group commit功能,当多个事务并发提交时,让多个都在等待fsync的事务合并做一次fsync,大大提升了吞吐量. 但是这个优化还需要

第一期先介绍下TokuDB团队吧. TokuDB自从开源后(更赞的是开源了所有的commits),逐渐被大家所熟悉,MariaDB 5.5系列和Percona Server 5.6的GA版本中,都以plugin的方式集成. 3位(Tokutek)创始人: Michael A. Bender , Martín Farach-Colton , Bradley C. Kuszmaul  2012年他们合发了一篇208页的pdf[Data Structures and Algorithms for Bi

背景 引入MDL锁的目的,最初是为了解决著名的bug#989,在MySQL 5.1及之前的版本,事务执行过程中并不维护涉及到的所有表的Metatdata 锁,极易出现复制中断,例如如下执行序列: Session 1: BEGIN; Session 1: INSERT INTO t1 VALUES (1); Session 2: Drop table t1; --------SQL写入BINLOG Session 1: COMMIT; -----事务写入BINLOG 在备库重放 binlog时,会

尽管MySQL 5.6和MariaDB 10.x在replication上已经做了不少优化,TokuDB 7.5也做了一个＂进一步＂的优化:Read Free Replication(RFR),目的是提高备库(slave)重放速度,减少主备延迟. RFR的原理比较简单:就是避免一些＂不必要＂的读来减少read IO. Read IO 当在slave上执行:UPDATE/DELETE操作的时候,MySQL进行read-modify-write操作,可能会产生read IO操作,而INSERT的时候

MySQL的update在执行时需要做read-modify-write: 操作路径还是比较长的,TokuDB提供了fast update语法,让＂某些＂场景下update更快,无需做read和modify直接write. 用法: NOAR语句: 语义是:插入一条记录,如果该记录存在(id为1),就对count的值做加法操作,不存在则做插入. 注意: fast updates的条件是比较苛刻的,必须满足: 看了这些苛刻的条件后,有种＂臣妾做不到＂的感觉了吧,可以看出TokuDB一直为细节而努力.

大连接问题 现有mysql 处理客户端连接的方式会触发mysql 新建一个线程来处理新的连接,新建的线程会处理该连接所发送的所有 SQL 请求,即 one-thread-per-connection 的方式,其创建连接的堆栈为: 线程建立后,处理请求的堆栈如下: 0 mysql_execute_command 1 0x0000000000936f40 in mysql_parse 2 0x0000000000920664 in dispatch_command 3 0x000000000091e