Compartir vía

¿Qué es un grupo de disponibilidad AlwaysOn?

  • Artículo

Se aplica a: SQL Server

En este artículo se presentan los conceptos centrales de Grupos de disponibilidad AlwaysOn para configurar y administrar uno o varios grupos de disponibilidad en la edición Enterprise de SQL Server. Para la edición Standard, revise Grupos de disponibilidad Always On básicos con una base de datos única.

La característica Grupos de disponibilidad AlwaysOn es una solución de alta disponibilidad y de recuperación ante desastres que proporciona una alternativa empresarial a la creación de reflejo de la base de datos. Grupos de disponibilidad Always On maximiza la disponibilidad de un conjunto de bases de datos de usuario para una empresa. Un grupo de disponibilidad admite un entorno de conmutación por error para un conjunto discreto de bases de datos de usuario, conocido como bases de datos de disponibilidad, que realizan la conmutación por error conjuntamente. Un grupo de disponibilidad admite un conjunto de bases de datos principales de lectura y escritura y de uno a ocho conjuntos de bases de datos secundarias correspondientes. Opcionalmente, las bases de datos secundarias pueden estar disponibles para el acceso de solo lectura o para algunas operaciones de copia de seguridad.

Con SQL Server habilitado por Azure Arc, puedes ver los grupos de disponibilidad en Azure Portal.

Información general

Un grupo de disponibilidad admite un entorno replicado de un conjunto discreto de bases de datos de usuario, conocido como bases de datos de disponibilidad. Un grupo de disponibilidad se puede crear para alta disponibilidad (HA) o para escalado de lectura. Un grupo de disponibilidad para alta disponibilidad es un grupo de bases de datos que realizan la conmutación por error conjuntamente. Un grupo de disponibilidad para escalado de lectura es un grupo de bases de datos que se copian en otras instancias de SQL Server para cargas de trabajo de solo lectura. Un grupo de disponibilidad admite un conjunto de bases de datos principales y entre uno y ocho conjuntos de las bases de datos secundarias correspondientes. Las bases de datos secundarias no son copias de seguridad. Continúe haciendo copias de seguridad de las bases de datos y de sus registros de transacciones periódicamente.

Sugerencia

Puede crear cualquier tipo de copia de seguridad de una base de datos principal. También puede crear copias de seguridad de registros y copias de seguridad completas de solo copia de las bases de datos secundarias. Para más información, consulte Descarga de copias de seguridad admitidas en las réplicas secundarias de un grupo de disponibilidad.

Cada conjunto de bases de datos de disponibilidad es hospedado por una réplica de disponibilidad. Existen dos tipos de réplicas de disponibilidad: una réplica principal única que hospeda las bases de datos principales, y entre una y ocho réplicas secundarias, cada una de las cuales hospeda un conjunto de bases de datos secundarias y podría ser el destino de una posible conmutación por error del grupo de disponibilidad. Un grupo de disponibilidad realiza la conmutación por error en el nivel de réplica de disponibilidad. Una réplica de disponibilidad proporciona redundancia solo en el nivel de base de datos del conjunto de bases de datos de un grupo de disponibilidad. Las conmutaciones por error no se deben a problemas de bases de datos, como, por ejemplo, a que una base de datos pase a ser sospechosa debido a la pérdida de un archivo de datos o a los daños de un registro de transacciones.

La réplica principal hace que las bases de datos principales estén disponibles para las conexiones de lectura/escritura que tienen como origen los clientes. La réplica principal envía las entradas del registro de transacciones de cada base de datos principal a todas las bases de datos secundarias. Este proceso, conocido como sincronización de datos, tiene lugar en el nivel de la base de datos. Cada una de las réplicas secundarias almacena en memoria caché las entradas del registro de transacciones (refuerza el registro) y las aplica a la base de datos secundaria correspondiente. La sincronización de datos se produce entre la base de datos principal y cada una de las bases de datos secundarias conectadas, independientemente de las demás bases de datos. Por tanto, una base de datos secundaria puede suspenderse o sufrir un error sin afectar a otras bases de datos secundarias, y una base de datos principal puede suspenderse o sufrir un error sin afectar a otras bases de datos principales.

