[译] MySQL 8.0.27 中具有组复制的在线 DDL

原文地址：Online DDL With Group Replication in MySQL 8.0.27
原文作者： Marco Tusa
译者：摸鱼王者

2021 年 4 月，我写了一篇关于Online DDL 和 Group Replication的文章。当时我们正在处理 MySQL 8.0.23，与此同时我们还打开了一个错误报告，该报告没有对所提出的案例提供正确答案。

无论如何，在那篇文章中，我已经展示了在线 DDL 如何事实上锁定整个集群很长时间，即使使用设置为 EVENTUAL 的一致性级别也是如此。

本文旨在对 MySQL/Oracle 工程师所做工作给予公正的评价。

在 MySQL 8.0.23 中，我们有：

在 MySQL 8.0.27 中，我们有：

正如您从图像中看到的那样，我们有三个不同的阶段。第一阶段在版本 8.0.23 和版本 8.0.27 之间是相同的。

相反，第二阶段和第三阶段完全不同。在 MySQL 8.0.23 中，在 Primary 上应用 DDL 后，它会传播到其他节点，但也获得了 metalock，并且没有返回控制权。结果是不仅执行 DDL 的会话保持暂停，而且所有其他执行修改的会话也保持暂停。

只有在所有从节点上操作结束时，DDL 才会被推送到 Binlog 并传播以进行异步复制，锁定并重新启动操作。

相反，在 MySQL 8.0.27 中，一旦主节点上的操作结束，DDL 就会被推送到 binlog，传播到辅助节点并返回控制权。结果是主节点上的写操作没有任何中断，并且 DDL 同时分发到辅助节点和异步复制。

虽然仅适用于一致性级别 EVENTUAL，但这个改进仍然很棒。

让我们看看一些数字

为了测试操作，我使用了上述文章中之前测试中使用的相同方法。

Connection 1:
    ALTER TABLE windmills_test ADD INDEX idx_1 (`uuid`,`active`), ALGORITHM=INPLACE, LOCK=NONE;
    ALTER TABLE windmills_test drop INDEX idx_1, ALGORITHM=INPLACE;
    
Connection 2:
 while [ 1 = 1 ];do da=$(date +'%s.%3N');/opt/mysql_templates/mysql-8P/bin/mysql --defaults-file=./my.cnf -uroot -D windmills_large -e "insert into windmills_test  select null,uuid,millid,kwatts_s,date,location,active,time,strrecordtype from windmill7 limit 1;" -e "select count(*) from windmills_large.windmills_test;" > /dev/null;db=$(date +'%s.%3N'); echo "$(echo "($db - $da)"|bc)";sleep 1;done

Connection 3:
 while [ 1 = 1 ];do da=$(date +'%s.%3N');/opt/mysql_templates/mysql-8P/bin/mysql --defaults-file=./my.cnf -uroot -D windmills_large -e "insert into windmill8  select null,uuid,millid,kwatts_s,date,location,active,time,strrecordtype from windmill7 limit 1;" -e "select count(*) from windmills_large.windmills_test;" > /dev/null;db=$(date +'%s.%3N'); echo "$(echo "($db - $da)"|bc)";sleep 1;done

Connections 4-5:
     while [ 1 = 1 ];do echo "$(date +'%T.%3N')";/opt/mysql_templates/mysql-8P/bin/mysql --defaults-file=./my.cnf -uroot -D windmills_large -e "show full processlist;"|egrep -i -e "(windmills_test|windmills_large)"|grep -i -v localhost;sleep 1;done
复制

修改约 500 万行的表：

node1-DC1 (root@localhost) [windmills_large]>select count(*) from  windmills_test;
+----------+
| count(*) |
+----------+
|  5002909 |
+----------+
复制

下面的数字表示操作完成所花费的时间秒/毫秒。虽然我也在另一个节点上捕获 ALTER 的状态，但我没有在这里报告它，因为它不相关。

EVENTUAL (on the primary only)
-------------------
Node 1 same table:
.184
.186 <--- no locking during alter on the same node
.184
<snip>
.184
.217 <--- moment of commit
.186
.186
.186
.185
 
Node 1 another table :
.189
.198 <--- no locking during alter on the same node
.188
<snip>
.191
.211  <--- moment of commit
.194
复制

正如您所看到的，在提交时只有一个非常小的延迟，但还有其他影响。

现在，如果我们将此与我最近对 ​​Percona XtraDB Cluster (PXC) Non-Blocking operation 进行的测试进行比较，具有相同的行数和相同的类型表/数据：

PXC 在 DDL 执行期间保持不同节点之间的一致性，而具有组复制的 MySQL 8.0.27 推迟了辅助节点上的一致性，因此主节点和辅助节点在完全 DDL 完成之前不同步次要的。

结论

MySQL 8.0.27 附带了这个很好的修复，它显着降低了在线 DDL 操作对繁忙服务器的影响。但是我们仍然可以观察到在执行 DDL 时节点之间的数据存在明显的错位。

另一方面，带有 NBO 的 PXC 比较费时，但节点始终保持对齐。

最后，对于您来说，选择解决方案的因素在于一致性与运营影响。