Los Grupos de Disponibilidad AlwaysOn de SQL Server es una tecnología que fue lanzada inicialmente por Microsoft con SQL Server 2012.
El concepto principal, es que tengas tus datos disponibles en más de un sitio al mismo tiempo. Para ello, tienes grupos de bases de datos que tienen réplicas primarias y réplicas secundarias. Estas réplicas están alojadas en diferentes servidores y pueden sincronizarse en dos modos:
- Modo de disponibilidad asíncrono-commit
- Modo de disponibilidad asíncrono-commit
- Aumentar el rendimiento de la base de datos de SQL Server con In-Memory OLTP
- Consejos esenciales de administración de SQL Server
- Fundamentos de SQL Server – Base de datos SQL para principiantes
- Consejos esenciales de desarrollo de SQL Server para desarrolladores de SQL
- La filosofía y los fundamentos de la programación informática
- .NET para principiantes – Windows Forms con C#
- Introducción a la ciencia de datos y al aprendizaje automático de SQL Server
- Introducción a Azure SQL Database para principiantes
- SQL Server 2019: Novedades – Características nuevas y mejoradas
- Entity Framework: Primeros pasos – Guía completa para principiantes
- Cómo importar y exportar datos en bases de datos de SQL Server
- Aprende a instalar y empezar a usar SQL Server en 30 minutos
- Guía sobre cómo empezar y monetizar un blog de éxito
- Consejos esenciales de administración de SQL Server
- Cómo parchear una instancia independiente de SQL Server
- El servicio de navegador de SQL Server y el puerto UDP 1434
- La configuración del número máximo de conexiones concurrentes en SQL Server
- Lista de las 10 principales tareas diarias de un DBA de SQL Server
- No hay ningún clúster de conmutación por error de SQL Server disponible para unirse
- Encriptación de una copia de seguridad de la base de datos de SQL Server
- …más
Grupos de disponibilidad modo asíncrono-commit
Con el modo asíncrono-commit, la réplica secundaria nunca está totalmente sincronizada con la réplica primaria. La razón de esto, es que debido a la naturaleza asíncrona de commit, cualquier base de datos secundaria podría quedarse atrás en cualquier momento. Esto significa que si está utilizando el modo de commit asíncrono y realiza una conmutación por error forzada (esta es la única forma de conmutación por error que puede realizar), entonces es muy posible que se produzca una pérdida de datos.
Modo de commit síncrono de los grupos de disponibilidad
Con el modo de commit síncrono, después de unirse a un grupo de disponibilidad, una base de datos secundaria se pone al día con la base de datos correspondiente y entra en el estado «sincronizado». El requisito previo para esto, por supuesto, es que la sincronización de datos (y por lo tanto, el movimiento de datos) continúe y no se detenga por ninguna razón (es decir, problemas de red, problemas de espacio en disco, etc.). Si la sincronización de datos continúa y se utiliza el modo de compromiso síncrono, entonces cada transacción que se compromete en una base de datos primaria dada también se ha comprometido en la base de datos secundaria.
Ejemplo de una arquitectura de grupos de disponibilidad Always On de SQL Server
El siguiente diagrama ilustra una configuración de una réplica de 2 nodos con grupos de disponibilidad Always On de SQL Server.
Discutiremos más los conceptos ilustrados en el diagrama de arquitectura anterior.
Discusión y Recomendaciones
Una cosa que es muy importante tener en cuenta, es que, basado en la arquitectura de Grupos de Disponibilidad, cada réplica, tiene su propio almacenamiento dedicado, esto después de todo, la forma de tener sus datos disponibles en múltiples sitios. Esto se basa en el principio de redundancia.
Tengo un geo-cluster con 2 nodos en 2 sitios diferentes, el sitio A y el sitio B. En cada sitio, tengo una réplica de mis grupos de disponibilidad de SQL Server. En el ejemplo anterior, en el Sitio A, tengo mis réplicas primarias, y en el Sitio B, mis réplicas secundarias. Como he comentado antes, mis réplicas pueden estar sincronizadas con commit síncrono o asíncrono.
Otra cosa importante a tener en cuenta, es que si realmente quieres conseguir una alta disponibilidad, necesitas un tercer sitio para que sirva como Testigo de Archivos Compartidos. Es por eso que en mi diagrama anterior, he incluido un tercer sitio, que es el sitio C, que proporciona un recurso compartido de archivos con el fin de ser utilizado como el Testigo de archivos para el geo-clúster.
¿Cómo conectar mi aplicación a una base de datos en un grupo de disponibilidad de SQL Server?
Si usted es nuevo en los grupos de disponibilidad de SQL Server usted podría preguntarse: «¿cómo se conectará mi aplicación a la base de datos?». Pues bien, no te preocupes porque esto es muy sencillo. Cada Grupo de Disponibilidad tiene su propio listener (un par de nombre de red virtual e IP virtual) que debe configurar durante la creación de un Grupo de Disponibilidad. En la configuración de la cadena de conexión para su aplicación, tendrá que introducir el nombre/IP del oyente y su número de puerto para que su aplicación pueda «ver» la(s) base(s) de datos en el grupo de disponibilidad específico. Después de eso, la arquitectura de alta disponibilidad subyacente será transparente para su aplicación.
Una nota importante aquí, se le aconseja utilizar Grupos de Disponibilidad para su solución sólo si su solución/aplicación soporta esta arquitectura de alta disponibilidad.
¿Qué sucede durante una conmutación por error?
Una conmutación por error en una arquitectura de Grupos de Disponibilidad de SQL Server es diferente (y más rápida) que una conmutación por error en una Instancia de Clúster de Conmutación por Error (FCI) de SQL Server tradicional. La principal diferencia es que cada vez que se produce una conmutación por error para un grupo de disponibilidad de SQL Server, lo único que cambia de propietario es el oyente. Esto significa que después de la conmutación por error, el oyente del grupo de disponibilidad específico estará apuntando a la otra réplica porque esa réplica acaba de convertirse en la nueva réplica primaria y la otra (que hasta ese momento era la primaria) se convirtió en la réplica secundaria. Todo esto, por supuesto, supone que ambas réplicas están sincronizadas.
Observaciones finales
Como se puede ver en la discusión y el ejemplo anteriores, todo lo anterior hace de SQL Server Always On una solución de alta disponibilidad muy potente que debe ser definitivamente considerada cuando se diseñan centros de datos activo-activo.
Por último, tenga en cuenta que lo anterior era un ejemplo simplificado, con el fin de ayudarle a entender los fundamentos mismos de los grupos de disponibilidad de SQL Server y cómo contribuyen a tener instancias de SQL Server de alta disponibilidad.
Con la oferta de grupos de disponibilidad de SQL Server Always On, puede construir sofisticadas soluciones de bases de datos de alta disponibilidad con más de 2 sitios y, por lo tanto, tener una infraestructura verdaderamente de alta disponibilidad.
En próximos artículos, trataremos más temas sobre SQL Server Always On Availability Groups, así que ¡esté atento!
Fortalezca sus habilidades de administración de SQL Server – ¡inscríbase en nuestro curso online!
Si realmente quieres aprender técnicas sofisticadas de administración de SQL Server, entonces deberías ver nuestro curso online bajo demanda titulado «Consejos esenciales de administración de SQL Server» (descuento especial por tiempo limitado incluido en el enlace).
A través del curso, aprenderás consejos esenciales de administración de SQL Server sobre el mantenimiento, la seguridad, el rendimiento, la integración, el manejo de errores y mucho más. Muchas demostraciones en vivo y recursos descargables incluidos!
¡Inscríbete ahora con descuento!
Cursos online destacados:
Artículos de administración de SQL Server relacionados:
Valora este artículo: 
(2 votos, media: 5.00 sobre 5)
Cargando…