Opcionalmente, puede configurar una o varias réplicas secundarias para que admitan acceso de solo lectura a las bases de datos secundarias y puede configurar las réplicas secundarias para que permitan copias de seguridad de las bases de datos secundarias.

SQL Server 2017 incorporó dos arquitecturas diferentes para los grupos de disponibilidad. Los grupos de disponibilidad AlwaysOn proporcionan alta disponibilidad, recuperación ante desastres y equilibrio del escalado de lectura. Estos grupos de disponibilidad requieren un administrador de clústeres. En Windows, la característica de clústeres de conmutación por error proporciona el administrador de clústeres. En Linux, puede usar Pacemaker. La otra arquitectura es un grupo de disponibilidad de escalado de lectura. Un grupo de disponibilidad de escalado de lectura proporciona réplicas para las cargas de trabajo de solo lectura, pero no alta disponibilidad. En un grupo de disponibilidad de escalado de lectura, no hay ningún administrador de clústeres, ya que la conmutación por error no puede ser automática.

La implementación de Grupos de disponibilidad AlwaysOn para alta disponibilidad en Windows requiere un clúster de conmutación por error de Windows Server (WSFC). Cada réplica de disponibilidad de un determinado grupo de disponibilidad debe residir en otro nodo del mismo WSFC. La única excepción es que mientras se migra a otro clúster de WSFC, un grupo de disponibilidad puede ocupar temporalmente dos clústeres.

Nota:

Para obtener más información sobre los grupos de disponibilidad en Linux, vea Grupos de disponibilidad para SQL Server en Linux.

En una configuración de alta disponibilidad, se crea un rol de clúster por cada grupo de disponibilidad que cree. El clúster de WSFC supervisa este rol para evaluar el estado de la réplica principal. El quorum para Grupos de disponibilidad AlwaysOn se basa en todos los nodos del clúster de WSFC independientemente de si un nodo de clúster determinado hospeda alguna réplica de disponibilidad. A diferencia de la creación de reflejo de la base de datos, no hay ningún rol testigo en Grupos de disponibilidad AlwaysOn.

Nota:

Para obtener información sobre la relación de componentes Always On de SQL Server con el clúster de WSFC, consulte Clústeres de conmutación por error de Windows Server con SQL Server.

En la ilustración siguiente se muestra un grupo de disponibilidad que contiene solo una réplica principal y cuatro réplicas secundarias. Se admiten hasta ocho réplicas secundarias, incluidas una réplica principal y cuatro réplicas secundarias de confirmación sincrónica.

Diagrama de un grupo de disponibilidad con cinco réplicas.

Términos y definiciones

Término Descripción
grupo de disponibilidad Contenedor para un conjunto de bases de datos, las bases de datos de disponibilidad, que conmutan por error juntas.
base de datos de disponibilidad Base de datos que pertenece a un grupo de disponibilidad. Para cada base de datos de disponibilidad, el grupo de disponibilidad mantiene una sola copia de lectura y escritura (la base de datos principal) y de una a ocho copias de solo lectura (bases de datos secundarias).
base de datos principal La copia de lectura y escritura de una base de datos de disponibilidad.
base de datos secundaria Una copia de solo lectura de una base de datos de disponibilidad.
réplica de disponibilidad Creación de instancia de un grupo de disponibilidad hospedado por una instancia específica de SQL Server y mantiene una copia local de cada base de datos de disponibilidad perteneciente al grupo de disponibilidad. Existen dos tipos de réplicas de disponibilidad: una sola réplica principal y de una a ocho réplicas secundarias.
réplica principal La réplica de disponibilidad que hace que las bases de datos principales estén disponibles para las conexiones de lectura y escritura de clientes y, además, envía las entradas del registro de transacciones para cada base de datos principal a cada réplica secundaria.
réplica secundaria Réplica de disponibilidad que mantiene una copia secundaria de cada base de datos de disponibilidad y actúa como posible destino de conmutación por error para el grupo de disponibilidad. Opcionalmente, una réplica secundaria puede admitir acceso de solo lectura a bases de datos secundarias y la creación de copias de seguridad de bases de datos secundarias.
agente de escucha de grupo de disponibilidad Nombre del servidor al que los clientes pueden conectarse para tener acceso a una base de datos en una réplica principal o secundaria de un grupo de disponibilidad. Los agentes de escucha del grupo de disponibilidad dirigen las conexiones entrantes a la réplica principal o una réplica secundaria de solo lectura.

