我们遇到了失败pt-osc
- 服务器磁盘空间不足。现在触发器被抛在了后面
SHOW TRIGGERS;
pt_osc_xxx_production_orders_ins
pt_osc_xxx_production_orders_upd
pt_osc_xxx_production_orders_del
这些怎样才能删除呢?
执行 aDROP TRIGGER
似乎会锁定表(它有 1.5 亿行),并且看起来需要几个小时。
我们不能pt-osc
再使用该表,因为它因Trigger already exists
错误而失败。
我们正在mysql Ver 8.0.32-24 for Linux on x86_64 (Percona Server (GPL), Release 24, Revision e5c6e9d2)
下面运行CentOS8
(如果这有什么区别的话)
我在上一份工作中不得不多次执行此操作,因为我们每周使用 pt-online-schema-change 数十次,偶尔会出现某些问题导致其失败。
您必须使用
DROP TRIGGER
. 操作本身几乎是瞬时的,并且无论表有多大都不再是瞬时的。但它必须先获取元数据锁,然后才能执行删除。所以理论上它可以等待很长时间才能获取该锁。针对该表的任何事务(即使是只执行只读查询的事务)都将禁止元数据锁。因此,如果有已对表进行查询的未完成事务,您
DROP TRIGGER
将等待。元数据锁的超时时间为lock_wait_timeout
,默认为 31536000 秒(1 年!)。最好的解决方案是对您的应用程序进行编码,这样您就不会出现持续数小时的长时间运行的事务。
您还可以终止保留其事务的线程。但是,如果您有许多线程需要长时间运行的事务,这可能会导致应用程序的操作出现一些问题。
正如罗兰多所说,您可能需要短暂关闭该应用程序。一旦应用程序关闭并且没有事务抑制操作
DROP TRIGGER
,它们将非常快。一旦您
DROP TRIGGER
使用了 pt-osc 创建的三个触发器,请记住还要删除它们将数据复制到其中的表。这是释放空间的唯一方法。下次,请注意 pt-osc 需要大量磁盘空间。不仅适用于复制表,还适用于二进制日志。
ALTER TABLE
不会向二进制日志添加很多内容,因为 DDL 始终只是一个基于语句的日志事件。但是 pt-osc 将数据复制步骤增量写入二进制日志,因此副本可以并行执行相同的数据复制操作。data_length
假设这至少会使二进制日志与表的大小成比例增长。您可以使用 释放更多空间
PURGE BINARY LOGS
,最多可容纳复制或恢复仍需要的日志空间。这有时会造成一种尴尬的情况,即数据库增长到我们无法再对最大的表执行任何模式更改的程度。
锁定功能是无法逃脱的。
您可以尝试重命名该表
这样,触发器将不会执行任何操作,但您仍然需要解决删除触发器的问题。
如果写入量太高,您必须暂停应用程序、删除表并删除触发器。