1、现象说明

DB Crash，signal 6...hit a bug...

具体表现：

a、实例内核版本8.0.30

b、实例crash sql都是ALTER TABLE `xxx`.`xxxxxx` ADD COLUMN .....

c、介入排查时，没有crash了，`xxx`.`xxxxxx` 表重建过

2、原因分析

初步判断为Mysql bug，该bug在8.0.31及以上版本被修复（Bug #34488482、Bug #33937504）

Bug参考：bugs.mysql.com/bug.php?id=107941

a、8.0.29开始online ddl instant算法存在设计缺陷；

b、8.0.12后，instant成为alter table add column新增列的默认算法；

以上两点导致缺陷导致DDL时数据库数据块损坏、DB Crash、及后续的备份失败。

备份失败问题详见，Percona官方说明：docs.percona.com/percona-xtrabackup/8.0/error-message-instant.html

BUG的内核分析，可以参考：

gitee.com/mirrors/mysql-server/commit/f0992c66fe26ae09d6e503645ac01eaa45de4e5d

3、问题影响

a、触发bug时，数据库crash重启；业务连接中断；

b、触发bug后，使用该表可能会不断crash，需要停表的相关业务进行重建表；

c、触发bug后，实例备份失败；

实例异常的影响时长：重启拉起的时长

这个表的影响时长：重启+重建表的时长（取决于表大小和磁盘性能）

建议DDL前对相关表进行备份。

4、相关解决方案

a、故障前规避BUG，为DDL指定算法

ALTER TABLE xx add .... , ALGORITHM=INPLACE, LOCK=NONE;

避免使用ALGORITHM=INSTANT、或者ALGORITHM=DEFAULT、或省略这个语句；

b、故障时重建表修复，将表的instant字段转为非instant字段

alter table xx engine = InnoDB;

c、其他实例的排查方法

SQL：select name from information_schema.innodb_tables where total_row_versions > 0 or instant_cols > 0;

重建表修复：alter table xx1.x1 engine=innodb;

如下图：