Bases de datos de disponibilidad

Para agregar una base de datos a un grupo de disponibilidad, la base de datos debe ser una base de datos de lectura/escritura en línea que exista en la instancia del servidor que hospeda la réplica principal. Al agregar una base de datos, se une al grupo de disponibilidad como base de datos principal, mientras permanece disponible para los clientes. No existe una base de datos secundaria correspondiente hasta que las copias de seguridad de la nueva base de datos principal se restauran a la instancia del servidor que hospeda la réplica secundaria (utilizando RESTORE WITH NORECOVERY). La nueva base de datos secundaria está en estado RESTORING hasta que se une al grupo de disponibilidad. Para obtener más información, vea Iniciar el movimiento de datos en una base de datos secundaria AlwaysOn (SQL Server).

La unión coloca la base de datos secundaria en estado ONLINE e inicia la sincronización de datos con la base de datos principal correspondiente. Lasincronización de datos es el proceso mediante el cual los cambios en una base de datos principal se reproducidos en una base de datos secundaria. La sincronización de datos implica que la base de datos principal envía entradas del registro de transacciones a la base de datos secundaria.

Importante

Una base de datos de disponibilidad a veces se denomina réplica de base de datos en los nombres de Objetos de administración de SQL Server (SMO), Transact-SQL y PowerShell. Por ejemplo, el término "réplica de base de datos" se usa en los nombres de las vistas de administración dinámicas de AlwaysOn que devuelven información sobre las bases de datos de disponibilidad: sys.dm_hadr_database_replica_states y sys.dm_hadr_database_replica_cluster_states. Sin embargo, en Libros en pantalla de SQL Server, el término "réplica" suele hacer referencia a las réplicas de disponibilidad. Por ejemplo, “replicación primaria” y “replicación secundaria” siempre hacen referencia a la disponibilidad de las réplicas.

Réplicas de disponibilidad

Cada grupo de disponibilidad define un conjunto de dos o más asociados de conmutación por error conocidos como réplicas de disponibilidad. Lasréplicas de disponibilidad son componentes del grupo de disponibilidad. Cada réplica de disponibilidad hospeda una copia de las bases de datos de disponibilidad en el grupo de disponibilidad. Para un grupo de disponibilidad determinado, las réplicas de disponibilidad deben hospedarse en instancias independientes de SQL Server que residan en nodos diferentes de un clúster de WSFC. Cada una de estas instancias del servidor debe estar habilitada para AlwaysOn.

SQL Server 2019 (15.x) aumenta el número máximo de réplicas sincrónicas a 5, de las 3 que eran en SQL Server 2017 (14.x). Puede configurar este grupo de cinco réplicas para habilitar la conmutación automática por error dentro del grupo. Hay una réplica principal, además de cuatro réplicas secundarias sincrónicas.

Una instancia determinada solo puede hospedar una única réplica de disponibilidad por grupo de disponibilidad. Sin embargo, cada instancia puede utilizarse para varios grupos de disponibilidad. Una instancia determinada puede ser una instancia independiente o una instancia de clúster de conmutación por error (FCI) de SQL Server . Si necesita redundancia de nivel de servidor, utilice instancias de clúster de conmutación por error.

A cada réplica de disponibilidad se le asigna un rol, ya sea el rol principal o el rol secundario, que es heredado por las bases de datos de disponibilidad de esa réplica. El rol de una réplica dada determina si hospeda bases de datos de lectura/escritura o bases de datos de solo lectura. A una réplica, conocida como réplica principal, se le asigna el rol principal y hospeda bases de datos de lectura/escritura, que se denominan bases de datos principales. Como mínimo, a otra réplica denominada réplica secundariase le asigna el rol secundario. Una réplica secundaria hospeda bases de datos de solo lectura, conocidas como bases de datos secundarias.

Nota:

