MySQL

MySQL复制性能

MySQL5.6 以后，提供了基于 GTID 开启多线程并行复制的方案，即每个库有一个单独的(sql thread)

在 mysql5.6 里，无须再知道 binlog 和 POS 点，需要知道 master 的 IP、端口，账号密码即可，因为同步复制是自动的，mysql 通过内部机制 GTID 自动找点同步

MySQL 5.7的并行复制建立在group commit的基础上。MySQL5.7当中，组提交是默认开启的

MySQL 隔离级别

• MySQL - Repeatable Read
• Oracle - Read Committed
• SQL Server - Read Committed

MySQL XA事务

MySQL XA分为两类，内部XA与外部XA

内部XA用于同一server实例下跨多个Innodb引擎的事务，由大家熟悉的Binlog作为协调者(解决了 binlog 和 redo log的一致性问)；

外部XA用于跨多MySQL实例的分布式事务，需要应用层介入作为协调者(崩溃时的悬挂事务，全局提交还是回滚，需要由应用层决定，对应用层的实现要求较高)

在MySQL5.7.7之前，外部XA事务是有bug的。binlog不写prepare日志，只写commit日志。考虑下面的场景：所有的参与节点prepare完成，在进行xa commit前crash。crash recover如果选择commit此事务。由于binlog在prepare阶段未写，因此主库中看来，此分布式事务最终提交了，但是此事务的操作并未写到binlog中，因此也就未能成功复制到备库，从而导致主备库数据不一致的情况出现。