MySQL从库过滤所有DELETE操作的几种方案

在 MySQL 从库 上，有没有一种 全局配置方式，可以直接禁止或过滤所有 DELETE（乃至 UPDATE）操作？

答案是 —— 有几种可选方案，但要看你希望的“层级”和“严格程度”。
本文我会详细说明 生产可用的几种方法（推荐从强到弱排列）。

方案一：使用 read_only 或 super_read_only（最推荐）

配置方式：

在从库 my.cnf（或 mysqld.cnf）中添加：

[mysqld]
read_only=ON
super_read_only=ON

然后重启 MySQL：

systemctl restart mysqld

工作原理：

• read_only=ON：普通用户不能对从库进行写入（INSERT, UPDATE, DELETE, CREATE, DROP等）；
• super_read_only=ON：即使是拥有 SUPER 权限的用户，也无法执行写入（除非关闭此选项）。

主从复制线程（replication SQL thread）不受此限制——

也就是说：

从库仍然可以接收主库的 binlog 更新（包括删除），
但任何手动 DELETE 都会被拒绝。

效果

mysql> delete from user where id=5;
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

主库发来的删除日志仍能正常同步执行，不受影响。

推荐用途

• 用于 防止 DBA 或程序误操作；
• 适合所有生产从库；
• 只要从库不承担写操作，就应该启用。

方案二：使用 binlog_ignore_db（仅对复制过滤）

在 主库的 my.cnf 中设置（而不是从库）：

[mysqld]
binlog_ignore_db=your_database_name

这样主库的 DELETE/UPDATE/INSERT 对该数据库不会写入 binlog，因此从库自然不会同步这些修改。

但这属于主库层面的过滤，无法阻止直接在从库上执行删除。

方案三：在从库使用 sql_log_bin=0（会话级控制）

你之前提到的：

SET sql_log_bin=0;

虽然能避免写入 binlog，但并不能阻止 DELETE 执行。
换句话说：

• DELETE 仍然在从库执行；
• 只是不会再同步给其他级联从库（如果存在）。

这种方法适合临时会话，不适合全局防护。

方案四：触发器（不推荐，但可用）

你可以为每个表添加触发器，阻止删除操作：

CREATE TRIGGER prevent_delete
BEFORE DELETE ON your_table
FOR EACH ROW
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'DELETE not allowed on slave';

但：

• 要对每个表单独添加；
• 表结构变动时需重新创建；
• 不适合大型系统。

方案五：修改从库权限（限制账号）

如果你的应用程序在主从库上使用相同账号，可以在从库上收紧权限：

REVOKE DELETE, UPDATE, INSERT ON *.* FROM 'appuser'@'%';

这样即使程序误连从库，也无法执行写操作。

总结对比

推荐安全配置组合

在从库 /etc/my.cnf 中加上：

[mysqld]
read_only=ON
super_read_only=ON
skip_slave_start=0

这样可以：

• 防止任何手动删除；
• 仍然允许主库复制更新；
• 从库安全可靠。

到此这篇关于MySQL从库过滤所有DELETE操作的几种方案的文章就介绍到这了,更多相关MySQL过滤所有DELETE操作内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论