我们在2000年使用我们自己的日志传送进行故障转移.对于2008年,我们需要决定使用我们自己的日志传送,内置日志传送或复制.
我们的服务器上有很多数据库(400);有些小,有些大.
数据库服务器故障应该很少,我们可以接受15-30分钟的数据丢失.更重要的是快速启动第二台DB服务器.
根据上述标准,我最好使用日志传送还是复制？
解决方法
这与DBA的技能无关.这完全取决于HA对业务或应用程序的要求 – 这些是驱动因素,而不是DBA可以应对的因素.如果需要更复杂的解决方案,那么还需要获得与之处理的DBA.由于DBA的技能限制您的HA解决方案是荒谬的.
数据库镜像也不是快速检测和快速故障转移 – 它完全取决于故障是什么,镜像伙伴超时是什么,SEND和REDO队列是什么.故障转移可能需要一段时间才能完成镜像决定成为主体的故障.我帮助了许多客户实现镜像(当我在Microsoft拥有数据库镜像和其他存储引擎时),以及自2007年离开以来.
在我们向您提出建议之前,您需要回答一些基本问题：
>您想要整个数据库的冗余副本还是只有部分？
>您是否希望能够使用冗余副本？对于写入还是仅用于读取？
>数据库的事务日志生成率是多少？
>两个站点之间的网络带宽是多少？
对于您来说,日志传送可能是最简单的,无论是在设置,监控还是只能在数据丢失限制内快速提供冗余副本.使用日志传送,您可以选择将冗余副本联机,而无需通过接受数据丢失来完成还原排队等待还原的所有事务日志备份.
您还可以使用中间层路由技术实现简单的故障转移,甚至可以使用0/100配置或切换到100/0的Windows NLB这样简单的故障转移.我还看到客户使用DNS切换来在服务器名称无法更改时实现故障转移.
通过复制,您必须处理从发布db事务日志中获取的事务之间的不可预测的延迟,命中分发数据库,然后由分发代理推送/拉到订阅数据库.复制也会让自己扭曲起来,并且很容易弄清楚并重置 – 日志传送很简单.
鉴于您一直在使用自己的日志传送,我猜测日志生成速率和网络带宽不是问题 – 我坚持使用日志传送并回避复制.甚至不要考虑数据库镜像,因为它不适用于您的卷.
希望这会有所帮助 – 当我向HA内部的DBA教授HA时,这真的是两天的讨论 – 归结为5分钟回答这个问题.随意在评论中跟进更具体的问题.
