除了群集之外,客户端还希望在发生SAN故障时为发布者数据库提供弹性.他们拥有第二个较小的SAN(从性能角度来看)(不幸的是,从DR的角度来看)同一个数据中心.这将有一个连接sql2005 32位企业版的32位服务器.客户端意识到,如果发生SAN事件,他们将不再具有群集或复制功能,并且性能水平较低.
我在争论是否使用日志传送或数据库镜像来提供数据库DR.我们使用Quest LiteSpeed进行备份,并可以使用它来发送压缩的事务日志备份.
解决方法
您还需要考虑客户希望为发布者提供哪些数据丢失要求,以及您是否已经在进行日志备份(我猜你是).
可以将数据库镜像设置为零数据丢失(只要镜像保持同步),但是根据事务日志生成速率和可用的网络带宽,等待事务记录在事务可以之前在镜像上加强对委托人的提交可能会减慢工作量.取决于您正在做什么样的交易(长或短)是否会对整体响应时间产生显着影响.
使用日志传送,它只是备份 – 复制 – 恢复,重复.因此,如果您已经在进行日志备份,那么您根本不会影响性能.如果您不习惯进行日志备份,则可能会遇到事务日志大小管理问题.
请注意,镜像需要完整的恢复模型,因此它可能会影响您的数据库维护,特别是如果您习惯使用BULK_LOGGED恢复模型.根据可用的网络带宽,这也可能导致日志大小管理问题.
两者都需要网络带宽,但方式不同.每次复制日志备份时,日志传送都会突发,数据库镜像更持久,显然取决于日志生成速率.我需要知道更多,以便能够判断任何一个所需的额外带宽量是否会影响复制流中的数据移动,从而影响那里的延迟.
使用日志传送时,您必须在发生故障时手动故障转移到日志传送辅助服务器,并且可能会丢失数据(自上次日志备份以来从主服务器复制的所有数据).然后你需要再次启动repl.
使用数据库镜像,您可以将其设置为自动进行故障转移,并且您可以专门将repl代理作业中的故障转移伙伴设置为在新主体(也是新发布者)上自动启动.棘手的是确保在本地群集故障转移有机会发生之前不会发生数据库镜像故障转移.您可以通过更改镜像伙伴超时值来执行此操作.我在http://www.sqlskills.com/BLOGS/PAUL/post/Search-Engine-QA-3-Database-mirroring-failover-types-and-partner-timeouts.aspx写了这篇博文.
我为Microsoft写了一份白皮书,描述了如何一起使用镜像和tranasactional复制：见http://www.sqlskills.com/BLOGS/PAUL/post/SQL-Server2008-New-whitepaper-on-combining-transactional-replication-and-database-mirroring.aspx.
在所有其他条件相同的情况下,我建议使用数据库镜像,因为它易于管理,可以减少数据流量.你可能还有一些我不知道的其他要求会阻止这种情况.
希望这可以帮助.
原文地址：https://www.jb51.cc/mssql/80700.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
