Adición de implementaciones Multi-AZ a una instancia de base de datos de SQL Server Eliminación de Multi-AZ de una instancia de base de datos de SQL Server Limitaciones, notas y recomendaciones Determinar la ubicación de la secundaria Migración a AG Always On

Implementaciones Multi-AZ para Amazon RDS for Microsoft SQL Server

Las implementaciones Multi-AZ proporcionan unos niveles superiores de disponibilidad, durabilidad de los datos y tolerancia a errores para las instancias de base de datos. Si se produce una interrupción del servicio no planificada o un mantenimiento planificado de la base de datos, Amazon RDS conmuta automáticamente a la instancia de base de datos secundaria. Esta funcionalidad permite que las operaciones de base de datos se reanuden rápidamente sin intervención manual. Las instancias principal y en espera usan el mismo punto de enlace, cuya dirección de red física cambia a la réplica secundaria como parte del proceso de conmutación por error. No tiene que volver a configurar su aplicación cuando se produzca una conmutación por error.

Amazon RDS admite implementaciones Multi-AZ para instancias de base de datos en las que se ejecuta Microsoft SQL Server mediante el uso de la creación de reflejos de bases de datos (DBM) de SQL Server o los grupos de disponibilidad (AG) AlwaysOn. Amazon RDS monitorea y mantiene el estado de la implementación Multi-AZ. Si se produce algún problema, RDS reparará automáticamente las instancias de base de datos con problemas, restablecerá la sincronización e iniciará las conmutaciones por error. La conmutación por error solo ocurre si las instancias en espera y principal están totalmente sincronizadas. No es necesario que administre nada.

Al configurar Multi-AZ en SQL Server, RDS configura automáticamente todas las bases de datos en la instancia para utilizar DBM o AG. Amazon RDS se encarga de la instancia principal, el testigo de creación de reflejo y la instancia de base de datos secundaria en su nombre. Debido a que la configuración es automática, RDS selecciona DBM o AG siempre en función de la versión de SQL Server que implemente.

Amazon RDS admite Multi-AZ con los AG Always On para las siguientes versiones y ediciones de SQL Server:

SQL Server 2022
- Standard Edition
- Enterprise Edition
SQL Server 2019:
- Standard Edition 15.00.4073.23 y posteriores
- Enterprise Edition
SQL Server 2017:
- Standard Edition 14.00.3401.7 y posteriores
- Enterprise Edition 14.00.3049.1 y posteriores
SQL Server 2016: Enterprise Edition 13.00.5216.0 o posterior

Amazon RDS es compatible con Multi-AZ con DBM para las siguientes versiones y ediciones de SQL Server, salvo para las versiones mencionadas anteriormente:

SQL Server 2019: Standard Edition 15.00.4043.16
SQL Server 2017: Standard y Enterprise Editions
SQL Server 2016: Standard y Enterprise Editions
SQL Server 2014: Standard y Enterprise Editions

Puede utilizar la siguiente consulta SQL para determinar si su instancia de base de datos de SQL Server es Single-AZ, Multi-AZ con DBM o Multi-AZ con AG Always On.


SELECT CASE WHEN dm.mirroring_state_desc IS NOT NULL THEN 'Multi-AZ (Mirroring)'
    WHEN dhdrs.group_database_id IS NOT NULL THEN 'Multi-AZ (AlwaysOn)'
    ELSE 'Single-AZ'
    END 'high_availability'
FROM sys.databases sd
LEFT JOIN sys.database_mirroring dm ON sd.database_id = dm.database_id
LEFT JOIN sys.dm_hadr_database_replica_states dhdrs ON sd.database_id = dhdrs.database_id AND dhdrs.is_local = 1
WHERE DB_NAME(sd.database_id) = 'rdsadmin';

La salida se parece a la siguiente:


high_availability
Multi-AZ (AlwaysOn)

Adición de implementaciones Multi-AZ a una instancia de base de datos de Microsoft SQL Server

