alwayson 只读副本权限控制问题解决思路征集

山寨DBA 2015-09-02 06:12:02

环境：Windows server 2012 + sqlserver 2012 R2
功能：alwayson 实现读写分离 + 自动故障转移
问题（目前测试环境我已经折腾出来了，但是反复测试过程正发现如下坑爹的问题）：即，可读副本权限控制问题。因为alwayson是针对于库级别的高可用性组，而且只读副本是“只读”的，导致alwayson搭好之后无法添加账号到只读副本上的各个库，所以故障切换之后主库（故障转移之前是只读辅库）没有原来主库的登录名等权限。
我这边目前的方案有两个，但是都非常不理想：
方案1：
主库写库正常read/write权限，并且准备一份主库写库程序访问的账号create的脚本，随时在故障转移的时候执行（工作量较大，而且非常不灵活，人工干预过多，容易出错），同时赋予程序访问只读辅库的账号sysadmin权限（这个凶险程度可想而知）。
方案2：
辅助库+主库账号全部授予sysadmin权限（凶险程度更上一层，但是相对而言管理简单，而且切换非常灵活，几乎不需要人工干预）

诸位大神对alwayson有深层研究的，有什么好的建议，请不吝赐教。

灰常感谢。。。

...全文

360 15 打赏收藏转发到动态举报

写回复

用AI写文章

15 条回复

切换为时间正序

请发表友善的回复…

发表回复

山寨DBA 2015-09-11

打赏
举报

引用 14 楼 Tiger_Zhao 的回复:

要做前台应用啊。原来你们光有数据库就开展业务了，奇葩，围观……

刚起步的创业型小公司，业务推进型，难免的呀。。。虽然我也很头疼。

Tiger_Zhao 2015-09-11

打赏
举报

要做前台应用啊。
原来你们光有数据库就开展业务了，奇葩，围观……

山寨DBA 2015-09-11

打赏
举报

引用 12 楼 Tiger_Zhao 的回复:

做读写分离说明你预测报表压力会比较大，这部分要按实际情况进行调优的，要从整个系统层面进行设计，不能光靠数据库。

确实如兄所言，因为我们公司刚起步，目前虽然数据量不大，但是目前公司正在逐步壮大，业务量每月都超新高，数据量也是。而目前我们是几乎没有什么报表的，公司高层每天开会需要的诸多资料都是每天手动执行SQL给他们的excel ，然而越来越多，人扛不住这个工作量了，所以决议做个读写分离+报表专用服务器的。系统层面我却不咋懂。

山寨DBA 2015-09-10

打赏
举报

引用 10 楼 Tiger_Zhao 的回复:

我的意思是读写分离照旧，再加一台同步递交的服务器实现自动故障转移。 alwayson可以这样配置不？

我理解兄台的意思了，可是目前我们的数据库是一个单机的，没有做读写分离，也没有高可用。兄台说的方法，我想出了一个，也测试了，可以行得通，方法如下： alwayson主副本负担业务写，辅助副本通过配置只读路由设置为业务读库，然后我又做了个replication，专门提供非业务的报表之类的查询用。架构这样设计是可行的，已经测试了（由于购买的服务器还没到，我在虚拟机上测试的）。但是还没上生产，具体压力测试也还没测，所以到时候压力情况还不清楚。

Tiger_Zhao 2015-09-10

打赏
举报

我的意思是读写分离照旧，再加一台同步递交的服务器实现自动故障转移。
alwayson可以这样配置不？

山寨DBA 2015-09-10

打赏
举报

引用 8 楼 Tiger_Zhao 的回复:

说实话，还没应用过AlwayOn呢不过纯理论：自动故障转移是通过集群的同步提交自动实现的，并不需要专门做读写分离啊。 sql server 2012 alwayson功能部署所以你原始的需求是什么？多功能就需要更多的服务器吧。

我们目前需求就是要在不借助第三方软件的前提下，弄sqlserver的读写分离+高可用。只有replication和alwayson呢。。。选择了alwayson，用配置只读路由来实现辅助库只读，目前多遍各种测试下来，发现其实alwayson还不错，有点强，唯独缺点就是非实例级别，应用程序登录权限不好控制