Cuando el rol de una réplica de disponibilidad es indeterminado, como durante una conmutación por error, sus bases de datos están temporalmente en estado NOT SYNCHRONIZING. Su rol se establece en RESOLVING hasta que el rol de la réplica de disponibilidad se resuelve. Si una réplica de disponibilidad se resuelve en el rol principal, sus bases de datos se convierten en las bases de datos principales. Si una réplica de disponibilidad se resuelve en el rol secundario, sus bases de datos se convierten en bases de datos secundarias.

Modos de disponibilidad

El modo de disponibilidad es una propiedad de cada réplica de disponibilidad. El modo de disponibilidad determina si la réplica principal espera la confirmación de transacciones en una base de datos hasta que una réplica secundaria haya escrito las entradas del registro de transacciones en el disco (protegido el registro). Grupos de disponibilidad AlwaysOn admite dos modos de disponibilidad: modo de confirmación asincrónica y modo de confirmación sincrónica.

  • Asynchronous-commit mode

    Una réplica de disponibilidad que usa este modo de disponibilidad se conoce como réplica de confirmación asincrónica. En modo de confirmación asincrónica, la réplica principal confirma las transacciones sin esperar la confirmación de que las réplicas secundarias de confirmación asincrónica han protegido los registros de transacciones. El modo de confirmación asincrónica minimiza la latencia de las transacciones en las bases de datos secundarias pero permite que se retrasen detrás de las bases de datos principales, haciendo posible alguna pérdida de datos.

  • Synchronous-commit mode

    Una réplica de disponibilidad que usa este modo de disponibilidad se denomina réplica de confirmación sincrónica. En modo de confirmación sincrónica, antes de la confirmación de transacciones, una réplica principal de confirmación sincrónica espera a que una réplica secundaria de confirmación sincrónica notifique que ha terminado de proteger el registro. El modo de confirmación sincrónica asegura que, una vez que una base de datos secundaria se sincroniza con la base de datos principal, las transacciones confirmadas queden totalmente protegidas. Esta protección se produce a costa de que aumente la latencia de las transacciones. Opcionalmente, SQL Server 2017 incorporó una característica de secundarias sincronizadas necesarias para aumentar aún más la seguridad a costa de la latencia cuando se desea. La característica REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT puede habilitarse para requerir un número especificado de réplicas sincrónicas para confirmar una transacción antes de que una réplica principal pueda confirmarse.

Para obtener más información, consulte Diferencias entre los modos de disponibilidad para un grupo de disponibilidad Always On.

Tipos de conmutación por error

En el contexto de una sesión entre la réplica principal y una réplica secundaria, los roles principal y secundario son potencialmente intercambiables en un proceso denominado conmutación por error. Durante una conmutación por error, la réplica secundaria de destino realiza la transición al rol principal, pasando a ser la nueva réplica principal. La nueva réplica principal pone sus bases de datos en línea como bases de datos principales y las aplicaciones cliente pueden conectarse a ellas. Cuando la réplica principal anterior está disponible, realiza la transición al rol secundario, pasando a ser una réplica secundaria. Las bases de datos principales anteriores se convierten en bases de datos secundaria y se reanuda la sincronización de datos.

Un grupo de disponibilidad realiza la conmutación por error en el nivel de réplica de disponibilidad. Las conmutaciones por error no se deben a problemas de bases de datos como que una base de datos pase a ser sospechosa debido a la pérdida de un archivo de datos, la eliminación de una base de datos o los daños de un registro de transacciones.

