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

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

视频中给出了几种方法

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

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

实验：http://coosh.blog.51cto.com/6334375/1738364

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

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

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

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

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

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

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

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

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

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

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