Comparteix a través de

¿Qué es un grupo de disponibilidad independiente?

  • Article

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 del sistema independientes y especializadas dentro del AG.

En este artículo se detallan las similitudes, las diferencias y las funcionalidades de los AG 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 asíncrono.

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 AG independientes 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 del grupo de disponibilidad independiente 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 ejecute y otras opciones de configuración que afecten 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.

Diferencias

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

Bases de datos del sistema independientes

Cada AG 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 AG independiente, cuando el AG independiente conmuta por error a otra instancia, conectándose al AG independiente, todavía se verán los trabajos de agente, y se podrá autenticar con el inicio de sesión creado en el AG independiente.

Importante

Los AG independientes 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 impida que una conexión a un AG independiente pueda acceder a bases de datos fuera de ese AG.

Las bases de datos del sistema de un AG independiente recién creado no se copian desde 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 AG independiente se copian en el AG independiente master. De este modo, el administrador puede iniciar sesión en el AG 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 de usuario se ha unido a un AG 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 de administrador del sistema (sysadmin) de la instancia primaria se copian en la base de datos master específica del nuevo AG.

Restauración de una base de datos del sistema independiente

Se puede restaurar una base de datos del sistema independiente de una de estas dos maneras diferentes.

  • Restauración de una base de datos independiente mediante una réplica secundaria:

    1. Restaura las bases de datos master y msdb independientes en una instancia de servidor que hospede la réplica secundaria mediante RESTORE WITH NORECOVERY para cada operación de restauración. Para obtener más información, consulta Preparación de una base de datos secundaria para un grupo de disponibilidad Always On.

    2. Une cada base de datos independiente al grupo de disponibilidad. Para más información, consulta Unión de una base de datos secundaria con un grupo de disponibilidad Always On.

  • Restauración de una base de datos independiente excluyendo el grupo de AG independiente:

    1. Excluye el AG contenido.

    2. Restaura las bases de datos master y msdb independientes en cada una de las instancias que participan en el AG independiente.

    3. Vuelve a crear el AG independiente con los nodos y el nombre originales mediante la sintaxis WITH (CONTAINED, REUSE_SYSTEM_DATABASES).

Conexión (entorno independiente)

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

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

Donde MyContainedDatabase es una base de datos dentro del AG independiente con el que se quiere interactuar.

Esto significa que se debe crear un agente de escucha para que el AG independiente use eficazmente un AG independiente. Si se establece conexión con una de las instancias que hospedan el AG independiente en lugar de directamente al AG independiente a través del agente de escucha, se estará en el entorno de la instancia y no en el AG 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 AG independiente, hay que conectarse al agente de escucha del AG independiente (MyContainedAG_Listener, por ejemplo) en su lugar. Cuando se establece conexión con la instancia a través del agente de escucha del AG independiente, y se interactúa con master, realmente se redirige al usuario a la base de datos independiente master (por ejemplo, MyContainedAG_master).

Enrutamiento de solo lectura y grupos de disponibilidad independientes

Si se ha configurado el enrutamiento de solo lectura para redirigir las conexiones con intención de lectura a una réplica secundaria (consulta Configuración del enrutamiento de solo lectura para un grupo de disponibilidad de Always On) y se quiere establecer conexión mediante un inicio de sesión creado solo en el grupo de disponibilidad independiente, hay algunas consideraciones adicionales:

  • Se debe especificar una base de datos que forme parte del AG 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 AG independiente.

Por ejemplo, en la siguiente cadena de conexión, donde AdventureWorks es una base de datos dentro del AG independiente que tiene MyContainedListener, y donde MyUser es un usuario definido en el AG independiente y 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 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 AG independiente.

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

  • Cuando se establece conexión con un AG independiente, los usuarios solo verán las bases de datos en el AG independiente, además de tempdb.
  • En el nivel de instancia, los nombres de los AG independientes master y msdb son [contained AG]_master y [contained AG]_msdb. Dentro del AG independiente, sus nombres son master y msdb.
  • El id. de base de datos para el AG independiente master es 1 desde dentro del AG independiente, pero algo más cuando se establece conexión con la instancia.
  • Aunque los usuarios no verán las bases de datos fuera del AG independiente en sys.databases cuando se conecten mediante un AG independiente, podrán 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 AG independiente, pero solo se puede escribir desde el nivel de instancia.
  • Desde las conexiones del AG independiente, el administrador del sistema (sysadmin) puede realizar operaciones de nivel de instancia, como apagar SQL Server.
  • La mayoría de las operaciones de nivel de base de datos, de punto de conexión o de AG solo se pueden realizar desde conexiones de instancia, no desde conexiones de AG independientes.

Interacciones con otras características

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

No compatible

Actualmente, las siguientes características de SQL Server no se admiten con un AG independiente:

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

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 AG independiente.

Para usar la captura de datos modificados con un AG independiente, hay que conectarse al agente de escucha del AG 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 AG independiente. Sin embargo, no se admite un destino de trasvase de registros dentro de un AG independiente. Además, hay un paso adicional para modificar el trabajo de trasvase de registros después de configurar CDC.

Para configurar el trasvase de registros con un AG independiente, hay que seguir estos pasos:

  1. Conectarse al agente de escucha del AG independiente.
  2. Configure el trasvase de registros como lo haría normalmente.
  3. Una vez configurado el trabajo de trasvase de registros, modificarlo para conectarse al agente de escucha del AG 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, hay que instalar manualmente la clave maestra de base de datos (DMK) en la base de datos independiente master dentro del AG 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 AG independiente, SQL Server comprobará ambas bases de datos master en busca de la clave maestra de base de datos (DMK), la base de datos master de la instancia y la base de datos master independiente dentro del AG 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 independientes.

Cambios de DDL

Los únicos cambios de DDL están en el flujo de trabajo CREATE AVAILABILITY GROUP. Hay dos nuevas cláusulas WITH:

<with_option_spec> ::=
CONTAINED |
REUSE_SYSTEM_DATABASES

CONTAINED

Esto especifica que el AG que se va a crear debe ser un AG independiente.

REUSE_SYSTEM_DATABASES

Esta opción solo es válida para los AG independientes y especifica que el AG recién creado debería reutilizar las bases de datos del sistema independientes existentes para un AG independiente anterior con el mismo nombre. Por ejemplo, si se tuviera un AG independiente con el nombre MyContainedAG, y se quisiera excluirlo y volver a crearlo, se podría usar esta opción para reutilizar el contenido de las bases de datos del sistema independientes originales.

Cambios de DMV

Hay dos adiciones a las DMV relacionadas con los AG 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