Conmutación por error del grupo de disponibilidad Always On en Linux

Se aplica a:SQL Server en Linux

Dentro del contexto de un grupo de disponibilidad, el rol principal y el rol secundario de las réplicas de disponibilidad suelen ser intercambiables en un proceso denominado conmutación por error. Hay tres formas de conmutación por error: conmutación por error automática (sin pérdida de datos), conmutación por error manual planeada (sin pérdida de datos) y conmutación por error manual forzada (con posible pérdida de datos), normalmente denominada conmutación por error forzada. Las conmutaciones por error automáticas o manuales planeadas conservan todos los datos. Un grupo de disponibilidad conmuta por error en el nivel de la réplica de disponibilidad. Es decir, un grupo de disponibilidad conmuta por error en una de sus réplicas secundarias (el destino de la conmutación por error actual).

Para obtener información general sobre la conmutación por error, vea Conmutación por error y modos de conmutación por error (grupos de disponibilidad Always On).

Conmutación por error manual

Use las herramientas de administración de clústeres para conmutar por error un grupo de disponibilidad administrado por un administrador de clústeres externo. Por ejemplo, si una solución usa Pacemaker para administrar un clúster de Linux, use pcs para realizar las conmutaciones por error manuales en Red Hat Enterprise Linux (RHEL) o Ubuntu. En SUSE Linux Enterprise Server (SLES), utilice crm.

Importante

En las operaciones normales, no realice la conmutación por error con Transact-SQL o herramientas de administración de SQL Server, como SSMS o PowerShell. Cuando CLUSTER_TYPE = EXTERNAL, el único valor aceptable para FAILOVER_MODE es EXTERNAL. Con esta configuración, el administrador de clústeres externo ejecuta todas las acciones de conmutación por error manuales o automáticas. Para obtener instrucciones sobre cómo forzar la conmutación por error con una posible pérdida de datos, vea Forzar la conmutación por error.

Pasos de conmutación por error manual

Para conmutar por error, la réplica secundaria que se convertirá en la réplica principal tiene que ser sincrónica. Si una réplica secundaria es asincrónica, cambie el modo de disponibilidad.

Conmute por error de forma manual en dos pasos.

Primero, conmute por error de forma manual al mover el recurso del grupo de disponibilidad desde el nodo del clúster propietario de los recursos a un nodo nuevo.

El clúster conmutará por error el recurso del grupo de disponibilidad y agregará una restricción de ubicación. Esta restricción configura el recurso para ejecutarse en el nuevo nodo. Quite esta restricción para conmutar por error correctamente en el futuro.
En segundo lugar, quite la restricción de ubicación.

Paso 1. Conmutación por error de forma manual al mover el recurso de un grupo de disponibilidad

Para la conmutación por error manual en un recurso de un AG denominado ag_cluster a un nodo de clúster denominado nodeName2, ejecute el comando adecuado para la distribución:

Ejemplo de RHEL/Ubuntu

sudo pcs resource move ag_cluster-master nodeName2 --master --lifetime=30S

Ejemplo de SLES

crm resource migrate ag_cluster nodeName2 --lifetime=30S

Cuando se usa la opción --lifetime, la restricción de ubicación creada para trasladar el recurso es temporal por naturaleza y es válida durante 30 segundos en el ejemplo anterior.

La restricción temporal no se borra automáticamente y puede aparecer en la lista de restricciones, pero como una restricción expirada. Las restricciones expiradas no afectan el comportamiento de conmutación por error del clúster de Pacemaker. Si no usa la opción --lifetime al mover el recurso, debe quitar una restricción de ubicación que se agregue automáticamente como se indica en la siguiente sección.

Paso 2. Quitar la restricción de ubicación

Durante una conmutación por error manual, el comando pcs de move o el comando crm de migrate agregan una restricción de ubicación para el recurso que se aplicará en el nuevo nodo de destino. Para ver la nueva restricción, ejecute el comando siguiente después de mover manualmente el recurso:

Ejemplo de RHEL/Ubuntu
```
sudo pcs constraint list --full
```
Ejemplo de SLES
```
crm config show
```
Este es un ejemplo de la restricción creada debido a una conmutación por error manual.

Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

Nota

El nombre del recurso de grupo de disponibilidad en los clústeres de Pacemaker en Red Hat Enterprise Linux 8.x y Ubuntu 18.04 puede ser similar a ag_cluster-clon, ya que la nomenclatura relacionada con los recursos ha evolucionado para usar clon promovible.
Ejemplo de RHEL/Ubuntu

En el comando siguiente, cli-prefer-ag_cluster-master es el identificador de la restricción que se debe quitar. sudo pcs constraint list --full devuelve este identificador.
```
sudo pcs resource clear ag_cluster-master
```
O
```
sudo pcs constraint remove cli-prefer-ag_cluster-master
```
Como alternativa, puede realizar tanto el movimiento como el borrado de restricciones generadas automáticamente en una sola línea, como se indica a continuación. En el ejemplo siguiente se usa la terminología clone según Red Hat Enterprise Linux 8.x.
```
sudo pcs resource move ag_cluster-clone --master nodeName2 && sleep 30 && sudo pcs resource clear ag_cluster-clone
```
Ejemplo de SLES

En el comando siguiente, cli-prefer-ms-ag_cluster es el identificador de la restricción. crm config show devuelve este identificador.
```
crm configure
delete cli-prefer-ms-ag_cluster
commit
```

