推荐的镜像替代方案?

she*_*ull 6 sql-server mirroring disaster-recovery amazon-ec2 sql-server-2014

设置

  • 2 个 Amazon EC2 SQL 2014 服务器位于不同的可用区域。
  • 同步镜像
  • S3 用于在夜间归档完整备份和日志
  • 现在为简单起见,每晚完整压缩备份
  • 每 15 分钟记录一次 Tran 日志(如果可以减少运行时间,会做得更多)
  • Ola Hallengren 备份在主服务器和镜像服务器上运行

服务水平协议

我要满足的 SLA 条款在这一点上没有严格的限制(我知道很奇怪!):

  • “Opps Deleted Something”恢复会很不错,但我现在对此没有硬性交付要求。我现在每 15 分钟做一次日志备份。
  • 高可用性:不完全需要,如果需要,停机一小时是可以接受的
  • 时间点恢复:由于事务日志备份每 15 分钟一次,我能够提供一次,但是现在 2 小时是可以接受的。

网络瓶颈

看起来最大的瓶颈之一是大约 300mb 的网络管道,它似乎因需要同步镜像到另一个 EC2 实例而过载。我可以在同一个实例上维护更多的数据库,如果我删除镜像,可能会降低成本。

镜像或替代方法以获得具有合理可用性的性能

我正在寻找最佳价值,同时仍能提供合理的正常运行时间。由于我使用的是 SQL 标准,这意味着异步镜像不是一个选项(我们正在运行 sql 2014)。

当我评估了选项时,我很欣赏有关基本灾难恢复的另一种观点。镜像的开销似乎是一个很大的瓶颈,但如果我删除它,那么我会担心如何提供更好的可用性。理想情况下,我会异步运行镜像,但我们需要在 sql server 版本中向后移动,并且不确定这是否是最好的方法

始终在高可用性组上

由于此时复杂性和许可成本增加,因此不继续进行此操作。对未来的探索持开放态度,但目前希望避免企业许可成本。

小智 7

如果您所寻找的只是可用性,那么听起来您可能会从故障转移群集中受益。您可以在标准版上运行它们,如果您采用 N+1 路由,您可以有两个节点用于 HA,并在 DR 站点中有一个准备接管。您需要处理 DR 端的存储可用性问题,但这是另一套蠕虫病毒。

另一个选项可能是日志传送,因为您已经每分钟都在进行日志备份。您可以将日志发送到您的 HA/DR 服务器。

您可以在此处获取有关如何执行此操作以及对 AWS 的影响的更多信息:

在 AWS 云中实施 Microsoft Windows Server 故障转移集群和 SQL Server AlwaysOn 可用性组