¿Qué es un grupo de disponibilidad independiente?

Se aplica a: SQL Server 2022 (16.x)

Un grupo de disponibilidad independiente es un grupo de disponibilidad (AG) Always On que admite:

• la administración de objetos de metadatos (usuarios, inicios de sesión, permisos, trabajos del Agente SQL, etc.) en el nivel de AG, además de en el nivel de instancia.

• bases de datos de sistema independientes y especializadas dentro del grupo de disponibilidad.

En este artículo se detallan las similitudes, las diferencias y las funcionalidades de los grupos de disponibilidad independientes.

Información general

Los AG suelen constar de una o varias bases de datos de usuario destinadas a funcionar como un grupo coordinado, y que se replican en algún número de nodos de un clúster. Cuando se produce un error en el nodo, o en el estado de SQL Server en el nodo que hospeda la copia principal, el grupo de bases de datos se mueve como una unidad a otro nodo de réplica del AG. Todas las bases de datos de usuario se mantienen sincronizadas en todas las réplicas del grupo de disponibilidad, ya sea en modo sincrónico o asincrónico.

Esto funciona bien para las aplicaciones que solo interactúan con ese conjunto de bases de datos de usuario, pero aparecen dificultades cuando las aplicaciones también dependen de objetos como usuarios, inicios de sesión, permisos, trabajos de agente, etc., que se almacenan en una de las bases de datos del sistema (master o msdb). Para que las aplicaciones funcionen sin problemas y de forma predecible, el administrador debe asegurarse manualmente de que cualquier cambio en estos objetos esté duplicado en todas las instancias de réplica del AG. Si se introduce una nueva instancia en el AG, las bases de datos se pueden inicializar automáticamente o manualmente en un proceso sencillo, pero todas las personalizaciones de la base de datos del sistema se deben volver a configurar en la nueva instancia para que coincidan con las demás réplicas.

Los grupos de disponibilidad independiente amplían el concepto del grupo de bases de datos que se replica para incluir partes pertinentes de las bases de datos master y msdb. Hay que entenderlo como el contexto de ejecución de las aplicaciones que usan el AG independiente. La idea es que el entorno del grupo de disponibilidad independiente incluya la configuración que afectaría a la aplicación basándose en ellos. Por lo tanto, el entorno de AG contenido se refiere a todas las bases de datos con las que interactúa la aplicación, la autenticación que usa (inicios de sesión, usuarios, permisos), los trabajos programados que espera que se ejecuten y otras opciones de configuración que afectan a la aplicación.

Esto es diferente de las bases de datos independientes, que usan un mecanismo distinto para las cuentas de usuario, almacenando la información de usuario dentro de la propia base de datos. Las bases de datos independientes solo replican inicios de sesión y usuarios, y el ámbito del inicio de sesión o usuario replicado se limita a esa base de datos única (y sus réplicas).

Por el contrario, en un AG independiente, se pueden crear usuarios, inicios de sesión, permisos, etc. en el nivel de AG, y serán coherentes automáticamente entre réplicas del AG, así como entre bases de datos dentro de ese AG independiente. Esto evita que el administrador tenga que realizar estos cambios manualmente.

Cambios de SQL Server 2025

La versión preliminar de SQL Server 2025 (17.x) presenta compatibilidad con grupos de disponibilidad distribuidos para grupos de disponibilidad contenidos.

Diferencias

Hay algunas diferencias prácticas que se deben tener en cuenta al trabajar con grupos de disponibilidad independientes, como la creación de bases de datos del sistema independientes y el forzado de la conexión en el nivel de grupo de disponibilidad independiente, en lugar de la conexión en el nivel de instancia.

Bases de datos del sistema independientes

