Alta disponibilidad y protección de datos para las configuraciones de grupo de disponibilidad

Se aplica a:SQL Server: Linux

En este artículo se presentan las configuraciones de implementación admitidas para los grupos de disponibilidad Always On de SQL Server en servidores Linux. Un grupo de disponibilidad admite alta disponibilidad y protección de datos. La detección automática de errores, la conmutación automática por error y la reconexión transparente después de la conmutación por error proporcionan alta disponibilidad. Las réplicas sincronizadas proporcionan la protección de datos.

En un clúster de conmutación por error de Windows Server (WSFC), una configuración común para la alta disponibilidad usa dos réplicas sincrónicas y un tercer servidor o recurso compartido de archivos para proporcionar el cuórum. El testigo de recurso compartido de archivos valida la configuración del grupo de disponibilidad: estado de sincronización y el rol de la réplica, por ejemplo. Esta configuración garantiza que la réplica secundaria elegida como destino de la conmutación por error tenga los cambios de configuración del grupo de disponibilidad y los datos más recientes.

El WSFC sincroniza los metadatos de configuración para el arbitraje de conmutación por error entre las réplicas del grupo de disponibilidad y el testigo del recurso compartido de archivos. Cuando un grupo de disponibilidad no está en un WSFC, las instancias de SQL Server almacenan los metadatos de configuración en la base de datos master.

Por ejemplo, un grupo de disponibilidad en un clúster de Linux tiene CLUSTER_TYPE = EXTERNAL. No hay ningún WSFC para arbitrar la conmutación por error. En este caso, las instancias de SQL Server administran y mantienen los metadatos de configuración. Dado que no hay ningún servidor testigo en este clúster, se requiere una tercera instancia de SQL Server para almacenar los metadatos de estado de configuración. Las tres instancias de SQL Server juntas proporcionan almacenamiento de metadatos distribuido para el clúster.

El administrador de clústeres puede consultar las instancias de SQL Server del grupo de disponibilidad y coordinar la conmutación por error para mantener una alta disponibilidad. En un clúster de Linux, Pacemaker es el administrador de clústeres.

SQL Server 2017 CU 1 permite una alta disponibilidad para un grupo de disponibilidad con CLUSTER_TYPE = EXTERNAL para dos réplicas sincrónicas más una réplica de solo configuración. La réplica de solo configuración se puede hospedar en cualquier edición de SQL Server 2017 CU1 o posterior, incluida la edición SQL Server Express. La réplica de solo configuración mantiene información de configuración sobre el grupo de disponibilidad en la base de datos master, pero no contiene las bases de datos de usuario del grupo de disponibilidad.

Cómo afecta la configuración a la configuración de recursos predeterminada

SQL Server 2017 presenta la configuración del recurso de clúster REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Esta configuración garantiza que el número especificado de réplicas secundarias escriba los datos de la transacción que se registrarán antes de que la réplica principal confirme cada transacción. Cuando se usa un administrador de clústeres externo, esta configuración afecta a la alta disponibilidad y a la protección de datos. El valor predeterminado de la configuración depende de la arquitectura en el momento en que se crea el recurso de clúster. Al instalar el agente de recursos de SQL Server (mssql-server-ha) y crear un recurso de clúster para el grupo de disponibilidad, el administrador de clústeres detecta la configuración del grupo de disponibilidad y establece REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT en consecuencia.

Si es compatible con la configuración, el parámetro de agente de recurso REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT se establece en el valor que proporciona alta disponibilidad y protección de datos. Para obtener más información, consulte Información sobre el agente de recursos de SQL Server para Pacemaker.

En las siguientes secciones se explica el comportamiento predeterminado para el recurso de clúster.

Elija un diseño de grupo de disponibilidad para satisfacer los requisitos empresariales específicos de alta disponibilidad, protección de datos y escalado de lectura.

Las siguientes configuraciones describen los patrones de diseño del grupo de disponibilidad y las capacidades de cada patrón. Estos patrones de diseño se aplican a los grupos de disponibilidad con CLUSTER_TYPE = EXTERNAL para soluciones de alta disponibilidad.

• Tres réplicas sincrónicas
• Dos réplicas sincrónicas
• Dos réplicas sincrónicas y una réplica de solo configuración

Tres réplicas sincrónicas

Esta configuración consta de tres réplicas sincrónicas. De forma predeterminada, proporciona alta disponibilidad y protección de datos. También puede proporcionar escalado de lectura.

