读写账号是否分开？
想起了前些天一个DBA朋友和我的聊天，是关于读写分离的场景中，读写模块是否使用同一个帐号的问题，感觉蛮有代表性的，把聊天记录分享出来，欢迎大家继续讨论
朋友A问我：“那你们读写分离是2套账号还是一套呢”
我说：“是两套”
--------------------------------------------------------------------
朋友A继续问：“我也是想做2套账号，但是开发觉得麻烦，说就一套账号体系，从库用readonly来控制”
我说：“mysql库不同步，可以直接这么跟他说啊”
--------------------------------------------------------------------
朋友A：“我们这里mysql库是同步的”
我说：“最好不要做mysql、information_schema、performe等非业务库同步”
--------------------------------------------------------------------
朋友A：“那主库挂了 你怎么切过去 ”
我：“主库的mysql库有备份啊，直接导入进去就可以了，而且就几十条grant语句，直接导入ok，搞定”
--------------------------------------------------------------------
朋友A：“
你还要做备份库的备份 还要做主库的mysql备份
这么麻烦
我简单粗暴 直接全部同步
这样切换的时候 可以快速切换
你那这样的话还有一个导入时间是不可写的
”
我说：“
mysql账号没有关系
mysql库不是业务库，所以这样做避免数据混乱
从库只允许读账号存在
在数据库账号上面，dba有全部的权限决定用哪个账号
做了读写分离的话，读写账号完全分开了。
开发人员那样反驳，看是哪个开发人员，如果是普通的开发人员，直接拒绝了；如果是开发架构师，就好好跟他说，这是dba要遵守的基本规则；DBA在公司地位超然，一般开发人员都会遵守DBA指定的基本数据库规范的。”
--------------------------------------------------------------------
朋友A：“^_^，其实我是打算最后实在说不通才这样来说这是我制定的规范”
我说：“晕倒，dba进公司的第一件事情就是熟悉数据库的环境和指定数据库规范，数据库规范最后说好像不太合适啊！
mysql库不同步的好处是：
1，主库少传了binlog，稍微提升了下性能
2，避免开发人员测试人员业务人员连接主库进行操作（这是最危险的，一个慢sql就能造成cpu尖刀啊）,一般比较慢的复杂查询都不允许放在主库上要放在从库上面。
3，开发人员如果一不小心把读账号的库ip域名写成主库的，你也无法检查出来。
4，开发人员一单能ssh了网段信息，就能直接连接主库从库进行操作了，太危险了。
......
All，读写账号一定要分开，mysql库不同步是最省事的方案。如果你要同步mysql库，记得要把读写账号分开。”
--------------------------------------------------------------------
题外话：
PS1：最重要的是，咱不能把希望全部放在开发人员100%遵守你的规则上，得有自己的限制措施，完全杜绝掉开发人员用读账号连接主库；
曾经遇到的情况：开发人员一个不小心读的时候连接了主库（dba不可能每次都100%检查出来应用的配置文件，貌似这是sa的责任？），而且里面有比较大的复杂查询sql，你看吧，在高峰期主库会被大量的慢sql卡住，然后cpu尖刀上来了，业务受影响了，然后DBA和这个开发人员这个月的绩效直接不合格，连带奖金也几乎没有了，遇到这种事情，你找谁说理去？别跟自己的奖金过不起啊，对吧？
PS2：经历的公司中，dba做了读写账号分开的，几乎没有人质疑的，如果个开发人员要反驳的话，dba得拍死他，。最后不行，dba就得说这是数据库的规范，只要dba在一天，就要遵守，当然dba也要不要因循守旧，需要与时俱进根据项目情况而定，制定出合适的规范出来。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
