Nis*_*R05 3 sql-server scalability availability-groups
目前我们有一个大小为 4 TB 的数据库。我们希望将其放入 2014 年可用性组以扩展读取。该数据库中的数据发生了很大变化。
我有以下问题:
尼斯莫,
重要的不是数据库的大小(无意开玩笑),而是与可用基础设施相结合的变化率。例如,一个相对静态的数据库在 5400 RPM SATA 驱动器的过载交换机上的 1Gb 连接上可能表现不佳。
如果变化率(也就是查看您的日志刷新字节)小于 200 MB/秒左右,并且您拥有非常快的存储(或大量前端缓存)和极低的延迟网络,那么我会说您会美好的。
现在让我们回顾一下您的问题:
1.这个大小是否适合可用性组(我们希望有 2-3 个副本)?
重要的不是规模,而是基础设施。所以,是的,那很好。
2.如果网络死掉1小时,我们能多快同步副本?
一只空着的燕子飞得有多快?说真的,我们没有办法告诉你。您需要考虑日志生成率 + 延迟 + 阻塞重做 + 同步/异步状态。
更好的问题是,“我的主服务器上是否有足够的空间让我的事务日志不截断一个小时?”
3.在使用可用性组之前,你们有什么我应该考虑的吗?
如果您担心这些,我会考虑认真研究 SQL 2016。并行重做(即将推出)、更好的网络利用率、分布式 AG、直接播种等。
如果您打算使用 2014,那么最好的建议是确保服务器硬件和基础架构符合您将要创建的更改速度。此外,当您对对象执行 DDL 时要注意,因为它可能会对重做造成潜在的问题。
如果您担心副本及时赶上,只需从 AG 中删除副本,将事务日志还原到它们,然后将它们带回 AG。请记住,当 AG 在“后面”时,您的主服务器将无法让日志文件重用任何 VLF,因为它只能标记为重用直到该 LSN。
| 归档时间: |
|
| 查看次数: |
257 次 |
| 最近记录: |