Actualización y mejora para servidores de grupos de disponibilidad con un tiempo de inactividad mínimo y pérdida mínima de datos

Al actualizar o mejorar instancias de servidor de SQL Server 2012 a un paquete de servicio o una versión más reciente, puede reducir el tiempo de inactividad de un grupo de disponibilidad a solo una conmutación manual por error realizando una actualización o mejora secuenciales. Para actualizar versiones de SQL Server, se conoce como actualización gradual; para actualizar la versión actual de SQL Server con revisiones o Service Packs, se conoce como actualización gradual.

En este tema, la discusión se limita únicamente a las actualizaciones y mejoras de SQL Server. Para obtener actualizaciones o actualizaciones relacionadas con el sistema operativo en las que se ejecutan las instancias de SQL Server de alta disponibilidad, consulte Migración entre clústeres de grupos de disponibilidad AlwaysOn para actualizaciones del sistema operativo.

Procedimientos recomendados para actualizaciones graduales de los grupos de disponibilidad AlwaysOn

Se deben observar los siguientes procedimientos recomendados al realizar actualizaciones o actualizaciones del servidor para minimizar el tiempo de inactividad y la pérdida de datos para los grupos de disponibilidad:

• Antes de iniciar la actualización gradual,

  • Realizar un simulacro de conmutación por error manual en al menos una de las réplicas de confirmación sincrónica

  • Proteja los datos realizando una copia de seguridad de la base de datos completa en cada base de datos de disponibilidad

  • Ejecución de DBCC CHECKDB en cada base de datos de disponibilidad

• Actualice siempre primero los nodos de réplica secundaria remota, luego los nodos de réplica secundaria local y, por último, el nodo de réplica principal.

• Las copias de seguridad no se pueden realizar en una base de datos que esté en proceso de actualización. Antes de actualizar las réplicas secundarias, configure la preferencia de copia de seguridad automatizada para ejecutar copias de seguridad solo en la réplica primaria. Antes de actualizar la réplica principal, modifique esta configuración para ejecutar copias de seguridad solo en las réplicas secundarias.

• Para evitar que el grupo de disponibilidad realice conmutaciones por error no deseadas durante el proceso de actualización o actualización, quite la conmutación por error de disponibilidad de todas las réplicas de confirmación sincrónica antes de comenzar.

• No actualice el nodo de réplica principal antes de conmutar por error el grupo de disponibilidad a un nodo actualizado con una réplica secundaria en primer lugar. De lo contrario, las aplicaciones cliente pueden sufrir un tiempo de inactividad prolongado durante la actualización o actualización en la réplica principal.

• Conmutar automáticamente siempre el grupo de disponibilidad a un nodo de réplica secundaria con confirmación sincrónica. Si conmuta por error a una réplica secundaria de confirmación asincrónica, las bases de datos sufrirán pérdida de datos y el movimiento de datos se suspenderá automáticamente hasta que reanude manualmente el movimiento de datos.

• No actualice el nodo de réplica principal hasta que haya actualizado todos los nodos de réplica secundaria. Una réplica principal actualizada ya no puede enviar registros a ninguna réplica secundaria que aún no se haya actualizado a la misma versión. Cuando el movimiento de datos a una réplica secundaria se suspenda, no puede producirse la conmutación por error automática para dicha réplica y las bases de datos de disponibilidad son vulnerables ante la pérdida de datos.

• Antes de conmutar por error un grupo de disponibilidad, compruebe que el estado de sincronización del destino de conmutación por error es SYNCHRONIZED.

Proceso de actualización incremental

En la práctica, el proceso exacto dependerá de factores como la topología de implementación de los grupos de disponibilidad y el modo de confirmación de cada réplica. Pero en el escenario más sencillo, una actualización gradual o actualización es un proceso de varias fases que, en su forma más sencilla, implica los pasos siguientes:

1. Quitar la conmutación por error automática en todas las réplicas de confirmación sincrónica

2. Mejorar o actualizar todas las instancias de servidores remotos que ejecutan réplicas secundarias de confirmación asincrónica

3. Actualiza y mejora todas las instancias de servidores locales que no estén ejecutando actualmente la réplica principal.

4. Conmutación por error manual del grupo de disponibilidad a una réplica secundaria de confirmación sincrónica

5. Mejorar o actualizar la instancia del servidor que anteriormente alojaba la réplica principal

6. Configuración de asociados de conmutación automática por error según sea necesario