Un grupo de disponibilidad con tres réplicas sincrónicas puede proporcionar protección de datos, alta disponibilidad y escalado de lectura. En la tabla siguiente se describe la disponibilidad de este comportamiento.

Comportamiento de la disponibilidad	Escalado de lectura	Alta disponibilidad y protección de datos	Protección de los datos
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0	1 1	2
Interrupción principal	Conmutación por error automática. Es posible que haya pérdida de datos. La nueva réplica principal es de L/E.	Conmutación por error automática. La nueva réplica principal es de L/E.	Conmutación por error automática. La nueva réplica principal no estará disponible para las transacciones de actualización del usuario hasta que la réplica principal anterior se recupere y se una al grupo de disponibilidad como réplica secundaria.
Interrupción de réplica secundaria	La réplica principal es de L/E.	La réplica principal es de L/E.	La réplica principal no estará disponible para las transacciones de actualización del usuario hasta que no se recupere y se una al grupo de disponibilidad la réplica secundaria con errores.

¹ valor predeterminado

Dos réplicas sincrónicas

Esta configuración habilita la protección de datos. Al igual que las demás configuraciones de grupo de disponibilidad, puede habilitar el escalado de lectura. La configuración de dos réplicas sincrónicas no proporciona alta disponibilidad automática. Una configuración de dos réplicas solo es aplicable a SQL Server 2017 RTM y ya no se admite con versiones posteriores (CU1 y posteriores) de SQL Server 2017.

Un grupo de disponibilidad con dos réplicas sincrónicas proporciona protección de datos y escalado de lectura. En la tabla siguiente se describe la disponibilidad de este comportamiento.

Comportamiento de la disponibilidad	Escalado de lectura	Protección de los datos
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0 1	1
Interrupción principal	Conmutación por error automática. Es posible que haya pérdida de datos. La nueva réplica principal es de L/E.	Conmutación por error automática. La nueva réplica principal no estará disponible para las transacciones de actualización del usuario hasta que la réplica principal anterior se recupere y se una al grupo de disponibilidad como réplica secundaria.
Interrupción de réplica secundaria	La réplica principal es de L/E, la ejecución se expone a pérdida de datos.	La réplica principal no estará disponible para las transacciones de actualización del usuario hasta que no se recupere la réplica secundaria.

¹ valor predeterminado

Dos réplicas sincrónicas y una réplica de solo configuración

Un grupo de disponibilidad con dos (o más) réplicas sincrónicas y una réplica de solo configuración proporciona protección de datos y también puede proporcionar alta disponibilidad. El diagrama siguiente representa esta arquitectura:

1. Replicación sincrónica de datos de usuario en la réplica secundaria. También incluye los metadatos de configuración del grupo de disponibilidad.
2. Replicación sincrónica de los metadatos de configuración del grupo de disponibilidad. No incluye los datos de usuario.

En el diagrama de grupo de disponibilidad, una réplica principal envía los datos de configuración a la réplica secundaria y a la réplica de solo configuración. La réplica secundaria también recibe datos de usuario. La réplica de solo configuración no recibe datos de usuario. La réplica secundaria está en modo de disponibilidad sincrónica. La réplica de solo configuración no contiene las bases de datos de los metadatos del grupo de disponibilidad, solo metadatos sobre el grupo de disponibilidad. Los datos de configuración de la réplica de solo configuración se confirman sincrónicamente.

Nota

Un grupo de disponibilidad con una réplica de solo configuración es nuevo para SQL Server 2017 CU1. Todas las instancias de SQL Server en el grupo de disponibilidad deben ser de SQL Server 2017 CU1 o posterior.

El valor predeterminado para REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT es 0. En la tabla siguiente se describe la disponibilidad de este comportamiento.

Comportamiento de la disponibilidad	Alta disponibilidad y protección de datos	Protección de los datos
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0 1	1
Interrupción principal	Conmutación por error automática. La nueva réplica principal es de L/E. Es posible que haya pérdida de datos.	Conmutación por error automática. La nueva réplica principal no está disponible para transacciones de actualización del usuario.
Interrupción de la réplica secundaria	La réplica principal es de L/E, la ejecución se expone a pérdida de datos (si se produce un error en la réplica principal y no se puede recuperar). No se produce una conmutación automática por error si la réplica principal también presenta errores.	La réplica principal no está disponible para transacciones de actualización del usuario. No hay ninguna réplica a la que realizar la conmutación por error si también se produce un error en la réplica principal.
Interrupción de la réplica de solo configuración	La réplica principal es de L/E. No se produce una conmutación automática por error si la réplica principal también presenta errores.	La réplica principal es de L/E. No se produce una conmutación automática por error si la réplica principal también presenta errores.
Interrupción de réplicas secundarias y de solo configuración de replicación sincrónica	La réplica principal no está disponible para transacciones de actualización del usuario. Sin conmutación automática por error.	La réplica principal no está disponible para transacciones de actualización del usuario. No se produce ninguna réplica en la conmutación por error en caso de que sea la réplica principal.

