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

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.

  • 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.

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]