问题重现

搭建一主一备，主备配置分别如下 ，同时设置备库的auto_position=0

背景描述

之前我们遇到一个咨询，客户说：

1. 同一个表，col1=a，col2=b，做 update，set col1=col2，col2=col1，这时候两个都是b
2. 不同表，A表 col1=a，B表 col2=b，做 update，就能进行交换 为什么不同表就能交换呢？

bug背景

官方 5.7.6 版本对 gtid 有非常多的改进和bugfix，其中有一个 bugfix 是针对 relay log 中没有接收完整的 gtid 事务的。正常的relay log 中的 gtid 事务应该是像下面这样：

1. gtid event
2. query event (begin)
3. row event (write/update/delete)
4. query event (commit)

背景

官方 5.6 最新版本 5.6.24 有这样一个bugfix，当使用 GTID 协议进行复制，并且备库的 slave_net_timeout 值设置太小的话，备库的 slave io 线程会卡住，同时主库上的 binlog dump 线程数一直在涨，官方的bug地址 。

我们看到在MySQL 5.7版本里大量遗留很多年的bug都被fix掉了，bug#12161就是其中一个，该bug在2005年第一次report到Bug list上，十年之后终于在MySQL 5.7.7 第一个RC版本被fix了。

本文是对整个Undo生命周期过程的阐述，代码分析基于当前最新的MySQL5.7版本。本文也可以作为了解整个Undo模块的代码导读。由于涉及到的模块众多，因此部分细节并未深入。

bug描述

设置 foreign_key_checks=0 删除被引用的索引后，再设置foreign_key_checks=1，对引用表进行DML操作会导致 mysqld crash，以下是重现的测例：

1
2
3
4
5
6
7
8
9
10
11

drop table if exists t2;
drop table if exists t1;

create table t1 (a int, b int, key idx1(a)) engine=innodb;
insert into t1 values(1,1);
insert into t1 values(2,2);
create table t2 (a int, b int, foreign key (b) references t1(a)) engine=innodb;
set session foreign_key_checks = 0;
alter table t1 drop key idx1;
set session foreign_key_checks = 1;
insert into t2 values (1,1); //此语句执行时mysqld会crash

PgSQL 9.4.1在2015年2月5日发布，主打的是安全方面的更新，修补了如下的安全漏洞：

• CVE-2015-0241 Buffer overruns in “to_char” functions.
• CVE-2015-0242 Buffer overrun in replacement printf family of functions.
• CVE-2015-0243 Memory errors in functions in the pgcrypto extension.
• CVE-2015-0244 An error in extended protocol message reading.
• CVE-2014-8161 Constraint violation errors can cause display of values in columns which the user would not normally have rights to see.

简介

TokuDB使用LockTree(ft-index/locktree)来维护事务的锁状态(row-lock和range-lock)，LockTree的数据结构是一个Binary Tree。
本篇将通过几个“栗子”来谈谈TokuDB的row-lock和range-lock。

TokuDB简介

TokuDB是一个支持事务的“新”引擎，有着出色的数据压缩功能，由美国TokuTek公司(http://www.tokutek.com/\) 研发，该公司于2015年4月份被Percona收购。 为了降低用户数据存储成本，云数据库(Aliyun RDS)增加了TokuDB引擎支持(MySQL5.6版本)。