¹ valor predeterminado

Nota

La instancia de SQL Server que hospeda la réplica de solo configuración también puede hospedar otras bases de datos. También puede participar como una base de datos solo de configuración para más de un grupo de disponibilidad.

Requisitos

• Todas las réplicas de un grupo de disponibilidad con una réplica de solo configuración deben ser SQL Server 2017 CU 1 o posterior.
• Cualquier edición de SQL Server puede hospedar una réplica de solo configuración, incluida SQL Server Express.
• El grupo de disponibilidad necesita al menos una réplica secundaria, además de la réplica principal.
• Las réplicas de solo configuración no cuentan para el número máximo de réplicas por instancia de SQL Server. La edición estándar de SQL Server permite hasta tres réplicas, la edición de SQL Server Enterprise permite hasta 9.

Consideraciones

• No hay más de una réplica de solo configuración en cada grupo de disponibilidad.
• Una réplica de solo configuración no puede ser una réplica principal.
• No se puede modificar el modo de disponibilidad de una réplica de solo configuración. Para cambiar de una réplica de solo configuración a una réplica secundaria sincrónica o asincrónica, quite la réplica de solo configuración y agregue una réplica secundaria con el modo de disponibilidad requerido.
• Una réplica de solo configuración es sincrónica con los metadatos del grupo de disponibilidad. No existen datos de usuario.
• Un grupo de disponibilidad con una réplica principal y una réplica de solo configuración, pero ninguna réplica secundaria no es válido.
• No se puede crear un grupo de disponibilidad en una instancia de la edición SQL Server Express.

Información sobre el agente de recursos de SQL Server para Pacemaker

SQL Server 2017 (14.x) introdujo sequence_number para sys.availability_groups mostrar si una réplica marcada como SYNCHRONOUS_COMMIT estaba actualizada. sequence_number es un valor BIGINT con una progresión continua que representa el grado de actualización de la réplica del grupo de disponibilidad local con respecto al resto de réplicas del grupo de disponibilidad. Las conmutaciones por error, la adición o la eliminación de réplicas y otras operaciones del grupo de disponibilidad actualizan este número. El número se actualiza en la réplica principal y, después, se inserta en las réplicas secundarias. Por tanto, una réplica secundaria que esté actualizada tiene el mismo sequence_number que la principal.

Cuando Pacemaker decide promover una réplica a principal, en primer lugar envía una notificación a todas las réplicas para extraer el número de secuencia y almacenarlo (esta notificación se denomina notificación previa a la promoción). A continuación, cuando Pacemaker intenta promocionar una réplica a primaria, la réplica solo se promociona a sí misma si su número de secuencia es el más alto de todos los números de secuencia de todas las réplicas; de lo contrario, rechaza la operación de promoción. De esta manera, solo se puede promover a principal la réplica con el número de secuencia más alto, lo que garantiza que no se producirá una pérdida de datos.

Solo se garantiza que la promoción funcione si al menos una réplica disponible para la promoción tiene el mismo número de secuencia que la réplica principal anterior. El comportamiento predeterminado es que el agente de recursos de Pacemaker establezca automáticamente REQUIRED_COPIES_TO_COMMIT de forma que al menos una réplica secundaria de confirmación sincrónica está actualizada y disponible para ser el destino de una conmutación por error automática. Con cada acción de supervisión, el valor de REQUIRED_COPIES_TO_COMMIT se calcula (y actualiza, si es necesario) como ("número de réplicas de confirmación sincrónica" / 2). Después, en tiempo de conmutación por error, el agente de recursos requiere que (total number of replicas - required_copies_to_commit réplicas) respondan a la notificación previa a la promoción para poder promover una de ellas a principal. La réplica con el valor de sequence_number más alto se promueve a principal.

Por ejemplo, consideremos el caso de un grupo de disponibilidad con tres réplicas sincrónicas (una réplica principal y dos réplicas secundarias de confirmación sincrónica).