Cada grupo de disponibilidad independiente tiene sus propias bases de datos del sistema master y msdb, cuyo nombre figura después del nombre del grupo de disponibilidad. Por ejemplo, en el AG independiente MyContainedAG, se tendrán bases de datos denominadas MyContainedAG_master y MyContainedAG_msdb. Estas bases de datos del sistema se propagan automáticamente a las nuevas réplicas y las actualizaciones se replican en estas bases de datos igual que cualquier otra base de datos de un grupo de disponibilidad. Esto significa que cuando se agrega un objeto como un inicio de sesión o un trabajo de agente mientras se está conectado al grupo de disponibilidad independiente, cuando el grupo de disponibilidad independiente conmuta por error a otra instancia, conectándose al grupo de disponibilidad independiente, se siguen viendo los trabajos de agente, y se pueden autenticar con el inicio de sesión creado en el grupo de disponibilidad independiente.

Las bases de datos del sistema en un Grupo de Disponibilidad (AG) independiente de nueva creación no son copias de la instancia en la que se ejecuta el comando CREATE AVAILABILITY GROUP. Son plantillas inicialmente vacías sin datos. Inmediatamente después de la creación, las cuentas de administrador de la instancia que crean el grupo de disponibilidad independiente se copian en el grupo de disponibilidad independiente master. De este modo, el administrador puede iniciar sesión en el grupo de disponibilidad independiente y configurar el resto de los valores.

Si se han creado configuraciones o usuarios locales en la instancia, no aparecerán automáticamente al crear las bases de datos del sistema independientes y no estarán visibles al conectarse al AG independiente. Una vez que la base de datos del usuario se ha unido a un grupo de disponibilidad independiente, se dejará de acceder inmediatamente a estos usuarios. Es necesario volver a crearlos manualmente en las bases de datos del sistema independientes en el contexto del AG independiente conectándolos directamente a la base de datos o usando el punto de conexión de escucha. La excepción es que todos los inicios de sesión del rol sysadmin de la instancia principal se copian en la nueva base de datos AG específica master durante la creación del AG independiente.

Sincronización de datos inicial

Las bases de datos del sistema contenidas solo admiten la siembra automática como forma inicial de sincronización de datos.

En SQL Server 2022 (16.x) y versiones anteriores, los grupos de disponibilidad contenidos deben usar la asignación automática en el momento de la creación. Cuando se use la instrucción CREATE AVAILABILITY GROUP o el asistente para nuevo grupo de disponibilidad en SQL Server Management Studio, incluya solo bases de datos de usuario que admitan propagación automática. Para añadir bases de datos de gran tamaño mediante propagación manual (JOIN ONLY), espere hasta que se cree el AG independiente.

En la versión preliminar de SQL Server 2025 (17.x), las bases de datos del sistema contenidas siempre usan el sembrado automático, incluso si la CREATE AVAILABILITY GROUP instrucción especifica el sembrado manual. Puede establecer el modo de propagación como manual para así crear un AG independiente y, posteriormente, añadir bases de datos de usuario mediante métodos de sincronización distintos de la propagación automática.

Restaurar una base de datos del sistema independiente

Para restaurar copias de seguridad de bases de datos contenidas del sistema, siga estos pasos:

1. Quite el grupo de disponibilidad independiente.

2. Restaure las bases de datos contenidas master y msdb en la réplica principal original del AG independiente.

3. Elimine las base de datos independientes master y msdb de las réplicas secundarias.

4. En la réplica principal, vuelva a crear el AG independiente utilizando el nombre y los nodos originales, con las sintaxis WITH (CONTAINED, REUSE_SYSTEM_DATABASES) y SEEDING_MODE = AUTOMATIC.

Al volver a crear un grupo de disponibilidad independiente no incluya bases de datos del sistema independientes en la instrucción CREATE AVAILABILITY GROUP. SQL Server los detecta automáticamente cuando REUSE_SYSTEM_DATABASES se especifica. En SQL Server 2022 (16.x) y versiones anteriores, solo incluyen bases de datos de usuario pequeñas que admiten la propagación automática. Añada por separado las bases de datos de gran tamaño después de crear el AG independiente, mediante JOIN ONLY.

Trabajos del grupo de disponibilidad independiente

Los trabajos que pertenecen a un grupo de disponibilidad independiente se ejecutan solo en la réplica principal. No se ejecutan en réplicas secundarias.

Conexión (entorno independiente)

