很多人可能还记得，Percona在Percona Server for MySQL 5.6.21 中添加了super_read_only功能，基于 WebScaleSQL 所做的工作。
从 5.7.8 开始，此功能最终进入 MySQL 的 Community 分支，并且在这两种情况下的工作方式相同。虽然这已经是旧闻了，但在过去的一年里，我从客户那里收到了一些关于MySQL 中super_read_only用法以及它在实践中如何工作的询问。
虽然super_read_only的用法并不复杂，但有一个小警告有时会导致对其使用的一些混淆。因此，我认为写一篇简短的博客文章更多地解释此功能并扩展它与read_only 的交互方式可能是个好主意.
什么是 super_read_only？
对于那些不熟悉的人，什么是super_read_only？
在引入之前，MySQL 可以选择将节点设置为read_only，以防止除具有SUPER权限的所有人之外的所有人写入数据库。最常用于副本节点，这是防止某人在不经过主节点并让复制线程处理分发的情况下无意中手动更新副本的一个很好的步骤。当然，这可能会由于重复的键、丢失的行或由于数据集之间的不一致而导致的其他问题而中断复制。
使用super_read_only更进一步，其行为与read_only相同，同时也阻止具有SUPER权限的人写入数据库。虽然乍一看这似乎是替代更好和更严格的用户权限的权宜之计，但事实证明它在生产环境中非常方便，可以为副本节点添加进一步的保护层，并有助于防止人为错误导致意外停机。
一只手洗另一只手
我之前引用的查询是随其使用的，并没有意识到（或忘记）read_only和super_read_only是链接的。要记住的关键是启用super_read_only 也 意味着常规read_only。
设置read_only = OFF也会设置 super_read_only = OFF。
设置super_read_only = ON也会设置 read_only = ON。
这些变量中任何一个的所有其他更改对另一个没有影响。
这种行为似乎合乎逻辑，因为在禁用read_only 时您可能还想禁用super_read_only，反之亦然，在启用super_read_only 时您可能还想启用read_only。虽然记录了这种链接行为，但当您对其中一个进行更改时，MySQL 本身没有警告或注释提醒您这一点。这可能会导致一些头疼，因为对一个变量的更改会同步更改另一个变量。
最后的考虑
对于适用于super_read_only 的read_only，还有一些其他含义需要牢记——例如，无论如何设置这些变量，都允许对临时表进行操作。任何OPTIMIZE TABLE或ANALYZE TABLE操作也是允许的，因为read_only / super_read_only的目的是防止对表结构的更改，而不是对表元数据（如索引统计）的更改。最后，如果有需要将副本提升为主要状态的实例，则需要手动禁用这些设置（或通过自动化编写脚本）。