• REQUIRED_COPIES_TO_COMMIT es 3 / 2 = 1

• El número necesario de réplicas para responder a la acción previa a la promoción es de 3 - 1 = 2. Por lo que dos réplicas tienen que estar activas para que se desencadene la conmutación por error. Cuando se produce una interrupción principal, si una de las réplicas secundarias no responde y solo una de las secundarias responde a la acción de previa a la promoción, el agente de recursos no puede garantizar que la secundaria que ha respondido tenga el sequence_number más alto, y no se desencadena una conmutación por error.

Un usuario puede elegir invalidar el comportamiento predeterminado y configurar el recurso de grupo de disponibilidad para no establecer REQUIRED_COPIES_TO_COMMIT automáticamente, como se ha mostrado anteriormente..

Importante

Cuando REQUIRED_COPIES_TO_COMMIT es 0, existe riesgo de pérdida de datos. En el caso de una interrupción de la réplica principal, el agente de recursos no desencadenará automáticamente una conmutación por error. El usuario tiene que decidir si quiere esperar para que la principal se recupere o conmute por error de forma manual.

Para establecer REQUIRED_COPIES_TO_COMMIT en 0, ejecute:

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

El comando equivalente con crm (en SLES) es:

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

Para revertir al valor calculado predeterminado, ejecute:

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Nota

Actualizar las propiedades de recursos hace que todas las réplicas se detengan y reinicien. Esto significa que la réplica principal se degradará temporalmente a secundaria y se volverá a promover de nuevo, lo que causará una falta de disponibilidad de escritura temporal. El nuevo valor de REQUIRED_COPIES_TO_COMMIT solo se establecerá una vez que se reinicien las réplicas, por lo que no será instantáneo al ejecutar el comando del equipo.

Equilibrio de la alta disponibilidad y la protección de datos

El comportamiento predeterminado anterior también se aplica en el caso de dos réplicas sincrónicas (principal + secundaria). Pacemaker tiene como valor predeterminado REQUIRED_COPIES_TO_COMMIT = 1 para asegurarse de que la réplica secundaria siempre esté actualizada para la máxima protección de datos.

Advertencia

Esto viene con un mayor riesgo de falta de disponibilidad de la réplica principal debido a interrupciones previstas e imprevistas en la réplica secundaria. El usuario puede elegir cambiar el comportamiento predeterminado del agente de recursos e invalidar REQUIRED_COPIES_TO_COMMIT en 0:

sudo pcs resource update <ag1> required_copies_to_commit=0

Una vez que se invalida, el agente de recursos usa la nueva configuración para REQUIRED_COPIES_TO_COMMIT y deja de calcularlo. Los usuarios tienen que actualizarlo de forma manual según corresponda (por ejemplo, si aumentan el número de réplicas).

Las tablas siguientes describen el resultado de una interrupción para las réplicas principal o secundaria en configuraciones de recursos de grupo de disponibilidad diferentes:

Grupo de disponibilidad: dos réplicas de sincronización

Configuración	Interrupción principal	Interrupción de réplica secundaria
REQUIRED_COPIES_TO_COMMIT = 0	El usuario tiene que emitir una FAILOVER manual. Es posible que haya pérdida de datos. La nueva réplica principal es de L/E.	La réplica principal es de L/E, la ejecución se expone a pérdida de datos.
REQUIRED_COPIES_TO_COMMIT = 11	El clúster emite automáticamente FAILOVER No se produce pérdida de datos. La nueva réplica principal rechaza todas las conexiones hasta que la réplica principal anterior se recupere y una al grupo de disponibilidad como réplica secundaria.	La réplica principal rechaza todas las conexiones hasta que se recupere la secundaria.

¹ Comportamiento predeterminado del agente de recursos de SQL Server para Pacemaker.

Grupo de disponibilidad: tres réplicas de sincronización

Configuración	Interrupción principal	Interrupción de réplica secundaria
REQUIRED_COPIES_TO_COMMIT = 0	El usuario tiene que emitir una FAILOVER manual. Es posible que haya pérdida de datos. La nueva réplica principal es de L/E.	La réplica principal es de L/E.
REQUIRED_COPIES_TO_COMMIT = 11	El clúster emite automáticamente FAILOVER. No se produce pérdida de datos. La nueva réplica principal es de L/E.	La réplica principal es de L/E.

¹ Comportamiento predeterminado del agente de recursos de SQL Server para Pacemaker.

Contenido relacionado

• Grupos de disponibilidad en Linux