Es importante comprender la diferencia entre conectarse a la instancia y conectarse al grupo de disponibilidad independiente. La única manera de acceder al entorno del grupo de disponibilidad incluido en el contenedor es conectarse al agente de escucha de ese grupo de disponibilidad o conectarse a una base de datos que se encuentre en ese grupo de disponibilidad.

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"

Donde MyContainedDatabase es una base de datos dentro del grupo de disponibilidad independiente con el que desea interactuar.

Esto significa que debe crear un agente de escucha para que el grupo de disponibilidad independiente use eficazmente un grupo de disponibilidad independiente. Si se conecta a una de las instancias que hospedan el grupo de disponibilidad independiente en lugar de directamente al grupo de disponibilidad independiente a través del agente de escucha, estará en el entorno de la instancia y no en el grupo de disponibilidad independiente.

Por ejemplo, si el grupo de disponibilidad MyContainedAG se hospeda en el servidor SERVER\MSSQLSERVER y, en lugar de conectarse al agente de escucha MyContainedAG_Listener, se establece conexión con la instancia mediante SERVER\MSSQLSERVER, se estará en el entorno de la instancia y no en el entorno de MyContainedAG. Esto significa que se estará sujeto al contenido (usuarios, permisos, trabajos, etc.) que se encuentra en las bases de datos del sistema de la instancia. Para acceder al contenido que se encuentra en las bases de datos del sistema independientes del grupo de disponibilidad independiente, conéctese al agente de escucha del grupo de disponibilidad independiente (MyContainedAG_Listener, por ejemplo) en su lugar. Cuando se conecta a la instancia a través del agente de escucha del grupo de disponibilidad independiente, cuando interactúa con master, realmente se le redirige a la base de datos independiente master (por ejemplo, MyContainedAG_master).

Enrutamiento de solo lectura y grupos de disponibilidad independientes

Si configura el enrutamiento de solo lectura para redirigir las conexiones con intención de lectura a una réplica secundaria (consulte Configuración del enrutamiento de solo lectura para un grupo de disponibilidad de Always On) y desea conectarse mediante un inicio de sesión que se crea solo en el grupo de disponibilidad independiente, hay algunas consideraciones adicionales:

• Debe especificar una base de datos que forme parte del grupo de disponibilidad independiente en la cadena de conexión
• El usuario especificado en la cadena de conexión debe tener permiso para acceder a las bases de datos del grupo de disponibilidad contenido.

Por ejemplo, en la siguiente cadena de conexión, donde AdventureWorks es una base de datos dentro del grupo de disponibilidad (AG) contenido que tiene MyContainedListener, y donde MyUser es un usuario definido en el grupo de disponibilidad (AG) contenido y no en ninguna de las instancias participantes:

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"

Esta cadena de conexión le permitiría conectarse a la réplica secundaria legible que forma parte de la configuración de enrutamiento de solo lectura y estaría dentro del contexto del grupo de disponibilidad independiente.

Diferencias entre conectarse a la instancia y conectarse al grupo de disponibilidad independiente

• Cuando se conecta a un grupo de disponibilidad independiente, los usuarios solo ven las bases de datos en el grupo de disponibilidad independiente, además de tempdb.
• En el nivel de instancia, los nombres del grupo de disponibilidad independiente master y msdb son [contained AG]_master y [contained AG]_msdb. Dentro del grupo de disponibilidad independiente, sus nombres son master y msdb.
• El identificador de base de datos para el grupo de disponibilidad independiente master es 1 desde dentro del grupo de disponibilidad independiente, pero algo más cuando se conecta a la instancia.
• Aunque los usuarios no ven las bases de datos fuera del grupo de disponibilidad independiente en sys.databases cuando se conecten mediante un grupo de disponibilidad independiente, pueden acceder a esas bases de datos por el nombre de tres partes o a través del comando USE.
• La configuración del servidor a través de sp_configure se puede leer desde la conexión del grupo de disponibilidad independiente, pero solo se puede escribir desde el nivel de instancia.
• Desde las conexiones de AG contenida, el administrador del sistema puede realizar operaciones a nivel de instancia, como apagar SQL Server.
• La mayoría de las operaciones de nivel de base de datos, de punto final o de grupo de disponibilidad solo se pueden realizar desde conexiones de instancia, no desde conexiones de grupo de disponibilidad independientes.

