Les dejo una tabla comparativa para saber cual es la mejor opción de alta disponibilidad para SQL Server relacionado a Sharepoint
| Opción | Potencial Data Los (RPO) | Potential Recovery Time (RTO) | Auto-Failover | Copias adicionales de lectura | Limitaciones para Sharepoint |
| AlwaysOn Availability Groups – Sincrónico (dual-phase commit, sin pérdida de datos, no puede operar sobre WAN) | Nada | 5-7 segundos | Si | 0-2 | No se puede usar sobre redes con alta latencia/bajo bandwidth |
| AlwaysOn Availability Groups – Asincrónico (tolerante a latencias, opción para Cross-WAN, potencial perdida de datos) | Segundos | Minutos | No | 0-4 | No puede ser usado para las bases de datos: Central Admin Content, Farm Configuration, todas las bases de search, State Service,UPA Sync, y Usage |
| AlwaysOn Failover Cluster Instance (FCI) – Clustering tradicional de storage compartido | N/A. Por default FCI no provee protección de datos. Depende del sistema de storage | 30 segundos a varios minutos (dependiendo del disk failover) | Si | N/A | N/A |
| Database Mirroring – High safety (Sincrónico) | Nada | 5-10 segundos | Si | N/A | |
| Database Mirroring – High Performance (Asincrónico) | Segundos | Minutos | No | N/A | No hay datos disponibles oficiales, pero para 2010 era común no usar este método para UPA Sync, Usage, Search, Word Automation, BCS, Secure Store, Subscription Settings Database y Web Analitics (ahora dentro de las bases de search) |
| SQL Log Shipping | Minutos | Minutos | No | No durante un restore | N/A |
No hay comentarios:
Publicar un comentario