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).
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, 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.
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 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.
Multi-AZ con DBM, AG o la replicación por bloque son compatibles con una única réplica en espera.
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.
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.

En la siguiente tabla se compara la forma en que se replican los objetos del servidor en implementaciones multi-AZ de RDS para SQL Server mediante creación de reflejos de base de datos (DBM) o grupos de disponibilidad (AG) Always On frente a la replicación por bloques.

Comportamiento de replicación por tipo de objeto
Objeto	Creación de reflejos de base de datos/Grupos de disponibilidad Always On	Replicación por bloques
Inicios de sesión	Sí, lo replica Amazon RDS. La propiedad `DEFAULT_DATABASE` no está replicada. No utilice `DEFAULT_DATABASE` al crear o modificar inicios de sesión en instancias de DBM o grupos de disponibilidad Always On.	Sí, incluido `DEFAULT_DATABASE` (sin restricciones).
Usuarios y permisos de la base de datos	Sí, se replica mediante la replicación nativa de SQL Server (almacenada en las bases de datos de los usuarios).	Sí.
Roles de servidor definidos por el usuario	Grupos de disponibilidad Always On: Sí, replicado. DBM: No, no está replicado.	Sí.
Servidores vinculados	No: se almacena en la base de datos `master`, que está fuera de la zona de disponibilidad o reflejo. Cree servidores enlazados antes de habilitar multi-AZ o vuelva a crearlos manualmente tras la conmutación por error.	Sí, se replica todo el volumen, incluidas las bases de datos del sistema.
SQL Server Audit	Parcial: las especificaciones de auditoría de la base de datos (en las bases de datos de los usuarios) se replican. Las auditorías de servidor y las especificaciones de auditoría de servidor no se replican. Debe crearlas manualmente en la secundaria con el parámetro `AUDIT_GUID` para que coincidan con el principal.	Sí, todos los objetos de auditoría se replican por volumen.
`tempdb`Configuración de la	Opcional: habilite la sincronización con el siguiente procedimiento almacenado. `EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'TempDbFile';` Los objetos y datos temporales nunca se replican.	Sí, la configuración se replica por volumen.
Trabajos de agente SQL Server	Opcional: habilite la sincronización con el siguiente procedimiento almacenado. `EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob';` Solo se replican los pasos de trabajo de T-SQL en las categorías compatibles. Los tipos de pasos SSIS, SSRS, Replication, PowerShell y Database Mail no se replican.	Sí, todos los trabajos se replican por volumen.
CDC (captura de datos de cambio)	Parcial: los metadatos y las tablas de cambios de CDC (en las bases de datos de usuarios) están replicados. Los trabajos de captura y limpieza (en `msdb`) no se replican directamente. Amazon RDS los descarta y los vuelve a crear en el nuevo dispositivo principal tras la conmutación por error mediante parámetros registrados anteriormente. Se utiliza `rds_set_configuration` para preestablecer los parámetros de CDC en el secundario.	Sí, todos los objetos de CDC se replican por volumen.
Gobernador de recursos	Sí, lo replica Amazon RDS. Para comprobar la sincronización, ejecute la siguiente consulta. `SELECT * FROM msdb.dbo.rds_fn_server_object_last_sync_time();`	Sí.
Propietario de la base de datos	No, e la instancia secundaria, el propietario de la base de datos está establecido en `NT AUTHORITY\SYSTEM`. Tras la conmutación por error, use `msdb.dbo.rds_changedbowner_to_rdsa` para restablecer la propiedad.	Sí, se mantiene el propietario.
`msdb`Permisos de	No, RDS para SQL Server no replica los permisos de la base de datos `msdb` en la instancia secundaria. Debe volver a crearlos manualmente.	Sí, se replican por volumen.

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]   
```

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

Multi-AZ para RDS for SQL Server

Determinar la ubicación de la secundaria