我们公司的一位架构师在两个地理位置偏远的数据中心设计了一个基于64位sql2005标准版的物理(4四核,32GB RAM)服见证服务器(1个虚拟cpu).存储是两个数据中心的企业级SAN.
前端应用程序面向Web,具有混合读/写用法.
作为一名DBA(在设计阶段没有咨询过),我担心这种配置的设计最大限度地减少冗余作为主要标准,并且它不能作为真实世界的解决方案 – 网络延迟和虚拟化的性能盒子会导致不可接受的响应时间吗？如果调用故障转移,性能甚至更差.
有没有人有类似设置的经验？
解决方法
虽然网络带宽在很大程度上发挥作用,但要考虑的绝对首要因素是主体上的事务日志生成率是多少？
如果应用程序和您的维护不生成任何事务日志,那么网络带宽实际上是无关紧要的.如果它确实生成了日志,那么网络带宽必须能够处理生成的日志量.
要回答您的实际问题,如果主体上没有大的OLTP工作负载,那么您的h / w配置可能会起作用(网络问题除外).如果有,并且您有4×4处理器核心生成事务日志,那么无论您的网络是否能够应对日志流量,您的镜像服务器都可能无法跟上重播日志.在标准版上,有一个线程处理镜像上的日志REDO – 所以你的REDO队列在重载下会变得非常大.
REDO队列是镜像上已强化但尚未在镜像数据库中重放的日志量 – 它越大,镜像数据库作为故障转移时的主体上线之前的时间就越长.这在标准版中尤其麻烦,因为您没有并行重做和快速恢复(数据库在REDO之后和UNDO之前联机)可用的功能.
当然,在从主体到镜像的故障转移之后,镜像无法为主体服务器提供相同的工作负载 – 所以你会在那里,但可能运行速度慢很多.
希望这可以帮助.