Existen tres formas de conmutación por error: automática, manual y forzada (con posible pérdida de datos). La forma o formas de conmutación por error admitidas por una réplica secundaria dependen de su modo de disponibilidad y, para el modo de confirmación sincrónica, del modo de conmutación por error de la réplica principal y la réplica secundaria de destino, del siguiente modo.

  • El modo de confirmación sincrónica admite dos formas de conmutación por error: conmutación por error manual planeada y conmutación por error automática, si la réplica secundaria de destino está sincronizada actualmente con la réplica principal. La compatibilidad con estas formas de conmutación por error depende de la propiedad del modo de conmutación por error en los asociados de conmutación por error. Si el modo de conmutación por error se establece en "manual” en la réplica principal o la réplica secundaria, solo se admite la conmutación por error manual para esa réplica secundaria. Si el modo de conmutación por error se establece en “automático” en las réplicas principal y secundaria, se admiten la conmutación por error manual y automática en esa réplica secundaria.

    • Conmutación por error manual planeada (sin pérdida de datos)

      Una conmutación por error manual se produce después de que un administrador de base de datos emite un comando de conmutación por error y produce la transición de una réplica secundaria sincronizada al rol principal (con protección de datos garantizada) y la transición de la réplica principal al rol secundario. Una conmutación por error manual requiere que la réplica principal y la réplica secundaria de destino se ejecuten en modo de confirmación sincrónica, y la réplica secundaria ya debe estar sincronizada.

    • Conmutación automática por error (sin pérdida de datos)

      Una conmutación por error automática se produce en respuesta a un error que produce la transición de una réplica secundaria al rol principal (con protección de datos garantizada). Cuando la réplica principal anterior está disponible, efectúa la transición al rol secundario. La conmutación automática por error requiere que la réplica principal y la réplica secundaria de destino se ejecuten en modo de confirmación sincrónica con el modo de conmutación por error establecido en Automático. Además, la réplica secundaria ya debe estar sincronizada, tener cuórum de WSFC y cumplir las condiciones especificadas por la directiva de conmutación por error flexible del grupo de disponibilidad.

  • En el modo de confirmación asincrónica, la única forma de conmutación por error es la conmutación por error manual forzada (con posible pérdida de datos), denominada normalmente conmutación por error forzada. La conmutación por error forzada se considera una forma de conmutación por error manual porque solo se puede iniciar manualmente. La conmutación por error forzada es una opción de recuperación ante desastres. Es la única forma de conmutación por error posible cuando la réplica secundaria de destino no está sincronizada con la réplica principal.

Para más información, consulte Conmutación por error y modos de conmutación por error (grupos de disponibilidad AlwaysOn).

Importante

  • Las instancias de clúster de conmutación por error (FCI) de SQL Server no admiten la conmutación automática por error de grupos de disponibilidad, por lo tanto, todas las réplicas de disponibilidad hospedadas por un FCI solo se pueden configurar para la conmutación por error manual.
  • Si emite un comando de conmutación por error forzada en una réplica secundaria sincronizada, la réplica secundaria se comportará igual que en el caso de una conmutación por error manual planeada.

Ventajas

Los grupos de disponibilidad Always On proporcionan un rico conjunto de opciones que mejoran la disponibilidad de la base de datos y el uso de los recursos. Los componentes clave son los siguientes:

Conexiones de cliente

Puede proporcionar conectividad de cliente a la réplica principal de un grupo de disponibilidad determinado mediante la creación de un agente de escucha del grupo de disponibilidad. Un agente de escucha del grupo de disponibilidad proporciona un conjunto de recursos que se adjunta a un grupo de disponibilidad determinado para dirigir las conexiones de cliente a la réplica de disponibilidad adecuada.

Un agente de escucha del grupo de disponibilidad está asociada a un nombre DNS único que actúa como un nombre de red virtual (VNN), una o más direcciones IP virtuales (VIP) y un número de puerto TCP. Para obtener más información, consulte Conexión a un agente de escucha de grupo de disponibilidad Always On.

Sugerencia

Si un grupo de disponibilidad posee solo dos réplicas de disponibilidad y no está configurado para permitir el acceso de lectura a la réplica secundaria, los clientes pueden conectarse a la réplica principal usando una cadena de conexión de creación de reflejo de la base de datos. Este enfoque puede ser útil temporalmente después de migrar una base de datos de creación de reflejo de la base de datos a Grupos de disponibilidad AlwaysOn. Antes de agregar réplicas secundarias adicionales, tendrá que crear un cliente de escucha para el grupo de disponibilidad y actualizar las aplicaciones para que se utilice el nombre de red del cliente de escucha.

Réplicas secundarias activas