Interacciones con otras características

Hay consideraciones adicionales al usar determinadas características con grupos de disponibilidad independientes y hay algunas características que actualmente no son compatibles.

Copia de seguridad

Los procedimientos para realizar copias de seguridad de bases de datos en un grupo de disponibilidad independiente son los mismos que los procedimientos de copia de seguridad de bases de datos de usuario. Esto es cierto tanto para las bases de datos de usuario de los grupos de disponibilidad independiente como para las bases de datos del sistema de los grupos de disponibilidad independiente.

Si la ubicación de copia de seguridad es local, los archivos de copia de seguridad se colocan en el servidor que ejecuta el trabajo de copia de seguridad. Esto significa que los archivos de copia de seguridad pueden estar en diferentes ubicaciones.

Si la ubicación de copia de seguridad está en un recurso de red, todos los servidores que hospedan réplicas necesitan acceso a ese recurso.

Grupos de disponibilidad distribuidos

Un grupo de disponibilidad distribuido es un tipo especial de grupo de disponibilidad que abarca dos grupos de disponibilidad subyacentes. Al configurar un grupo de disponibilidad distribuido, los cambios realizados en la réplica principal global (que es la réplica principal del primer grupo de disponibilidad) se replican en la réplica principal del segundo grupo de disponibilidad, conocido como reenviador.

A partir de la versión preliminar de SQL Server 2025 (17.x) es posible configurar un grupo de disponibilidad distribuido entre dos AGs independientes. Dado que un AG independiente está basado en bases de datos de sistema independientes master y msdb, para crear un grupo de disponibilidad distribuido, el segundo AG (reenviador) debe disponer de la misma base de datos de sistema AG independiente que el grupo principal global.

Si se pretende usar un AG independiente como reenviador en un grupo de disponibilidad distribuido, debe crearse el grupo de disponibilidad independiente usando la cláusula AUTOSEEDING_SYSTEM_DATABASES para la opción WITH | CONTAINED en la instrucción CREATE AVAILABILITY GROUP. La cláusula AUTOSEEDING_SYSTEM_DATABASES indica a SQL Server que omita la creación de sus propias bases de datos AG independientes de sistema y, en su lugar, propague las bases de datos AG independientes de sistema a partir de la réplica primaria global.

Regulador de recursos

En SQL Server 2022 (16.x) antes de la actualización acumulativa 18 y en versiones anteriores de SQL Server, no se admite la configuración o el uso del regulador de recursos en conexiones de grupo de disponibilidad independientes.

A partir de la actualización acumulativa 18 de SQL Server 2022 (16.x), si configura el regulador de recursos en una conexión de instancia, el consumo de recursos en las conexiones de instancia o las conexiones de grupo de disponibilidad independientes se rige según lo previsto. Si intenta configurar el regulador de recursos en una conexión de grupo de disponibilidad independiente, recibirá un error.

El regulador de recursos funciona en el nivel de instancia del motor de base de datos. La configuración del regulador de recursos en el nivel de instancia no se propaga a las réplicas de disponibilidad. Debe configurar el regulador de recursos en cada instancia que hospeda una réplica de disponibilidad.

Para obtener más información, consulte Regulador de recursos y Ejemplos de configuración y mejores prácticas del regulador de recursos.

Captura de datos modificados

La captura de datos modificados (CDC) se implementa como trabajos del Agente SQL, por lo que el Agente SQL debe ejecutarse en todas las instancias con réplicas en el grupo de disponibilidad independiente.

Para usar la captura de datos modificados con un grupo de disponibilidad independiente, conéctese al agente de escucha del grupo de disponibilidad al configurar CDC para que los metadatos de CDC se configuren mediante las bases de datos del sistema independientes.

Trasvase de registros

El trasvase de registros se puede configurar si la base de datos de origen está en el grupo de disponibilidad independiente. Sin embargo, no se admite un destino de trasvase de registros dentro de un grupo de disponibilidad independiente. Además, hay un paso adicional para modificar la tarea de envío de registros después de configurar CDC.

