标签：主从备份
根据老男孩老师的视频讲到，主从复制的风险是具备写权限的用户连接到从库上改数据。
视频中给出了几种方法
1）在从库上回收用户的写权限（UPDATE/DELETE/INSERT）
这种方法必须保证主库上对应的用户不会发生改动；如果真的发生了改动，该用户的授权又会同步到从库上去，导致回收失效。
2）在从库上增加一个只读用户，并告知开发人员，如果连接从库则使用该只读用户。
这种方法必须与开发人员密切配合，风险也是蛮大的，一旦开发不依规则硬要用写权限的用户去连接从库（有时候连开发也是无心之失），那就糟了。所以这种方法一定要三思。
3）同步时忽略mysql数据库，自行在从库添加只读用户（与主库的帐密保持一致）。
这种做法相对安全，只是万一主库失效，从库接手后又没有帐号信息，很难进行恢复；另外如果主库上的帐号较多，也是有很大的风险。如果单从数据备份的角度来，并且帐号不多的情况下（又或者主库上的mysql数据库做了备份）的情况下，是可行的。
4）从库在启动前加read-only参数
这种做法算是比较接近完美，但并非没有风险；首先，read-only不能限制住具备全部权限的用户；其次，当主库失效时，从库必须去掉read-only；
我个人觉得第四种更为值得推荐，因为在主库失效时，
首先，帐号密码授权不会丢失；
其次，这4种方法，除了第二种外，其他都需要人工干预（半自动），而干预的程度来说，第四种最低；
而第二种方法来说，尽管开发可以做成自行切换来达到自动替换主从库，但站在运维的角度来说，这是两难；站在管理层的角度来说，这种方法是四种方法中最有可能保持服务持久；总而言之，第二种方法是一把双刃剑。
标签：主从备份
原文地址：http://coosh.blog.51cto.com/6334375/1738281