Grupos de disponibilidad AlwaysOn admite réplicas secundarias activas. Entre las funciones secundarias activas se incluye la compatibilidad con:

  • Realizar operaciones de copia de seguridad en las réplicas secundarias

    Las réplicas secundarias admiten la realización de copias de seguridad de registros y de solo copia de toda una base de datos, un archivo o un grupo de archivos. Puede configurar el grupo de disponibilidad para que se especifique la preferencia por la que las copias de seguridad deben realizarse. Es importante entender que SQL Server no aplica la preferencia, por lo que las copias de seguridad ad hoc no resultan afectadas. La interpretación de esta preferencia depende de la lógica, si existe, del script con los trabajos de copia de seguridad ejecutado para cada una de las bases de datos de un grupo de disponibilidad dado. En el caso de una réplica de disponibilidad individual, puede especificar la prioridad para realizar copias de seguridad en esta réplica en relación con las otras réplicas del mismo grupo de disponibilidad. Para más información, consulte Descarga de copias de seguridad admitidas en las réplicas secundarias de un grupo de disponibilidad.

  • Acceso de solo lectura a una o varias réplicas secundarias (réplicas secundarias legibles)

    Cualquier réplica de disponibilidad secundaria se puede configurar para permitir el acceso de solo lectura a sus bases de datos locales, aunque algunas operaciones no sean totalmente compatibles. Esto impide los intentos de conexión de lectura y escritura a la réplica secundaria. También es posible evitar cargas de trabajo de solo lectura en la réplica principal al permitir solo el acceso de lectura y escritura. Esto impide que se realicen conexiones de solo lectura a la réplica principal. Para obtener más información, consulte Descarga de cargas de trabajo de solo lectura a la réplica secundaria de un grupo de disponibilidad Always On.

    Si un grupo de disponibilidad posee actualmente un agente de escucha de grupo de disponibilidad y una o varias réplicas secundarias legibles, SQL Server puede enrutar las solicitudes de conexión de intento de lectura a una de ellas (enrutamiento de solo lectura). Para obtener más información, consulte Conexión a un agente de escucha de grupo de disponibilidad Always On.

Tiempo de espera de la sesión

El tiempo de espera de la sesión es una propiedad de la réplica de disponibilidad que determina cuánto tiempo puede permanecer inactiva la conexión con otra réplica de disponibilidad antes de que se cierre la conexión. Las réplicas principales y secundarias hacen ping entre sí para indicar que siguen estando activas. Si se recibe un ping de otra réplica durante el tiempo de espera, significa que la conexión todavía está abierta y que las instancias del servidor se están comunicando. Al recibir un ping, una réplica de disponibilidad restablece el contador de tiempo de espera de la sesión de esa conexión.

El tiempo de espera de la sesión impide que una réplica espere indefinidamente a recibir un ping de la otra réplica. Si no se recibe ningún ping de otra réplica durante el tiempo de espera de la sesión, el tiempo de espera de la réplica se agota. La conexión se cierra y la réplica con el tiempo de espera agotado entra en el estado DISCONNECTED. Aunque una replicación desconectada esté configurada en modo de confirmación sincrónica, las transacciones no esperan a que la réplica vuelva a conectarse y sincronizarse.

El tiempo de espera predeterminado de la sesión de cada réplica de disponibilidad es de 10 segundos. Este valor puede configurarlo el usuario, con un mínimo de 5 segundos. Normalmente, es recomendable mantener el período de espera en 10 segundos o más. Si establece el valor en menos de 10 segundos, existe la posibilidad de que un sistema sobrecargado declare un error falso.

Nota:

En el rol de resolución, el tiempo de espera de la sesión no se aplica, porque no se hace ping.

Reparación de página automática

Cada réplica de disponibilidad intenta la recuperación automática de las páginas dañadas en una base de datos local resolviendo ciertos tipos de errores que impiden la lectura de una página de datos. Si una réplica secundaria no puede leer una página, la réplica solicita una nueva copia de la página de la réplica principal. Si la réplica principal no puede leer una página, la réplica propaga una solicitud de una nueva copia a todas las réplicas secundarias y obtiene la página de la primera que responda. Si la solicitud se realiza correctamente, la copia sustituirá a la página que no se puede leer, de forma que se resuelve el error en la mayoría de los casos.

Para obtener más información, vea Reparación de página automática (grupos de disponibilidad/creación de reflejo de la base de datos).

Interoperabilidad y coexistencia con otras características del motor de base de datos

Grupos de disponibilidad AlwaysOn se puede utilizar con las siguientes características o componentes de SQL Server:

Paso siguiente

Introducción a los grupos de disponibilidad Always On