# Implementaciones Multi-AZ para Amazon RDS for Microsoft SQL Server
<a name="USER_SQLServerMultiAZ"></a>

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 Microsoft SQL Server mediante el uso de la creación de reflejos de bases de datos (DBM) de SQL Server, los grupos de disponibilidad (AG) Always On o la replicación por bloque. 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, AG o la replicación por bloque. Amazon RDS se encarga de la instancia principal, el testigo y la instancia de base de datos secundaria en su nombre cuando configure DBM o los AG. Para la replicación por bloque, RDS se encarga de las instancias de base de datos principal y secundaria. Debido a que la configuración es automática, RDS selecciona DBM, Always On AG o replicación por bloque 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 

Amazon RDS admite multi-AZ con replicación por bloque para SQL Server 2022 Web Edition 16.00.4215.2 y versiones superiores.

**nota**  
Solo las instancias de base de datos nuevas creadas con 16.00.4215.2 o superior admiten implementaciones multi-AZ con replicación por bloque. Se aplican las siguientes restricciones a las instancias existentes de SQL Server 2022 Web Edition:  
En el caso de las instancias existentes de la versión 16.00.4215.2, debe restaurar una instantánea en una nueva instancia con la misma versión secundaria o superior para permitir la replicación por bloque.
Las instancias SQL Server 2022 Web con una versión secundaria anterior se pueden actualizar a la versión secundaria 16.00.4215.2 o superior para permitir la replicación por bloque.

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. Esta consulta no se aplica a las implementaciones multi-AZ en SQL Server Web Edition.

```
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
<a name="USER_SQLServerMultiAZ.Adding"></a>

Al crear una nueva instancia de base de datos de SQL Server con la Consola de administración de AWS, puede agregar multi-AZ con creación de reflejos de base de datos (DBM), Always On AG o replicación por bloque. Para ello, elija **Sí (Creación de reflejos/Always On/Replicación por bloque)** en la **Implementación multi-AZ**. Para obtener más información, consulte [Creación de una instancia de base de datos de Amazon RDS](USER_CreateDBInstance.md).

Cuando modifique una instancia de base de datos de SQL Server existente con la consola, puede agregar multi-AZ con DBM, AG o replicación por bloque al elegir **Sí (Creación de reflejos/Always On/Replicación por bloque)** en **Implementación multi-AZ** en la página **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](Overview.DBInstance.Modifying.md).

**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 2016 o 2017 Enterprise Edition y está habilitada la optimización en memoria.   
Si la instancia de base de datos está ejecutando AG o replicación por bloque para SQL Server Web Editions, este paso no es necesario. 

## Eliminación de Multi-AZ de una instancia de base de datos de Microsoft SQL Server
<a name="USER_SQLServerMultiAZ.Removing"></a>

Al modificar una instancia de base de datos de SQL Server existente mediante la Consola de administración de AWS, se puede eliminar multi-AZ con DBM, AG o replicación por bloque. Para hacerlo, elija **No (Creación de reflejos/Always On/Replicación por bloque)** en **implementación multi-AZ** en la página **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](Overview.DBInstance.Modifying.md).

# Limitaciones, notas y recomendaciones relativas a las implementaciones Multi-AZ de Microsoft SQL Server
<a name="USER_SQLServerMultiAZ.Recommendations"></a>

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).
+ Multi-AZ con replicación por bloque solo es compatible actualmente para las instancias de SQL Server Web Edition.
+ 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 Soporte. Abra la página del [centro de AWS Support](https://console.aws.amazon.com/support/home#/), 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.
+ No puede tener una base de datos sin conexión en una instancia de base de datos de SQL Server que se encuentre en una implementación Multi-AZ de SQL Server.
+ RDS para SQL Server no replica los permisos de la base de datos MSDB en la instancia secundaria. Si necesita estos permisos en la instancia secundaria, debe recrearlos manualmente.
+ Las métricas de volumen no están disponibles para el host secundario de la instancia mediante la replicación por bloque.

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](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover) 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](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover).
+ 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.
+ Multi-AZ con DBM, AG o la replicación por bloque 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 AG o replicación por bloque 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](Appendix.SQLServer.CommonDBATasks.Agent.md#SQLServerAgent.Replicate).
+ 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 de base de datos, Always On AG o la replicación por bloque 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 mediante DBM o AG. Este comando no se admite en las instancias que utilizan la replicación por bloque. 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, a menos que use la replicación por bloque para alta disponibilidad, 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] WITH DEFAULT_DATABASE=[db3]
  ```

# Determinar la ubicación de la secundaria
<a name="USER_SQLServerMultiAZ.Location"></a>

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

![\[AZ secundaria\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/SQLSvr-MultiAZ.png)


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
<a name="USER_SQLServerMultiAZ.Migration"></a>

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.