Al crear una nueva instancia de base de datos de SQL Server utilizando la AWS Management Console, puede añadir Multi-AZ con creación de reflejos (DBM) o AG Always On. Para ello, elija Yes (Mirroring / Always On) (Sí [Creación de reflejos / Always On]) en la Multi-AZ Deployment (Implementación Multi-AZ) . Para obtener más información, consulte Creación de una instancia de base de datos de Amazon RDS.

Cuando modifique una instancia de base de datos de SQL Server existente con la consola, puede añadir Multi-AZ con DBM o AG al seleccionar Yes (Mirroring/Always On) (Sí [Replicación/Siempre activada]) en Multi-AZ Deployment (Implementación multi-AZ) en la página Modify DB Instance (Modificar instancia de base de datos). Para obtener más información, consulte Modificación de una instancia de base de datos de Amazon RDS.

nota

Si la instancia de base de datos ejecuta la creación de reflejos de base de datos (DBM) —no grupos de disponibilidad (AG) Always On— deshabilite la optimización en memoria antes de agregar Multi-AZ. Deshabilite la optimización en memoria con DBM antes de agregar Multi-AZ si su instancia de base de datos ejecuta SQL Server 2014, 2016 o 2017 Enterprise Edition y está habilitada la optimización en memoria.

Si la instancia de base de datos está ejecutando AG, este paso no es necesario.

Eliminación de Multi-AZ de una instancia de base de datos de Microsoft SQL Server