Si es necesario, puede realizar una conmutación por error manual adicional para devolver el grupo de disponibilidad a su configuración original.

Grupo de disponibilidad con una réplica secundaria remota

Si ha implementado un grupo de disponibilidad solo para la recuperación ante desastres, es posible que tenga que realizar una conmutación por error del grupo de disponibilidad a una réplica secundaria de confirmación asincrónica. Tal configuración se muestra en la ilustración siguiente:

En esta situación, debe realizar una conmutación por error del grupo de disponibilidad a la réplica secundaria de confirmación asincrónica durante la actualización gradual. Para evitar la pérdida de datos, cambie el modo de confirmación a confirmación sincrónica y espere a que la réplica secundaria se sincronice antes de conmutar por error el grupo de disponibilidad. Por lo tanto, el proceso de actualización gradual puede tener el siguiente aspecto:

1. Mejorar/actualizar el servidor remoto

2. Cambiar el modo de confirmación a confirmación sincrónica

3. Espere hasta que el estado de sincronización sea SINCRONIZADO

4. Conmutación por error del grupo de disponibilidad al sitio remoto

5. Actualizar o mejorar el servidor local (sitio primario)

6. Conmutación por error del grupo de disponibilidad al sitio primario

7. Cambiar el modo de confirmación a confirmación asincrónica

Dado que el modo de confirmación sincrónica no es una configuración recomendada para la sincronización de datos en un sitio remoto, las aplicaciones cliente pueden observar un aumento inmediato de la latencia de la base de datos después del cambio de configuración. Además, la realización de una conmutación por error hará que se descarten todos los mensajes de registro no reconocidos. La cantidad de mensajes de registro descartados puede ser bastante grande debido a la alta latencia de red entre los dos sitios, lo que provoca que los clientes experimenten un gran volumen de errores transaccionales. Puede minimizar el impacto en las aplicaciones cliente haciendo lo siguiente:

• Seleccionar cuidadosamente una ventana de mantenimiento durante el tráfico lento de cliente

• Al actualizar SQL Server en el sitio primario, cambie el modo de disponibilidad a confirmación asincrónica y luego vuelva a la confirmación sincrónica cuando esté listo para conmutar al sitio primario de nuevo.

Grupo de disponibilidad con nodos de instancia de clúster de conmutación por error

Si un grupo de disponibilidad contiene nodos de instancia de clúster de conmutación por error (FCI), debe actualizar primero los nodos inactivos antes de hacerlo con los nodos activos. En la ilustración siguiente se muestra un escenario de grupo de disponibilidad común con FCI para alta disponibilidad local y confirmación asincrónica entre las FCI para la recuperación ante desastres remota y la secuencia de actualización.

1. Mejorar/actualizar REMOTE2

2. Conmutación por error de FCI2 a REMOTE2

3. Mejorar/actualizar REMOTE1

4. Mejora/actualización PRIMARY2

5. Conmutación por error de FCI1 a PRIMARY2

6. Mejorar o actualizar PRIMARY1

Mejorar o actualizar instancias de SQL Server con múltiples grupos de disponibilidad

Si ejecuta varios grupos de disponibilidad con réplicas principales en nodos de servidor independientes (una configuración Active/Active), la ruta de actualización implica más pasos de conmutación por error para mantener la alta disponibilidad en el proceso. Supongamos que ejecuta tres grupos de disponibilidad en tres nodos de servidor, como se muestra en la tabla siguiente, y todas las réplicas secundarias se ejecutan en modo de confirmación sincrónica.

Puede ser adecuado en su situación para realizar una actualización o actualización gradual con equilibrio de carga en la siguiente secuencia:

1. Conmutación por error de AG2 a Node3 (para liberar Node2)

2. Mejorar o actualizar Node2

3. Conmutar AG1 a Node2 (para liberar Node1)

4. Mejorar/actualizar Node1

5. Conmutación por error de AG2 y AG3 a Node1 (para liberar Node3)

6. Actualizar o mejorar Node3

7. Cambio por error de AG3 a Nodo3

Esta secuencia de actualización tiene un tiempo de inactividad promedio de menos de dos conmutaciones por error por grupo de disponibilidad. La configuración resultante se muestra en la tabla siguiente.

En función de la implementación específica, la ruta de actualización o actualización puede variar, y el tiempo de inactividad que experimentan las aplicaciones cliente también puede variar.