Nota

La conmutación automática por error no agrega una restricción de ubicación, por lo que no es necesaria ninguna limpieza.

Para obtener más información:

Red Hat: Managing Cluster Resources (Red Hat: Administración de recursos de clúster)
Pacemaker: movimiento manual de recursos
Guía de administración de SLES: Administración de recursos de clúster

Forzar la conmutación por error

La conmutación por error forzada se usa estrictamente para la recuperación ante desastres. En este caso, no se puede realizar una conmutación por error con las herramientas de administración de clústeres porque el centro de datos principal está fuera de servicio. Si se fuerza la conmutación por error a una réplica secundaria no sincronizada, es posible que se pierdan datos. Ejecute solo una conmutación por error forzada si necesita restaurar el servicio al grupo de disponibilidad de inmediato y asume el riesgo de que se pierdan datos.

Si no puede usar las herramientas de administración de clústeres para interactuar con el clúster (por ejemplo, si el clúster no responde debido a un evento de desastre en el centro de datos principal), puede que tenga que forzar la conmutación por error para omitir el administrador de clústeres externo. Este procedimiento no se recomienda para operaciones normales, ya que existe el riesgo de que se produzca una pérdida de datos. Úselo cuando las herramientas de administración de clústeres no puedan ejecutar la acción de conmutación por error. De manera funcional, este procedimiento es similar a ejecutar una conmutación por error manual forzada en un grupo de disponibilidad en Windows.

Este proceso para forzar la conmutación por error es específico de SQL Server en Linux.

Compruebe que el clúster ya no administra el recurso de grupo de disponibilidad.
- Establezca el recurso como el modo no administrado en el nodo del clúster de destino. Este comando indica al agente del recurso que detenga la supervisión y administración de recursos. Por ejemplo:
```
sudo pcs resource unmanage <resourceName>
```
- Si se produce un error al intentar establecer el modo no administrado en el recurso, elimine el recurso. Por ejemplo:
```
sudo pcs resource delete <resourceName>
```
  Nota
  
  Al eliminar un recurso, también se eliminan todas las restricciones asociadas.
En la instancia de SQL Server que hospeda la réplica secundaria, establezca la variable de contexto de sesión external_cluster.
```
EXECUTE sp_set_session_context
    @key = N'external_cluster',
    @value = N'yes';
```
Conmute por error el grupo de disponibilidad con Transact-SQL. En el ejemplo siguiente, reemplace <MyAg> por el nombre del grupo de disponibilidad. Conéctese a la instancia de SQL Server que hospeda la réplica secundaria de destino y ejecute el comando siguiente:
```
ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;
```
Después de una conmutación por error forzada, devuelva el grupo de disponibilidad a un estado correcto; para hacerlo, reinicie las funciones de administración y supervisión de recursos del clúster, o bien vuelva a crear el recurso de grupo de disponibilidad. Vea Tareas esenciales después de una conmutación por error forzada.
Reinicie las funciones de administración y supervisión de recursos del clúster:

Para reiniciar las funciones de administración y supervisión de recursos del clúster, ejecute el comando siguiente:
```
sudo pcs resource manage <resourceName>
sudo pcs resource cleanup <resourceName>
```
Si ha eliminado recursos del clúster, vuelva a crearlo. Para recrear el recurso del clúster, siga las instrucciones de Crear un recurso de grupo de disponibilidad.

Importante

No siga el procedimiento anterior para la obtención de detalles de recuperación ante desastres, ya que existe el riesgo de que se produzca una pérdida de datos. En su lugar, cambie la réplica asincrónica a sincrónica y siga las instrucciones para una conmutación por error manual normal.

Supervisión del nivel de la base de datos y desencadenamiento de una conmutación por error

En el caso de CLUSTER_TYPE=EXTERNAL, la semántica para desencadenar una conmutación por error es distinta en comparación con WSFC. Cuando del grupo de disponibilidad se encuentra en una instancia de SQL Server en WSFC, la transición fuera de un estado de ONLINE para la base de datos hace que el estado del grupo de disponibilidad notifique un error. Como respuesta, el administrador de clústeres desencadena una acción de conmutación por error. En Linux, la instancia de SQL Server no se puede comunicar con el clúster. La supervisión del estado de la base de datos se realiza desde fuera hacia dentro. Si el usuario ha activado la supervisión de conmutación por error de nivel de base de datos y la conmutación por error (al establecer la opción DB_FAILOVER=ON al crear el grupo de disponibilidad), el clúster comprueba si el estado de la base de datos es ONLINE cada vez que ejecuta una acción de supervisión. El clúster consulta el estado en sys.databases. Para cualquier estado distinto de ONLINE, desencadena automáticamente una conmutación por error (si se cumplen las condiciones de la conmutación automática por error). El tiempo real de la conmutación por error depende de la frecuencia de la acción de supervisión y del estado de la base de datos que se actualiza en sys.databases.

La conmutación automática por error necesita como mínimo una réplica sincrónica.

Contribuya a la documentación de SQL

¿Sabía que puede editar el contenido de SQL usted mismo? Si lo hace, no solo contribuirá a mejorar la documentación, sino que también se le reconocerá como colaborador de la página.

Para obtener más información, consulte Editar documentación de Microsoft Learn.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2025-07-14