Nota
L'accés a aquesta pàgina requereix autorització. Pots provar d'iniciar sessió o canviar de directori.
L'accés a aquesta pàgina requereix autorització. Pots provar de canviar directoris.
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 fallo 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 traslada como una unidad a otro nodo de réplica en el grupo de disponibilidad (AG). Todas las bases de datos de usuario permanecen sincronizadas en todas las réplicas del Grupo de Disponibilidad, ya sea en modo sincrónica o asincrónica.
Esta arquitectura funciona bien para las aplicaciones que solo interactúan con ese conjunto de bases de datos de usuario. Sin embargo, los desafíos surgen cuando las aplicaciones también dependen de objetos como usuarios, inicios de sesión, permisos, trabajos del agente y otros objetos almacenados en una de las bases de datos del sistema (master o msdb). Para garantizar que las aplicaciones funcionen de manera fluida y predecible, el administrador debe verificar manualmente que cualquier cambio en estos objetos se refleje en todas las instancias de réplica del AG. Si agrega una nueva instancia al grupo de disponibilidad (AG), puede inicializar automáticamente o manualmente las bases de datos en un proceso sencillo. Sin embargo, debe volver a configurar todas las personalizaciones de base de datos del sistema 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 de AG contenido incluye configuraciones que afectan a la aplicación que depende de ellas. 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.
Este concepto difiere de las bases de datos independientes, que usan un mecanismo diferente 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 grupo de disponibilidad contenida, se crean usuarios, inicios de sesión, permisos, etc., a nivel de grupo de disponibilidad. Estos objetos son coherentes automáticamente entre las réplicas del grupo de disponibilidad, así como coherentes entre las bases de datos dentro de ese grupo de disponibilidad contenido. Esta coherencia evita que el administrador tenga que realizar estos cambios manualmente.
Cambios de SQL Server 2025
SQL Server 2025 (17.x) presenta compatibilidad con grupos de disponibilidad distribuidos para grupos de disponibilidad independientes.
Diferencias
Al trabajar con grupos de disponibilidad independientes, tenga en cuenta algunas diferencias prácticas. Estas diferencias incluyen la creación de bases de datos del sistema contenidas y forzar la conexión en el nivel de grupo de disponibilidad contenido en vez de conectar al 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. Al agregar un objeto como un inicio de sesión o un trabajo del agente cuando está conectado al grupo de disponibilidad contenida, sigue viendo los trabajos del agente y puede autenticarse utilizando el inicio de sesión creado en el grupo de disponibilidad contenida cuando este cambia a otra instancia.
Importante
Los grupos de disponibilidad incluidos en contenedores son un mecanismo para mantener la coherencia de las configuraciones del entorno de ejecución en todas las réplicas de un grupo de disponibilidad. NO constituyen un límite de seguridad. Por ejemplo, no hay ningún límite que mantenga una conexión con un grupo de disponibilidad independiente para acceder a las bases de datos fuera del grupo de disponibilidad.
Las bases de datos del sistema en un Grupo de Disponibilidad Contenida recién creado no son copias de la instancia en la que se ejecuta el comando CREATE AVAILABILITY GROUP. Inicialmente están vacías plantillas sin datos. Inmediatamente después de la creación, el proceso copia las cuentas de administrador en la instancia que crea el grupo de disponibilidad contenido en el grupo de disponibilidad mastercontenido. De este modo, el administrador puede iniciar sesión en el AG contenido y configurar el resto de la configuración.
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 de usuario se une a un grupo de disponibilidad independiente, estos usuarios pierden inmediatamente el acceso. 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 a esta regla es que todos los logins del rol sysadmin de la instancia principal se copian en la nueva base de datos de grupo de disponibilidad específico master durante la creación del grupo de disponibilidad contenido.
Nota
Dado que la master base de datos es independiente para cada grupo de disponibilidad independiente, las actividades de ámbito de servidor realizadas en el contexto del grupo de disponibilidad contenido solo se conservan en la base de datos del sistema independiente. Esta regla incluye la auditoría. Si audita la actividad de nivel de servidor con SQL Server Auditing, debe crear las mismas auditorías de servidor dentro de cada grupo de disponibilidad contenido.
Sincronización inicial de datos
Las bases de datos del sistema contenido solo admiten el sembrado automático como método 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 use la instrucción CREATE AVAILABILITY GROUP o el Asistente para Nuevo Grupo de Disponibilidad en SQL Server Management Studio, solo incluya bases de datos de usuario que admitan seeding automático. Para agregar grandes bases de datos mediante la siembra manual (JOIN ONLY), espere hasta que se cree el grupo de disponibilidad (AG) contenido.
En 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 en manual para crear un grupo de disponibilidad independiente y, posteriormente, agregar 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:
Quite el grupo de disponibilidad independiente.
Restaure las bases de datos contenidas
masterymsdben la réplica principal original del AG independiente.Elimine las bases de datos contenidas
masterymsdbdesde las réplicas secundarias.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)ySEEDING_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 al especificar REUSE_SYSTEM_DATABASES. 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 de respaldo.
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 contenido (AG) con el que desee interactuar.
Debe crear un agente de escucha para el grupo de disponibilidad contenido a fin de usar eficazmente un grupo de disponibilidad contenido. 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. Está sujeto al contenido (usuarios, permisos, trabajos, etc.) que se encuentran 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 la intención de lectura a una réplica secundaria (consulte Configuración del enrutamiento de solo lectura para un grupo de disponibilidad AlwaysOn) y quiere conectarse mediante un inicio de sesión que se crea en el grupo de disponibilidad independiente solo, hay otras consideraciones:
- Debe especificar una base de datos que sea parte de un grupo de disponibilidad contenido (AG) 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, AdventureWorks es una base de datos dentro del Grupo de Disponibilidad Contenido que tiene MyContainedListener, y MyUser es un usuario definido en el Grupo de Disponibilidad Contenido y no en ninguna de las instancias participantes.
"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"
Este ejemplo le conecta a una secundaria legible que forma parte de la configuración de ReadOnly Routing y está dentro del contexto del AG.
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
masterymsdbson[contained AG]_mastery[contained AG]_msdb. Dentro del grupo de disponibilidad independiente, sus nombres sonmasterymsdb. - El identificador de base de datos para el grupo de disponibilidad independiente
masteres1desde 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.databasescuando 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 comandoUSE. - La configuración del servidor a través de
sp_configurese 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
Tenga en cuenta otros factores al usar determinadas funcionalidades con grupos de disponibilidad independientes. Actualmente no se admiten algunas características.
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. Esta afirmación es cierta tanto para las bases de datos de usuario contenidas en el AG como para las bases de datos del sistema contenidas en el AG.
Si usa una ubicación de copia de seguridad 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 ubicaciones diferentes.
Si usa un recurso de red para la ubicación de copia de seguridad, todos los servidores que hospedan réplicas necesitan acceso a ese recurso.
Habilitación de la creación o restauración de bases de datos en sesiones de grupo de disponibilidad independientes
Se aplica a: SQL Server 2025 (17.x) CU 1 y versiones posteriores.
En SQL Server 2025 (17.x) Actualización acumulativa (CU) 1, puede habilitar la restauración y creación de bases de datos directamente dentro de una sesión de grupo de disponibilidad contenida, a través del controlador de escucha de AG contenida. Esta mejora simplifica los flujos de trabajo para los usuarios asignados a los roles adecuados, lo que permite operaciones sin problemas en entornos de AG contenidos.
Solo los usuarios con el rol dbcreator pueden crear bases de datos en una sesión de AG contenida. Solo los usuarios con el rol db_owner o sysadmin pueden restaurar bases de datos.
En el siguiente ejemplo, se habilita la característica para su sesión usando la clave de contexto de sesión allow_cag_create_db en el procedimiento almacenado sp_set_session_contex. Para deshabilitarlo, establezca @value a 0.
EXECUTE sp_set_session_context
@key = N'allow_cag_create_db',
@value = 1;
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 SQL Server 2025 (17.x), puede configurar un grupo de disponibilidad distribuido entre dos grupos de disponibilidad contenidos. 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
Se aplica a: SQL Server 2022 (16.x) CU 18 y versiones posteriores.
En SQL Server 2022 (16.x) antes de la actualización acumulativa (CU) 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.
En SQL Server 2022 (16.x) CU 18 y versiones posteriores, 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.
Sugerencia
Debe usar la misma configuración del regulador de recursos para todas las instancias del motor de base de datos que hospedan réplicas de disponibilidad para garantizar un comportamiento coherente a medida que se producen las conmutaciones por error del grupo de disponibilidad.
Para obtener más información, consulte Regulador de recursos y Tutorial: Ejemplos de configuración del regulador de recursos y procedimientos recomendados.
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
Puede configurar el envío de registros si la base de datos de origen está en el grupo de disponibilidad contenida. Sin embargo, no se admite un destino de trasvase de registros dentro de un grupo de disponibilidad independiente. Además, debe modificar el trabajo de trasvase de registros después de configurar CDC.
Para configurar el trasvase de registros con un grupo de disponibilidad independiente, siga estos pasos:
- Conéctese al agente de escucha del grupo de disponibilidad independiente.
- Configure el trasvase de registros como lo haría normalmente.
- Después de configurar el trabajo de trasvase de registros, modifique el trabajo para conectarse al agente de escucha del grupo de disponibilidad contenido 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 master base de datos de la instancia a la base de datos independiente master , consulte Traslado de una base de datos protegida por TDE a otra instancia de SQL Server, centrándose principalmente en las partes en las que la DMK se transfiere del servidor antiguo a la nueva.
Nota
El cifrado de cualquier base de datos en una instancia de SQL Server también cifra la base de datos del tempdb sistema.
Paquetes SSIS y planes de mantenimiento
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.
Compatibilidad con DDL
En el procedimiento CREATE AVAILABILITY GROUP, existe una cláusula WITH con varias opciones:
<with_option_spec> ::=
CONTAINED [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ]
INDEPENDIENTE
Esta opción especifica que el AG que está creando es un AG contenido.
REUSE_SYSTEM_DATABASES
La REUSE_SYSTEM_DATABASES opción solo es válida para grupos de disponibilidad independientes. Especifica que el nuevo grupo de disponibilidad contenida debe reutilizar las bases de datos del sistema contenidas existentes de un grupo de disponibilidad contenida anterior con el mismo nombre. Por ejemplo, si tenía un grupo de disponibilidad independiente denominado MyContainedAGy quería 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 los nombres de base de datos del sistema. SQL Server los detecta automáticamente.
AUTOSEEDING_SYSTEM_DATABASES
Aplica a: SQL Server 2025 (17.x) y versiones posteriores.
Si desea usar su grupo de disponibilidad contenido como reenviador en un grupo de disponibilidad distribuido, debe usar la opción AUTOSEEDING_SYSTEM_DATABASES al crear su grupo de disponibilidad contenido. 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.
Compatibilidad de objetos del sistema con grupos de disponibilidad independientes
Dos vistas del sistema incluyen adiciones relacionadas con grupos de disponibilidad contenidos:
- La sys.dm_exec_sessions vista de administración dinámica incluye una
contained_availability_group_idcolumna. - La vista de catálogo sys.availability_groups incluye la columna
is_contained.