高分请教 发布订阅灾难和恢复问题

Question

这个自动增加字段 不用于复制属性 都变成了 true (原来建表的时候是 false)， 
=======================这个？

Answer 1

1.用发布订阅做容灾不推荐. 发布订阅一般使用订阅端的数据用来做负载只读的.
2.容灾应该使用cluster/镜像/log shipping.
3.关于你的自增的问题，在建发布时应该有这个自增的设置，可以查下.

Answer 2

回答4楼的答复：1、镜像是实现不了频繁查询的，而利用快照查询，并不能符合我们的需求2、我的主要问题并不是单纯的容灾，容灾方面也有很多选择的，并不一定就是 镜像、cluster(光盘塔，磁带机等都可以实现容灾)，这些我也可以做，但从设备使用的角度来说，设备的闲置太浪费了。单从数据完整性来说，订阅发布也是可以实现容灾的(看我的提问的描述，可以做到容灾)，现在的问题只是快速恢复速度还不够理想3、这个问题，其实最关键的地方就是利用订阅数据库，进行快速进行灾难恢复如果做发布订阅，可以利用订阅数据库快速进行灾难恢复，完全接替原来的业务流程，那可比镜像、cluster 都要好，可以合理分配业务流程，充分利用其每台设备，我作这个测试，也只是研究一下，看看能否找到一个比较合理除了 镜像、cluster 以外的容灾、快速灾难恢复的方法，重点是看看能否利用订阅数据库，进行快速进行灾难恢复，注意：回答这个问题朋友们，请注意分析一下我的问题，另外，如果都是微软按照标准的推荐方案，照本宣科式的来回答，那就大可不必了，这些我都知道了，就算不知道，网上一查也是一大把的，

Answer 3

接9楼：我现在的做法就是利用发布订阅来实现，写操作在 A 服务器进行，查询操作在 B 进行，如果什么时候 B 撑不住了，可以随时加订阅服务器 C D E 等，利用负载均衡器进行查询分担，让 B C D E 加权平均承担查询操作，当做技术研究，大家来讨论一下，不知大家有什么另外的好建议

Answer 4

1.镜像的确实现不了频繁查询的，而利用快照查询，如果你查询需要实时，那么不符合你的要求，可以理解.
2.cluster是非常好的容灾方案，不管你是硬件损坏还是系统死掉，都能最快的转移sql server服务,cluster并不浪费资源，cluster可以做成AA模式或是N+1模式，基本不存在浪费. 
3.订阅数据库来不足亦实现容灾的方面：程序需要更改ip ,表必须都要有主键,源表不可以删除,不可以修改表名,不能同步添加索引/修改索引/删除索引,存储过程同步偶会有错误不能同步,另外，在网络情况不稳时，会导致延时.
4.我的容灾方式：
    首先，生产主要库全部cluster,或AA模式或N+1/N+2模式，查询全部走cluster主库存的订阅服务器,另外用log shipping进行异机房备份，再用cluster进行主cluster库的镜像.

Answer 5

正常流程：
A服务器是写操作，然后在F5上(负载均衡器)设置一个池子，假设池子下有10台服务器，这10台都是A的订阅端，可随时上下线.
在用户不变的情况下，该池子有10台服务器时，可能性能最稳定
如果现在用户变成原来的3倍，那么再加两个池子，然后分别配置10台服务器加入池子，以满足需求。

Answer 6

perfectaction ： 你好，我的 QQ： 4302899，希望能向你多多请教

Answer 7

CSDN 的加好友功能不行了，打开都是 404 Not Found 的

Answer 8

DBCC CHECKIDENT  ('XX表',reseed)