背景
MySQL通过read_only参数来设置DB只读，这样MySQL实例就可以作为slave角色，只应用binlog，不接受用户修改数据。这样就可以保护master-slave结构中的数据一致性，防止双写风险。
global read_only的实现方式
MySQL5.5版本通过三个步骤来设置read_only：
- 步骤1：获取global read lock，阻塞所有的写入请求
- 步骤2：flush opened table cache，阻塞所有的显示读写锁
- 步骤3：获取commit lock，阻塞commit写入binlog
- 步骤4：设置read_only=1
- 步骤5：释放global read lock和commit lock。
MySQL 5.5的版本，通过这5步完成设置read only的功能。
Bug描述
比如如下场景：
先执行session1，然后session2会一直被session1阻塞。
原因是：session1的显示锁，虽然与步骤1中的global read lock相容， 但session2因为session1一直持有读锁并保持t表opened而被阻塞。
但是，实际上，显示的读写锁产生的opened table并不影响read_only的功能，这里的flush tables也并非是必须的。
这也是我们的实际应用环境中，因主备切换而要在master实例上设置read_only的时候，经常被大查询所阻塞的原因。
修复方法
修复方法非常简单，只需要把步骤2删除即可，不影响read only的语义。
官方在MySQL 5.6.5中进行了修复：
If tables were locked by LOCK TABLES ... READ in another session, SET GLOBAL read_only = 1 failed to complete. (Bug #57612, Bug #11764747)
RDS功能增强
设置read_only阻塞用户写入，但只能阻塞普通用户的更新，RDS为了最大可能的保护数据一致性，增强了read_only功能，通过设置super read only，阻塞除了slave线程以为的所有用户的写入，包括super用户。