Para configurar el trasvase de registros con un grupo de disponibilidad independiente, siga estos pasos:

1. Conéctese al agente de escucha del grupo de disponibilidad independiente.
2. Configure el trasvase de registros como lo haría normalmente.
3. Una vez configurado el trabajo de trasvase de registros, modifíquelo para conectarse al agente de escucha del grupo de disponibilidad independiente antes de realizar una copia de seguridad.

Cifrado de datos transparente (TDE)

Para usar el cifrado de datos transparente (TDE) con bases de datos de un grupo de disponibilidad independiente, instale manualmente la clave maestra de base de datos (DMK) en la base de datos independiente master dentro del grupo de disponibilidad independiente.

Las bases de datos que usan TDE dependen de los certificados de la base de datos master para descifrar la clave de cifrado de base de datos (DEK). Sin ese certificado, SQL Server no puede descifrar las bases de datos cifradas con TDE ni ponerlas en línea. En un grupo de disponibilidad independiente, SQL Server comprueba ambas bases de datos master para la DMK, la base de datos master de la instancia y la base de datos master independiente dentro del grupo de disponibilidad independiente para descifrar la base de datos. Si no encuentra el certificado en ninguna ubicación, SQL Server no podrá poner la base de datos en línea.

Para transferir la DMK desde la base de datos master de la instancia a la base de datos master independiente, consulta Traslado de una base de datos protegida TDE a otra de SQL Server, centrándote principalmente en las partes en las que se transfiere la DMK desde el servidor antiguo al nuevo.

Paquetes y planes de mantenimiento de SSIS

El uso de paquetes SSIS, incluidos los planes de mantenimiento, no se admite con grupos de disponibilidad contenidos.

No compatible

Actualmente, las siguientes características de SQL Server no son compatibles con un Grupo de Disponibilidad contenido (AG):

• Replicación de SQL Server de cualquier tipo (transaccional, combinación, instantánea, etc.).
• Trasvase de registros donde la base de datos de destino está en el grupo de disponibilidad independiente. Se admite el trasvase de registros con la base de datos de origen en el grupo de disponibilidad independiente.

Cambios de DDL

Los únicos cambios de DDL se encuentran en el flujo de trabajo CREATE AVAILABILITY GROUP. Hay una WITH cláusula con dos opciones:

<with_option_spec> ::=
CONTAINED [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ]

INDEPENDIENTE

Esto especifica que el grupo de disponibilidad que se va a crear debe ser un grupo de disponibilidad independiente.

REUSE_SYSTEM_DATABASES

La REUSE_SYSTEM_DATABASES opción solo es válida para grupos de disponibilidad independientes y especifica que el grupo de disponibilidad recién creado debe reutilizar las bases de datos del sistema independientes existentes para un grupo de disponibilidad independiente anterior con el mismo nombre. Por ejemplo, si tuviera un grupo de disponibilidad independiente con el nombre MyContainedAG y quisiera quitarlo y volver a crearlo, podría usar esta opción para reutilizar el contenido de las bases de datos del sistema independientes originales. Al usar esta opción, no especifique nombres de base de datos del sistema. SQL Server los detecta automáticamente.

AUTOSEEDING_SYSTEM_DATABASES

Se aplica a: versión preliminar de SQL Server 2025 (17.x) y versiones posteriores

Si se pretende usar el AG independiente como reenviador en un grupo de disponibilidad distribuido, se debe usar la opción AUTOSEEDING_SYSTEM_DATABASES al crear el AG independiente. Esta opción le indica a SQL Server que omita la creación de sus propias bases de datos AG independientes de sistema y, en su lugar, propague las bases de datos AG independientes de sistema a partir de la réplica primaria global.

Cambios de DMV

Hay dos adiciones a las DMV relacionadas con los grupos de disponibilidad independientes:

• La DMV sys.dm_exec_sessions tiene una columna agregada: contained_availability_group_id
• La vista de catálogo sys.availability_groups tiene la columna agregada: is_contained

Contenido relacionado

• CREAR GRUPO DE DISPONIBILIDAD (Transact-SQL)