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