开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2800人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群260+ 9群)
在使用PolarDB for MySQL的过程中，我们遇到一个问题，PolarDB 8.02的小版本8.02.2.24 在添加索引的时候，会有部分情况无法添加索引，添加索引失败。具体表现是如下图：
在添加索引后会停滞，如果你等不及，直接KILL 添加索引的会话（实际上不KILL长时间也会索引添加失败），则BUG触发，稍后会返回如下报错信息，然后在怎么添加索引都不在报错而是直接无响应。
Fail to get table lock on replica;
You can set polar_support_mdl_sync_preemption = ON;但即使你打开了 polar_support_mdl_sync_preemption = ON; 也无济于事，还会在添加索引的时候报这个错误，同时也不是每次都会报错，而是在有大事务情况下，在读节点上很长时间无法运行完毕的情况下，会出现这个报错，而且只要出现这个报错，就会导致后续在添加索引的失败。解决方案为重启从节点。
这里提示：解决问题的关键是升级数据库版本，从8.02.2.24升级到 8.0.2.2.27，实际上8.0.2.2.24的BUG不少，这里列举一下。
1 优化文件系统在DDL过程中频繁创建和删除表文件时的性能稳定性。 2 新增高优先级DDL能力，保证DDL执行成功。
这两个部分是在8.02.2.25中修复的。
故障的原理是
1 在添加索引的情况下，基于POLARDB的原理，shared storage的架构，所以主从是一个存储，在这样的情况下，如果在主库将添加索引的SESSION KILL，会卡主，因为主库和从库之间有线程，从库不返回，主库就一直等导致的。
2 解决方案只能强行重启从节点，给主库一个信号，然后如果此时在建立索引则会建立索引立即成功。
在排查POLARDB FOR MySQL的数据库时，可以利用如下的命令
/force_node='p-2zexq8l8pzx8m6i'/ select * from information_schema.processlist where db = 'scm_suppl'; /force_node='p-2zec58b6uxm16a1'/ select * from information_schema.processlist where db = 'scm_suppl'; /force_node='p-2zeij811u776s5m'/ select * from information_schema.processlist where db = 'scm_supply';
在具体查询PolarDB的各个节点的信息，需要在语句前加入force_node 来具体查询各个节点的具体的状态信息。
查看DDL 工作的进度
SELECT THREAD_ID,EVENT_ID, EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED,(WORK_COMPLETED/WORK_ESTIMATED)*100 as PROGRESS FROM performance_schema.events_stages_current;如一些常见的问题
解决方案 1 及时进行从节点的事务的COMMIT ，如何发现没有及时的COMMIT 在从节点执行，并发现和解决
1 在主节点运行 /force_node='主节点名'/ show processlist; 如果在其中发现了如图中的位置写着，wait for syncing with replicas。 那么就证明的DDL 在被从库卡着
2 此时你需要去各个从库来对
select * from information_schema.innodb_log_mdl_slot where slot_state = "SLOT_ACQUIRING"来去找到从库那个语句在让主库的DDL等待的原因。
你可以开启 polar_slave_work_on_nonblock_mdl_mode = on
他的主要目的是为了解决从库中的长事务的问题，而不是长SQL的问题，长SQL这个解决不了，你还的自己在从库发现长时间运行的SQL并且杀死他，而不是依靠polar_slave_work_on_nonblock_mdl_mode 来解决问题。
同时在进行DDL操作可以通过POLARDB 中的如下语句来查看对应的操作的进度。
SELECT THREAD_ID,EVENT_ID, EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED,(WORK_COMPLETED/WORK_ESTIMATED)*100 as PROGRESS FROM performance_schema.events_stages_current;
+-----------+----------+------------------------------------------------------+----------------+----------------+----------+
| THREAD_ID | EVENT_ID | EVENT_NAME | WORK_COMPLETED | WORK_ESTIMATED | PROGRESS |
+-----------+----------+------------------------------------------------------+----------------+----------------+----------+
| 3057989 | 13 | stage/innodb/alter table (read PK and internal sort) | 56634 | 330135 | 17.1548 |
+-----------+----------+------------------------------------------------------+----------------+----------------+----------+
1 row in set (0.00 sec)然后通过如下的语句，将3057989放入可以查询到对应的语句
SELECT esc.THREAD_ID, esc.EVENT_NAME, esc.WORK_COMPLETED, esc.WORK_ESTIMATED, pl.INFO FROM performance_schema.events_stages_current esc LEFT JOIN performance_schema.threads th ON esc.thread_id = th.thread_id LEFT JOIN information_schema.PROCESSLIST pl ON th.PROCESSLIST_ID = pl.ID;
+-----------+------------------------------------------------------+----------------+----------------+-----------------------------------------------------------------------------------------+
| THREAD_ID | EVENT_NAME | WORK_COMPLETED | WORK_ESTIMATED | INFO |
+-----------+------------------------------------------------------+----------------+----------------+-----------------------------------------------------------------------------------------+
| 3057989 | stage/innodb/alter table (read PK and internal sort) | 77034 | 330519 | ALTER TABLE test.test ALGORITHM=INPLACE, ADD testA VARCHAR(20) NOT NULL DEFAULT 'testA' |
+-----------+------------------------------------------------------+----------------+----------------+-----------------------------------------------------------------------------------------+
1 row in set (0.00 sec)还可以通过获得 medtadata_locks 信息来查看具体performance_schema.threads 中持有的MDL线程
SELECT * FROM performance_schema.metadata_locks;
+-------------+--------------------+------------------+-------------+-----------------------+---------------------+---------------+-------------+------------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | COLUMN_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | SOURCE | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+------------------+-------------+-----------------------+---------------------+---------------+-------------+------------------------+-----------------+----------------+
| GLOBAL | NULL | NULL | NULL | 139949462878336 | INTENTION_EXCLUSIVE | STATEMENT | GRANTED | sql_base.cc:3103 | 3055785 | 1 |
| TABLE | test | test | NULL | 139931318980224 | SHARED_WRITE | TRANSACTION | GRANTED | sql_parse.cc:6479 | 3055785 | 1 |
| COMMIT | NULL | NULL | NULL | 139931318980480 | INTENTION_EXCLUSIVE | EXPLICIT | GRANTED | handler.cc:1669 | 3055785 | 1 |
| TABLE | performance_schema | metadata_locks | NULL | 139934227366144 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6479 | 3057612 | 1 |
| GLOBAL | NULL | NULL | NULL | 139934216849664 | INTENTION_EXCLUSIVE | STATEMENT | GRANTED | sql_base.cc:5519 | 3057989 | 13 |
| SCHEMA | test | NULL | NULL | 139934216849408 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | sql_base.cc:5506 | 3057989 | 13 |
| TABLE | test | test | NULL | 139934216848640 | SHARED_UPGRADABLE | TRANSACTION | GRANTED | sql_parse.cc:6479 | 3057989 | 13 |
| BACKUP LOCK | NULL | NULL | NULL | 139934216849280 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | sql_base.cc:5526 | 3057989 | 13 |
| TABLESPACE | NULL | test/test | NULL | 139934216848384 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | lock.cc:815 | 3057989 | 13 |
| TABLE | test | #sql-17d9_2ea89a | NULL | 139934216848896 | EXCLUSIVE | STATEMENT | GRANTED | sql_table.cc:15054 | 3057989 | 13 |
| GLOBAL | NULL | NULL | NULL | 139934216850176 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | dictionary_impl.cc:416 | 3057989 | 13 |
| TABLESPACE | NULL | test/test | NULL | 139934216849920 | EXCLUSIVE | TRANSACTION | GRANTED | dictionary_impl.cc:397 | 3057989 | 13 |
+-------------+--------------------+------------------+-------------+-----------------------+---------------------+---------------+-------------+------------------------+-----------------+----------------+
12 rows inset (0.00 sec)
SELECT * FROM performance_schema.threads WHERE THREAD_ID = "3057612"in performance_schema.metadata_locks table ";如果系统中存在Wait for syncing with replicas，PolarDB采用集群架构，因此在主节点上执行DDL操作时，需要等待所有只读节点释放对应的MDL锁。若您在使用show processlist时，观察到DDL操作处于Wait for syncing with replicas的状态，则说明在只读节点上持有了对应表的MDL锁。
在主库进行查找发现 Wait for syncing with replicas
/*force_node='pi-bp10k7631d6k3****'*/ SHOW PROCESSLIST;
+-----------+-----------------+-----------------------+--------------------+----------------+---------+--------------------------------+-------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----------+-----------------+-----------------------+--------------------+----------------+---------+--------------------------------+-------------------------------------------------------------+
| 98 | event_scheduler | localhost | NULL | Daemon | 1307512 | Waiting on empty queue | NULL |
| 109 | replicator | 11.111.XX.XX:62549 | NULL | Polar Log Dump | 1 | Reading log from innodb | NULL |
| 113 | replicator | 11.111.XX.XX:62560 | NULL | Polar Log Ack | 1 | Receiving from client | NULL |
| 133 | replicator | 10.13.64.70:42712 | NULL | Polar Log Dump | 1 | Reading log from innodb | NULL |
| 138 | replicator | 10.13.64.70:42723 | NULL | Polar Log Ack | 0 | Receiving from client | NULL
| 3064011 | root | 127.0.0.1:59703 | NULL | Sleep | 742 | | NULL |
| 3064013 | root | 127.0.0.1:59710 | NULL | Sleep | 21 | | NULL |
| 3064015 | root | 127.0.0.1:59713 | NULL | Sleep | 21 | | NULL |
| 3064018 | root | 127.0.0.1:59716 | NULL | Sleep | 1 | | NULL |
| 3067041 | zyg_root | 172.17.28.253:48594 | test | Query | 6 | Wait for syncing with replicas | alter table t1 add column d varchar(10),algorithm = inplace |
+-----------+-----------------+-----------------------+--------------------+----------------+---------+--------------------------------+-------------------------------------------------------------+
21 rows inset (0.00 sec)然后转到从节点，通过metadata_locks 语句找到对应的进程在通过 performance_schema.threads表来进一步查找对应的线程信息。最后决定是如何将这些阻塞DDL的操作仅先处理。
/*force_node='pi-bp186ko4o21wl****'*/ SELECT * FROM performance_schema.metadata_locks;
+-------------+--------------------+----------------+-------------+-----------------------+---------------------+---------------+-------------+--------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | COLUMN_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | SOURCE | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+----------------+-------------+-----------------------+---------------------+---------------+-------------+--------------------+-----------------+----------------+
| TABLE | test | t1 | NULL | 139394298895872 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:7688 | 3513381 | 1 |
| TABLE | test | t1 | NULL | 139394298602240 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:7688 | 3519277 | 1 |
| TABLE | test | t1 | NULL | 139917548369664 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:7688 | 3519279 | 1 |
| TABLE | test | t1 | NULL | 139394296661888 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:7688 | 3519278 | 1 |
| TABLE | test | t1 | NULL | 139394297595520 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:7688 | 3519276 | 1 |
| SCHEMA | test | NULL | NULL | 139464322084864 | INTENTION_EXCLUSIVE | EXPLICIT | GRANTED | sql_table.cc:17404 | 57 | 1 |
| TABLE | test | t1 | NULL | 139464322084992 | EXCLUSIVE | EXPLICIT | PENDING | sql_table.cc:17410 | 57 | 1 |
| TABLE | performance_schema | metadata_locks | NULL | 139394296038784 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:7688 | 3518506 | 1 |
+-------------+--------------------+----------------+-------------+-----------------------+---------------------+---------------+-------------+--------------------+-----------------+----------------+
8 rows inset (0.00 sec)
/*force_node='pi-bp186ko4o21wl****'*/SELECT * FROM performance_schema.threads WHERE THREAD_ID IN (3519278,3513381,3519279,3519276,3519277)\G
*************************** 1. row ***************************
THREAD_ID: 3513381
NAME: thread/sql/one_connection
TYPE: FOREGROUND
PROCESSLIST_ID: 538961413
PROCESSLIST_USER: zyg_root
PROCESSLIST_HOST: 172.17.28.253
PROCESSLIST_DB: test
PROCESSLIST_COMMAND: Connect
PROCESSLIST_TIME: 103
PROCESSLIST_STATE: User sleep
PROCESSLIST_INFO: select *,sleep(60) from t1
PARENT_THREAD_ID: NULL
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: TCP/IP
THREAD_OS_ID: 63826
RESOURCE_GROUP: NULL这里我简短的画一个处理问题的流程图
置顶
搞 PostgreSQL多才多艺的人--赵渝强 《PG数据库实战派》
阿里云DTS 产品，你真让我出离愤怒，3年了病还没治好？？？
专访唐建法-从MongoDB中国第一人到TapData掌门人的故事
天上的“PostgreSQL” 说 地上的 PostgreSQL 都是“小垃圾”宇宙的“PostgreSQL” 说 “地球上的PG” 都是“小垃圾”
云数据库核爆在内部，上云下云话题都是皮外伤！--2025云数据库专栏（二）
云原生 DB 技术将取代K8S为基础云数据库服务-- 2025年云数据库专栏（一）
临时工：数据库人生路，如何救赎自己 -- 答某个迷茫DBA的职业咨询
阿里云DTS 产品，你真让我出离愤怒，3年了病还没治好？？？
PostgreSQL 相关文章
“PostgreSQL” 高性能主从强一致读写分离，我行，你没戏！
PostgreSQL 添加索引导致崩溃，参数调整需谨慎--文档未必完全覆盖场景
PostgreSQL SQL优化用兵法，优化后提高 140倍速度
PostgreSQL 运维的难与“难” --上海PG大会主题记录
PostgreSQL 什么都能存，什么都能塞 --- 你能成熟一点吗？
全世界都在“搞” PostgreSQL ，从Oracle 得到一个“馊主意”开始
PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁
PostgreSQL “我怎么就连个数据库都不会建？” --- 你还真不会！
病毒攻击PostgreSQL暴力破解系统，防范加固系统方案（内附分析日志脚本）
PostgreSQL 远程管理越来越简单，6个自动化脚本开胃菜
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
PostgreSQL 分组查询可以不进行全表扫描吗？速度提高上千倍？
POSTGRESQL --Austindatabaes 历年文章整理
PostgreSQL 查询语句开发写不好是必然，不是PG的锅
PostgreSQL 字符集乌龙导致数据查询排序的问题，与 MySQL 稳定 "PG不稳定"
PostgreSQL Patroni 3.0 新功能规划 2023年 纽约PG 大会 （音译）
PostgreSQL 玩PG我们是认真的，vacuum 稳定性平台我们有了
PostgreSQL DBA硬扛 垃圾 “开发”，“架构师”，滥用PG 你们滚出 ！（附送定期清理连接脚本）
OceanBase 相关文章
OceanBase 6大学习法--OBCA视频学习总结第六章
OceanBase 6大学习法--OBCA视频学习总结第五章--索引与表设计
OceanBase 6大学习法--OBCA视频学习总结第五章--开发与库表设计
OceanBase 6大学习法--OBCA视频学习总结第四章 --数据库安装
OceanBase 6大学习法--OBCA视频学习总结第三章--数据库引擎
OceanBase 架构学习--OB上手视频学习总结第二章 （OBCA）
OceanBase 6大学习法--OB上手视频学习总结第一章
没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)
跟我学OceanBase4.0 --阅读白皮书 （4.0优化的核心点是什么）
跟我学OceanBase4.0 --阅读白皮书 （0.5-4.0的架构与之前架构特点）
跟我学OceanBase4.0 --阅读白皮书 （旧的概念害死人呀，更新知识和理念）
OceanBase 学习记录-- 建立MySQL租户,像用MySQL一样使用OB
PolarDB 相关文章
“PostgreSQL” 高性能主从强一致读写分离，我行，你没戏！
POLARDB 添加字段 “卡” 住---这锅Polar不背
PolarDB 版本差异分析--外人不知道的秘密（谁是绵羊，谁是怪兽）
PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤，来自杭州的Package（活动结束了）
PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火
MySQL相关文章
MySQL 的SQL引擎很差吗？由一个同学提出问题引出的实验
用MySql不是MySQL, 不用MySQL都是MySQL 横批 哼哼哈哈啊啊
MYSQL --Austindatabases 历年文章合集
MongoDB 相关文章
MongoDB 大俗大雅，上来问分片真三俗 -- 4 分什么分
MongoDB 大俗大雅，高端知识讲“庸俗” --3 奇葩数据更新方法
MongoDB 大俗大雅，高端的知识讲“通俗” -- 2 嵌套和引用
MongoDB 大俗大雅，高端的知识讲“低俗” -- 1 什么叫多模
MongoDB 合作考试报销活动 贴附属，MongoDB基础知识速通
MongoDB 使用网上妙招，直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
MongoDB 双机热备那篇文章是 “毒”
MongoDB 会丢数据吗？在次补刀MongoDB 双机热备
MONGODB ---- Austindatabases 历年文章合集
临时工访谈系列
没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
SQL SERVER 系列
SQL SERVER 如何实现UNDO REDO 和PostgreSQL 有近亲关系吗
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
