背景

DocDB 自动同步复制数据，以便在发生故障的同时保持数据一致性并避免操作员干预。它使用 Raft 分布式共识协议来实现。

背景

关于Group Commit网上的资料其实已经足够多了，我这里只简单的介绍一下。

众所周知，在MySQL5.6之前的版本，由于引入了Binlog/InnoDB的XA，Binlog的写入和InnoDB commit完全串行化执行，大概的执行序列如下：

来自一个TokuDB用户的“投诉”:

https://mariadb.atlassian.net/browse/MDEV-6207

本文说明一个物理升级导致的 “数据丢失”。

现象

在mysql 5.1下新建key分表，可以正确查询数据。

问题描述

当单个 MySQL 实例的数据增长到很多的时候，就会考虑通过库或者表级别的拆分，把当前实例的数据分散到多个实例上去，假设原实例为A，想把其中的5个库（db1/db2/db3/db4/db5）拆分到5个实例（B1/B2/B3/B4/B5）上去。

bug描述

Oracle 最新发布的版本 5.6.22 中有这样一个关于GTID的bugfix，在主备场景下，如果我们在主库上 SET GLOBAL GTID_PURGED = “some_gtid_set”，并且 some_gtid_set 中包含了备库还没复制的事务，这个时候如果备库接上主库的话，预期结果是主库返回错误，IO线程挂掉的，但是实际上，在这种场景下主库并不报错，只是默默的把自己 binlog 中包含的gtid事务发给备库。这个bug的造成的结果是看起来复制正常，没有错误，但实际上备库已经丢事务了，主备很可能就不一致了。

背景

客户使用mysqldump导出一张表，然后使用mysql -e ‘source test.dmp’的过程中client进程crash，爆出内存的segment fault错误，导致无法导入数据。

问题重现

先从问题入手，重现下这个bug

前言

与oracle 不同，mysql 的主库与备库的同步是通过 binlog 实现的，而redo日志只做为mysql 实例的crash recovery使用。mysql在4.x 的时候放弃redo 的同步策略而引入 binlog的同步，一个重要原因是为了兼容其它非事务存储引擎，否则主备同步是没有办法进行的。

背景

MySQL从5.6版本开始支持GTID特性，也就是所谓全局事务ID，在整个复制拓扑结构内，每个事务拥有自己全局唯一标识。GTID包含两个部分，一部分是实例的UUID，另一部分是实例内递增的整数。

GTID的分配包含两种方式，一种是自动分配，另外一种是显式设置session.gtid_next，下面简单介绍下这两种方式：