mysql 主主 风险_Linux学习笔记：MySQL主从复制的风险与防范

根据老男孩老师的视频讲到，主从复制的风险是具备写权限的用户连接到从库上改数据。

视频中给出了几种方法

1)在从库上回收用户的写权限(UPDATE/DELETE/INSERT)

这种方法必须保证主库上对应的用户不会发生改动；如果真的发生了改动，该用户的授权又会同步到从库上去，导致回收失效。

2)在从库上增加一个只读用户，并告知开发人员，如果连接从库则使用该只读用户。

这种方法必须与开发人员密切配合，风险也是蛮大的，一旦开发不依规则硬要用写权限的用户去连接从库(有时候连开发也是无心之失)，那就糟了。所以这种方法一定要三思。

3)同步时忽略mysql数据库，自行在从库添加只读用户(与主库的帐密保持一致)。

这种做法相对安全，只是万一主库失效，从库接手后又没有帐号信息，很难进行恢复；另外如果主库上的帐号较多，也是有很大的风险。如果单从数据备份的角度来，并且帐号不多的情况下(又或者主库上的mysql数据库做了备份)的情况下，是可行的。

后记：视频中使用binlog-ignore-db参数，老师的实验是有问题的，尽管看上去像是实现了，但实际上只是延迟了。经查手册和自己验证的结果来看，该参数是有限制的。假设binlog-ignore-db=mysql，只有当用户use mysql;然后对当前库进行操作才会被忽略。而如果在没有use库的情况下对任何库的增删改，还是会被写进binlog里并同步到从库。

4)从库在启动前加read-only参数

这种做法算是比较接近完美，但并非没有风险；首先，read-only不能限制住具备全部权限的用户；其次，当主库失效时，从库必须去掉read-only；

我个人觉得第四种更为值得推荐，因为在主库失效时，

首先，帐号密码授权不会丢失；

其次，这4种方法，除了第二种外，其他都需要人工干预(半自动)，而干预的程度来说，第四种最低；

而第二种方法来说，尽管开发可以做成自行切换来达到自动替换主从库，但站在运维的角度来说，这是两难；站在管理层的角度来说，这种方法是四种方法中最有可能保持服务持久；总而言之，第二种方法是一把双刃剑。