这里主要说第三篇文章：解决非原子表切换问题，使其成为原子表切换
我们提供的解决方案仅基于两个连接（之前是三个，采用乐观方式）。这里我们假设 GH-OST 工具的连接将是 C10，C20；正常的应用程序连接是 C1..C9，C11..C19，C21..C29。
- 连接 C1..C9：正常 DML 操作 tbl 表
- 连接 C10：CREATE TABLE _tbl_del (id int primary key) COMMENT=’magic-be-here’
- 连接 C10：LOCK TABLES tbl WRITE, _tbl_del WRITE
- 连接 C11..C19：新进来的请求，或许有 DML 和 SELECT 都会因 LOCK 而等待
- 连接 C20：RENAME TABLE tbl TO _tbl_del, _tbl_gho TO tbl，会因 LOCK 而等待
- 连接 C21..C29：新进来的请求在 tbl 上发出查询，但由于 LOCK 和由于 RENAME 而在队列中等待而被阻塞
- 连接 C10：检查 C20 的 RENAME 是否正在执行（在 show processlist 中查找被阻止的 RENAME）
- 连接C10：DROP TABLE _tbl_del，什么也没有发生，tbl 仍然锁定，所有其他连接仍然被阻止
- 连接C10：UNLOCK TABLES
这里注意了！此时存在 C1..C9、C11..C19、C21..C29、C20 都在等待锁，无固定先后顺序。此时，RENAME 是第一个执行的，ghost 表被交换代替 tbl，然后 C1..C9、C11..C19、C21..C29 都可以运行在新的 tbl 表上。
注意点：
- 提前创建 _tbl_del 表是为了防止 tbl 表过早交换，导致数据丢失。
- 在同一个会话下执行了 write lock 后是可以进行 dml 操作和 drop 表的，这个 lock 本身的机制。
- 无论 DML 和 RENAME 谁先执行，被阻塞后 RENAME 总是优先于 DML 语句被执行，这个很重要。
在 gh-ost issue #82，有哥们提出一个问题就是怎么保证 RENAME 总是会优先于 DML 被执行，因为这个很关键。如果不能保证 RENAME 优先于 DML 被执行，就有数据丢失的风险。作者回答说他并没有保证，这个确实需要依赖 MySQL 内部行为，并且这种行为已经在 MySQL 中存在十年之久，并且与 MySQL 工程师讨论过这个问题。
整个 cut-over 方案的出现主要还是因为 MySQL 的局限性，你无法在同一个会话中 LOCK TABLES 后再去 RENAME TABLE（从 MySQL 8.0.13 版本开始支持同一个会话中 LOCK TABLES 后执行 RENAME TABLE），其他操作是可行的，比如 C10 还兼顾应用积压的 binlog 日志回访操作，这点是很重要的。
如果执行失败会发生什么？
- 如果 C10 的 CREATE 执行错误，GH-OST 不会继续往下执行了。
- 如果 C10 的 LOCK 语句出现错误，GH-OST 不会继续，表未锁定，应用程序继续正常运行。
- 如果 C10 在 C20 执行 RENAME 前挂掉了：
A. C10 锁被释放，查询 C1..C9，C11..C19 立即在 tbl 上运行。
B. C20 的 RENAME 立即失败，因为 _tbl_del 表存在。
C. 整个操作都失败了，但没有什么可怕的事情发生，有些查询被阻止了一段时间，我们需要重试。
- 如果 C10 在 C20 执行 RENAME 被阻塞时挂掉了：大部分与上述类似，锁释放，则 C20 执行 RENAME 失败（因为 _tbl_del 表存在），则所有查询恢复正常操作。
- 如果 C20 在 C10 DROP 表之前挂掉了，GH-OST 会捕获该错误并让 C10 按计划进行：DROP，UNLOCK。并不会有什么可怕的事情发生，一些查询被阻止了一段时间，我们需要重试。
- 如果 C20 在 C10 DROP 表之后但在解锁之前挂掉了，则与上面情况相同。C10 线程挂掉后自然锁就释放了，然后 C20 的 RENAME 会在 DML 之前操作。
- 如果 C10 和 C20 都挂掉了，没问题：LOCK 被清除，RENAME 锁被清除。 C1..C9，C11..C19，C21..C29 可以在 tbl 上自由运行。
无论发生什么事，在操作结束时，我们都会寻找 ghost 表。它还在，然后我们知道操作失败了。它不在，然后它被重命名为 tbl，并且该操作以原子方式工作。
关于失败的一个注意事项是清理 _tbl_del，也许只是让它存在下去，避免重新创建它；或者如果你喜欢，你可以删除它。
对应用程序的影响？
应用程序连接保证被阻止，直到交换 ghost 表或直到操作失败。在前者中，他们继续在新表上进行操作。在后者中，他们继续在原表上进行操作。
对复制的影响？
复制从库只能看到 RENAME，二进制日志中没有 LOCK。因此，复制会看到一个原子两表交换，没有表中断。
为什么需要锁定源表？
我们知道，RENAME 操作是 in-place 的，无需重建表并允许并发的 DML 操作。但因为 GH-OST 是通过异步方式应用二进制日志内容，有可能二进制日志有一些积压。因此，我们锁定源表，以确保我们完整应用完二进制日志相关的改动。
RENAME TABLES under LOCK TABLES
值得注意的是，从 MySQL 8.0.13 版本开始，支持了在 LOCK TABLES 之上的 RENAME TABLE 操作，专门为 GH-OST 做了一些设计支持。see: https://mysqlserverteam.com/the-mysql-8-0-13-maintenance-release-is-generally-available/
简单翻译过来就是，允许在 LOCK TABLES 之上执行 RENAME TABLE （WL#9826）操作，由 Dmitry Lenev 实现了原子 RENAME TABLE。这项特性已经请求 Shlomi Noach 在 GH-OST 工具的最后 cut-over 阶段使用。此类工具使用现有的旧表与用户并行构建一个新的，经过更改的表。当新的表数据是最新的时候，需要做两个表的原子交换。现在可使用 LOCK TABLES tbl WRITE 来实现（停止更新旧表），然后同一个会话执行 RENAME TABLE tbl TO _tbl_del, _tbl_gho TO tbl（交换时 _tbl_gho 是最新的）。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
# MySQL 8.0.18 mysql> LOCK TABLES t1 WRITE; Query OK, 0 rows affected (0.01 sec) mysql> select * from t1; +---+ | a | +---+ | 2 | +---+ 1 row in set (0.01 sec) mysql> update t1 set a=1; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> RENAME TABLE t1 to t11; Query OK, 0 rows affected (0.02 sec) mysql> select * from t1; ERROR 1100 (HY000): Table 't1' was not locked with LOCK TABLES mysql> unlock tables; Query OK, 0 rows affected (0.00 sec) mysql> select * from t1; ERROR 1146 (42S02): Table 'sbtest.t1' doesn't exist |
NOTE
关于表锁定看 “MySQL表锁定（Table Locking）”
