Ideas, releases, practical guides, and perspectives from the people building with MySQL.
在 MySQL-8.0 之前，DDL 是不能做到 Crash Safe 的。主要的问题有 3 个：
Server 层的 Metadata 和 InnoDB 的 Metadata/数据不一致。
Server 层的 Metadata 记录在文件中，例如表结构信息保存在 frm
文件中；InnoDB 中也有一份 Metadata 存储在表中。Crash 可能导致 Server 层的 Metadata
和 InnoDB 中的 Metadata、甚至表中的数据不一致。比如 Server 层存在表的
frm 文件，认为表存在，但是 InnoDB 的 ibd
数据文件已经不存在了，InnoDB 认为表不存在。
Binlog 和数据不一致。
比如 Crash 重启后，表已经存在了，但是 CREATE TABLE 却没有记录到
Binlog 中。
MySQL-8.0 为了实现 Atomic …
[获取更多]本文也有英文版：English version。
MySQL官方从MySQL-5.6开始优化复制延迟问题，最先实现了 Schema 级别的 Binlog
并发应用。然而这个并发能力并不能解决日常的复制延迟。然后官方在
MySQL-5.7上实现了基于提交顺序的并发回放策略(Commit Order),
这种策略依赖主上的事务并发执行数量。主上并发执行的事务非常多的情况下，从库上回放的速度才会快。如果主上并发少，从库上回放速度仍然会变慢，产生复制延迟。因此官方又在
MySQL-5.7 上又实现了行级的并发策略(Writeset),
这种并发策略无论主上并发事务的多少，都能在从库上快速的并发回放。
我们很早以前就在线上全面使用了基于 writeset 的复制策略，writeset …
[获取更多]
MySQL 在执行 Online DDL 重建表的时候，可能会碰到 Duplicate
Entry 错误，从而导致 DDL 中途失败。失败信息如下所示：
1
2
mysql> alter table tt add c3 int, algorithm=inplace;
ERROR 1062 (23000): Duplicate entry '1' for key 'tt.uk_c2'
这是一个非常知名的问题，自从 MySQL-5.6 引入了 Online DDL 之后就一直存在。相关的Bug包括:
BUG#76895[5]最早报告了这个问题。BUG#76895 上提到的是 Duplicate
PRIMARY …
Not long ago, we were invited to the Percona Live 2016 meeting in
the USA to share our recent findings on MySQL replication, which
is InnoDB-based phy
【mysql】 【innodb】 【replication】 【I/O】 【Developer_blog】 【DDL】 点击查看原文>
导读:本文是测试online DDL对表的二级索引的增删的影响。测试目的有以下几点：
(1):online DDL和旧机制的DDL 在二级索引变更方面的效率如何
(2):onlineDDL是否支持DML，查询并发
导读:
本文是onlineDDL 对Innodb全文索引的变更测试的。MySQL5.6手册中有这样的解释: (除非用户提供FTS_DOC_ID列，否则创建第一个全文索引的过程包含表的复制。
导读：本文主要详细测试online DDL中的删除，添加主键操作。关于MySQL5.6在线DDL的全文信息，请参照：MySQL5.6版本InnoDB存储引擎在线DDL变更的官方信息中文翻译版，
文章地址：http://www.mysqlops.com/2013/03/26/mysql56-innodb-ddl.html
测试目的主要有以下几点：