she*_*ull 6 sql-server mirroring disaster-recovery amazon-ec2 sql-server-2014
设置
服务水平协议
我要满足的 SLA 条款在这一点上没有严格的限制(我知道很奇怪!):
网络瓶颈
看起来最大的瓶颈之一是大约 300mb 的网络管道,它似乎因需要同步镜像到另一个 EC2 实例而过载。我可以在同一个实例上维护更多的数据库,如果我删除镜像,可能会降低成本。
镜像或替代方法以获得具有合理可用性的性能
我正在寻找最佳价值,同时仍能提供合理的正常运行时间。由于我使用的是 SQL 标准,这意味着异步镜像不是一个选项(我们正在运行 sql 2014)。
当我评估了选项时,我很欣赏有关基本灾难恢复的另一种观点。镜像的开销似乎是一个很大的瓶颈,但如果我删除它,那么我会担心如何提供更好的可用性。理想情况下,我会异步运行镜像,但我们需要在 sql server 版本中向后移动,并且不确定这是否是最好的方法
始终在高可用性组上
由于此时复杂性和许可成本增加,因此不继续进行此操作。对未来的探索持开放态度,但目前希望避免企业许可成本。
小智 7
如果您所寻找的只是可用性,那么听起来您可能会从故障转移群集中受益。您可以在标准版上运行它们,如果您采用 N+1 路由,您可以有两个节点用于 HA,并在 DR 站点中有一个准备接管。您需要处理 DR 端的存储可用性问题,但这是另一套蠕虫病毒。
另一个选项可能是日志传送,因为您已经每分钟都在进行日志备份。您可以将日志发送到您的 HA/DR 服务器。
您可以在此处获取有关如何执行此操作以及对 AWS 的影响的更多信息:
在 AWS 云中实施 Microsoft Windows Server 故障转移集群和 SQL Server AlwaysOn 可用性组