Al modificar una instancia de base de datos de SQL Server existente mediante AWS Management Console, se pueden eliminar implementaciones Multi-AZ con DBM o AG. Para hacerlo, elija No (Mirroring / Always On) (No [Replicación/Siempre activada) en Multi-AZ deployment (Implementación Multi-AZ) en la página Modify DB Instance (Modificar instancia de base de datos). Para obtener más información, consulte Modificación de una instancia de base de datos de Amazon RDS.

Limitaciones, notas y recomendaciones relativas a las implementaciones Multi-AZ de Microsoft SQL Server

Las siguientes limitaciones se aplican al trabajar con implementaciones Multi-AZ en RDS para instancias de base de datos de SQL Server:

No se admite Multi-AZ entre regiones.
No se puede detener una instancia de base de datos de Amazon RDS para SQL Server que esté en una implementación Multi-AZ.
No puede configurar la instancia de base de datos secundaria de modo que acepte la actividad de lectura de bases de datos.
Multi-AZ con grupos de disponibilidad (AG) Always On es compatible con la optimización en memoria.
Multi-AZ con grupos de disponibilidad (AG) Always On no admite la autenticación Kerberos para el agente de escucha del grupo de disponibilidad. Esto se debe a que el agente de escucha no tiene nombre principal de servicio (SPN).
No se puede cambiar el nombre de una base de datos de una instancia de base de datos de SQL Server que esté en una implementación Multi-AZ de SQL Server. Si tiene que cambiar el nombre de una base de datos en una instancia de este tipo, desactive primero la implementación Multi-AZ para la instancia de base de datos, cambie el nombre de la base de datos. Por último, vuelva a activar la implementación Multi-AZ en la instancia de base de datos.
Solo puede restaurar las instancias de base de datos Multi-AZ a las que se haya realizado una copia de seguridad usando el modelo de recuperación completa.
Las implementaciones multi-AZ tienen un límite de 10 000 trabajos del Agente SQL Server.

Si se necesitan límites más altos, solicite un aumento; para ello, contáctese con AWS Support. Abra la página del centro de AWS Support, inicie sesión si es preciso y, luego, elija Create Case (Crear caso). Seleccione Service limit increase (Aumento del límite de servicio). Rellene y envíe el formulario.

En las siguientes notas se describe el trabajo con implementaciones Multi-AZ en RDS para instancias de base de datos de SQL Server:

Amazon RDS expone el punto de enlace del agente de escucha del grupo de disponibilidad de los AG Always On. El punto de conexión está visible en la consola, y lo devuelve la operación de API DescribeDBInstances como entrada en el campo de puntos de conexión.
Amazon RDS es compatible con las conmutaciones por error multisubred de grupos de disponibilidad.
Para usar las implementaciones Multi-AZ con una instancia de base de datos de SQL Server en una nube privada virtual (VPC), debe crear primero un grupo de subredes de base de datos que tenga subredes en al menos dos zonas de disponibilidad diferentes. A continuación, asigne el grupo de subredes de la réplica principal de la instancia de base de datos de SQL Server.
Cuando una instancia de base de datos se modifica para convertirla en una implementación Multi-AZ, durante la modificación tiene el estado modifying (modificando). Amazon RDS crea el modo de espera y realiza una copia de seguridad de la instancia de base de datos primaria. Una vez que el proceso se haya completado, el estado de la instancia de base de datos principal pasará a ser available (disponible).
Las implementaciones Multi-AZ mantienen todas las bases de datos en el mismo nodo. Si una base de datos del anfitrión principal experimenta una conmutación por error, todas las bases de datos de SQL Server conmutarán por error como una unidad atómica al anfitrión en espera. Amazon RDS aprovisiona un nuevo anfitrión en buen estado y reemplaza al anfitrión que no está en buen estado.
Las implementaciones Multi-AZ con DBM o AG son compatibles con una única réplica en espera.
Los usuarios, los inicios de sesión y los permisos se replican automáticamente en la secundaria. No tiene que volver a crearlos. Los roles de servidor definidos por los usuarios solo se replican en instancias de base de datos que utilizan Always On AGs para implementaciones multi-AZ.
En las implementaciones multi-AZ, RDS para SQL Server crea inicios de sesión de SQL Server para permitir grupos de disponibilidad (AG) Always On o la creación de reflejos de bases de datos. RDS crea inicios de sesión con el siguiente patrón: db_<dbiResourceId>_node1_login, db_<dbiResourceId>_node2_login y db_<dbiResourceId>_witness_login.
RDS para SQL Server crea un inicio de sesión de SQL Server para permitir el acceso a las réplicas de lectura. RDS crea inicios de sesión con el siguiente patrón: db_<readreplica_dbiResourceId>_node_login.
En las implementaciones Multi-AZ, los trabajos de SQL Server Agent se replican desde el host principal al host secundario cuando la función de replicación de trabajos está activada. Para obtener más información, consulte Activación de la replicación de trabajos del agente de SQL Server.
Pueden producirse latencias elevadas comparadas con una implementación de instancia de base de datos estándar (en una única zona de disponibilidad) debido a la replicación de datos síncrona.
Los tiempos de conmutación por error se ven afectados por el tiempo necesario para completar el proceso de recuperación. Las transacciones grandes aumentan el tiempo de conmutación por error.
En las implementaciones Multi-AZ de SQL Server, el reinicio con conmutación por error reinicia sólo la instancia de base de datos principal. Después de la conmutación por error, la instancia de base de datos principal se convierte en la nueva instancia de base de datos secundaria. Puede que no se actualicen los parámetros para instancias Multi-AZ. Para el reinicio sin conmutación por error, las instancias de base de datos primaria y secundaria se reinician y los parámetros se actualizan después del reinicio. Si la instancia de base de datos no responde, se recomienda reiniciar sin conmutación por error.

Las siguientes recomendaciones están indicadas al trabajar con implementaciones Multi-AZ en RDS para instancias de base de datos de Microsoft SQL Server:

Para conocer las bases de datos utilizadas en el proceso de producción y preproducción, le recomendamos las siguientes opciones:
- Implementaciones Multi-AZ para alta disponibilidad
- "IOPS provisionadas" para un rendimiento rápido y coherente
- "Optimizada para memoria" en lugar de "Uso general"
No se puede seleccionar la zona de disponibilidad (AZ) para la instancia secundaria, así que al implementar los hosts de las aplicaciones, tenga esto en cuenta. Su base de datos podría experimentar una conmutación por error a otra zona de disponibilidad y los hosts de las aplicaciones podrían no estar en la misma zona de disponibilidad que la base de datos. Por este motivo, le recomendamos equilibrar los hosts de aplicaciones entre todas las zonas de disponibilidad de la región de AWS dada.
Para obtener el máximo rendimiento, no habilite la creación de reflejos ni AG Always On durante una operación grande de carga de datos. Si desea que la carga de datos sea lo más rápida posible, termínela antes de convertir la instancia de base de datos en una implementación Multi-AZ.

Las aplicaciones que obtienen acceso a las bases de datos de SQL Server deben tener un tratamiento de las excepciones que detecte los errores de conexión. En la siguiente muestra de código, un bloque try/catch detecta un error de comunicación. En este ejemplo, la instrucción break sale del bucle while si la conexión es correcta, pero vuelve a intentarlo hasta 10 veces si se produce una excepción.


int RetryMaxAttempts = 10;
int RetryIntervalPeriodInSeconds = 1;
int iRetryCount = 0;
while (iRetryCount < RetryMaxAttempts)
{
   using (SqlConnection connection = new SqlConnection(DatabaseConnString))
   {
      using (SqlCommand command = connection.CreateCommand())
      {
         command.CommandText = "INSERT INTO SOME_TABLE VALUES ('SomeValue');";
         try
         {
            connection.Open();
            command.ExecuteNonQuery();
            break;
         }
         catch (Exception ex) 
         {
            Logger(ex.Message);
            iRetryCount++;
         }
         finally {
            connection.Close();
         }
      }
   }
   Thread.Sleep(RetryIntervalPeriodInSeconds * 1000);
}

No use el comando Set Partner Off cuando se trabaja con instancias Multi-AZ. Por ejemplo, no haga lo siguiente.
```
--Don't do this
ALTER DATABASE db1 SET PARTNER off   
```
No establezca el modo de recuperación en simple. Por ejemplo, no haga lo siguiente.
```
--Don't do this
ALTER DATABASE db1 SET RECOVERY simple   
```
No use el parámetro DEFAULT_DATABASE cuando cree nuevos inicios de sesión en instancias de base de datos Multi-AZ, ya que esta configuración no se puede aplicar en el reflejo en espera. Por ejemplo, no haga lo siguiente.
```
--Don't do this
CREATE LOGIN [test_dba] WITH PASSWORD=foo, DEFAULT_DATABASE=[db2]   
```
Tampoco haga lo siguiente.
```
--Don't do this
ALTER LOGIN [test_dba] SET DEFAULT_DATABASE=[db3]   
```

Determinar la ubicación de la secundaria

Puede determinar la ubicación de la réplica secundaria usando la AWS Management Console. Debe conocer la ubicación de la secundaria si va a configurar la instancia de base de datos principal en una VPC.

También puede ver la zona de disponibilidad de la secundaria usando el comando AWS CLI de la describe-db-instances o la operación DescribeDBInstances de la API de RDS. La salida muestra la zona de disponibilidad secundaria en la que se encuentra el reflejo en espera.

Migración desde la creación de reflejos de base de datos a grupos de disponibilidad Always On

En la versión 14.00.3049.1 de Microsoft SQL Server Enterprise Edition, los grupos de disponibilidad (AG) Always On están habilitados de forma predeterminada.

Para migrar desde la creación de reflejos de base de datos (DBM) a AG, compruebe su versión antes. Si está utilizando una instancia de base de datos con una versión anterior a Enterprise Edition 13.00.5216.0, modifique la instancia para parchearla a la versión 13.00.5216.0 o posterior. Si está utilizando una instancia de base de datos con una versión anterior a Enterprise Edition 14.00.3049.1, modifique la instancia para parchearla a la versión 14.00.3049.1 o posterior.

Si desea actualizar una instancia de base de datos de la que se ha creado el reflejo para usar AG, ejecute la actualización primero, modifique la instancia para eliminar Multi-AZ y, a continuación, vuelva a modificarla para añadir Multi-AZ. Esto convierte su instancia para usar AG Always On.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Uso de réplicas de lectura de SQL Server

Características adicionales para SQL Server