Mantenimiento de un clúster de base de datos de Amazon Aurora

Amazon RDS realiza tareas de mantenimiento periódicas en los recursos de Amazon RDS.

Temas

• Descripción general de las actualizaciones de mantenimiento de clústeres de base de datos

• Visualización de actualizaciones de mantenimiento pendientes

• Aplicación de actualizaciones a un clúster de base de datos

• La ventana de mantenimiento de Amazon RDS

• Ajuste de la ventana de mantenimiento preferida para un clúster de base de datos

• Actualizaciones de versiones secundarias automáticas para clústeres de base de datos de Aurora

• Selección de frecuencia de actualizaciones de mantenimiento de Aurora MySQL

Descripción general de las actualizaciones de mantenimiento de clústeres de base de datos

El mantenimiento suele implicar actualizaciones de los siguientes recursos de su clúster de base de datos:

• Hardware subyacente

• Sistema operativo (SO) subyacente

• Versión del motor de base de datos

Las actualizaciones del sistema operativo suelen deberse a motivos de seguridad. Se recomienda que las haga lo antes posible. Para obtener más información sobre las actualizaciones de sistemas operativos, consulte Aplicación de actualizaciones a un clúster de base de datos.

Recursos sin conexión durante las actualizaciones de mantenimiento

Algunos elementos de mantenimiento requieren que Amazon RDS desconecte su clúster de base de datos durante un breve plazo de tiempo. Entre los elementos de mantenimiento que requieren que un recurso esté desconectado están el sistema operativo necesario o la aplicación de parches a la base de datos. Los parches obligatorios que tienen que ver con la seguridad y la fiabilidad de la instancia son los únicos que se programan automáticamente. Estos parches se producen con poca frecuencia, normalmente una vez cada pocos meses. Rara vez se requiere más de una fracción de su período de mantenimiento.

Modificaciones diferidas de instancias de base de datos y clústeres de base de datos

Las modificaciones de instancias y clústeres de base de datos diferidas que haya decidido no aplicar inmediatamente se aplican durante el periodo de mantenimiento. Por ejemplo, puede elegir cambiar clases de instancia de base de datos o grupos de parámetros de clúster o base de datos durante el periodo de mantenimiento. Las modificaciones que especifique mediante la configuración de reinicio pendiente no se muestran en la lista Mantenimiento pendiente. Para obtener más información acerca de la modificación de un clúster de base de datos, consulte Modificación de un clúster de base de datos de Amazon Aurora.

Para ver las modificaciones pendientes para la siguiente ventana de mantenimiento, utilice el comando describe-db-clústers de la AWS CLI y marque el campo PendingModifiedValues.

Consistencia final de la API DescribependingMaintenanceActions

La API DescribePendingMaintenanceActions de Amazon RDS sigue un modelo de consistencia final. Esto significa que el resultado del comando DescribePendingMaintenanceActions puede que no sea visible inmediatamente para todos los comandos de RDS posteriores. Tenga esto en cuenta cuando utilice DescribePendingMaintenanceActions inmediatamente después de usar un comando de API anterior.

La consistencia final puede afectar a la forma en que ha administrado las actualizaciones de mantenimiento. Por ejemplo, si ejecuta el comando ApplyPendingMaintenanceActions para actualizar la versión del motor de base de datos de un clúster de base de datos, al final será visible en DescribePendingMaintenanceActions. En este escenario, DescribePendingMaintenanceActions podría indicar que la acción de mantenimiento no se aplicó a pesar de que sí se hizo.

Para administrar la consistencia final, puede hacer lo siguiente:

• Confirme el estado de el clúster de base de datos antes de ejecutar un comando para modificarlo. Ejecute el comando DescribePendingMaintenanceActions correspondiente mediante un algoritmo de retroceso exponencial para asegurarse de que dispone de tiempo suficiente para que el comando anterior se propague en el sistema. Para ello, ejecute el comando DescribePendingMaintenanceActions varias veces, empezando con un par de segundos de espera y aumentando gradualmente hasta cinco minutos.

• Agregue tiempo de espera entre los comandos siguientes, incluso si un comando DescribePendingMaintenanceActions devuelve una respuesta precisa. Aplique un algoritmo de retroceso exponencial comenzando con un par de segundos de tiempo de espera y aumente gradualmente hasta unos cinco minutos de tiempo de espera.

Visualización de actualizaciones de mantenimiento pendientes

Compruebe si hay disponible una actualización de mantenimiento para un clúster de base de datos, use la consola de RDS, la AWS CLI o la API de RDS. Si hay disponible una actualización, se indicará en la columna Maintenance (Mantenimiento) para el clúster de base de datos en la consola Amazon RDS, como se muestra a continuación.

Si no hay ninguna actualización de mantenimiento disponible para un clúster de base de datos, el valor de columna es none (ninguno).

Si una actualización de mantenimiento está disponible para un clúster, son posibles los siguientes valores de columna:

• required (obligatorio): la acción de mantenimiento se aplicará al recurso y no se podrá aplazar indefinidamente.

• available (disponible): la acción de mantenimiento está disponible, pero no se aplicará al recurso automáticamente. Puede aplicarla manualmente.

• next window (siguiente periodo): la acción de mantenimiento se aplicará al recurso durante el siguiente periodo de mantenimiento.

• In progress (en curso): la acción de mantenimiento está en proceso de aplicarse al recurso.

Si hay una actualización disponible, puede realizar una de las acciones:

• Si el valor de mantenimiento es next window (siguiente periodo), aplace los elementos de mantenimiento eligiendo defer upgrade (aplazar actualización) en Actions (Acciones). No puede aplazar una acción de mantenimiento si ya se ha iniciado.

• Aplicar inmediatamente los elementos de mantenimiento.

• Programar los elementos de mantenimiento para que se inicien en la siguiente ventana de mantenimiento.

• No realice ninguna acción.

Para realizar una acción, elija el clúster para mostrar sus detalles y, a continuación, elija Maintenance & backups (Mantenimiento y copias de seguridad). Aparecerán los elementos de mantenimiento pendientes.

El periodo de mantenimiento determina el momento en que comienzan las operaciones pendientes, pero no limita su tiempo de ejecución total. No existen garantías de que las operaciones de mantenimiento finalicen antes de que termine el periodo de mantenimiento, de modo que pueden continuar más allá de la hora de finalización establecida. Para obtener más información, consulte La ventana de mantenimiento de Amazon RDS.

Para obtener información acerca de actualizaciones de motores de Amazon Aurora e instrucciones para actualizarlos y aplicarles parches, consulte Actualizaciones del motor de base de datos de Amazon Aurora MySQL y Actualizaciones del motor de base de datos de Amazon Aurora PostgreSQL.

Para ver si hay disponible una actualización de mantenimiento para un clúster de base de datos, puede ejecutar el comando describe-pending-maintenance-actions de la AWS CLI.

Para obtener información sobre la aplicación de actualizaciones de mantenimiento, consulte Aplicación de actualizaciones a un clúster de base de datos.

La ventana de mantenimiento de Amazon RDS

Los periodos de mantenimiento son un intervalo de tiempo semanal durante los que se aplican los cambios del sistema. Cada clúster de base de datos tiene un periodo de mantenimiento semanal. El periodo de mantenimiento es una oportunidad para controlar cuándo ocurrirán las modificaciones y los parches de software. Para obtener más información sobre el ajuste del periodo de mantenimiento, consulte Ajuste de la ventana de mantenimiento preferida para un clúster de base de datos.

RDS consume algunos de los recursos de su clúster de base de datos mientras se aplica el mantenimiento. Es posible que observe un efecto mínimo en el desempeño. Para una instancia de base de datos, en raras ocasiones puede ser necesaria una conmutación por error Multi-AZ para que se complete una actualización de mantenimiento.

Si hay un evento de mantenimiento programado para una semana determinada, se iniciará durante la ventana de mantenimiento que identifique. La mayoría de los eventos de mantenimiento también se completan durante la ventana de mantenimiento de 30 minutos, aunque otros eventos de mantenimiento pueden tardar más de 30 minutos en completarse. El periodo de mantenimiento se detiene cuando se detiene el clúster de la base de datos.

La ventana de mantenimiento de 30 minutos se selecciona al azar dentro de un bloque de 8 horas por región. Si no especifica una ventana de mantenimiento al crear un clúster de base de datos, RDS asigna una ventana de mantenimiento de 30 minutos un día de la semana seleccionado al azar.

A continuación, puede encontrar los bloques de horas de cada región desde los que se asignan las ventanas predeterminadas de mantenimiento.

Nombre de la región	Región	Bloque de tiempo
Este de EE. UU. (Ohio)	us-east-2	03:00 — 11:00 UTC
Este de EE. UU. (Norte de Virginia)	us-east-1	03:00–11:00 UTC
Oeste de EE. UU. (Norte de California)	us-west-1	06:00 — 14:00 UTC
Oeste de EE. UU. (Oregón)	us-west-2	06:00–14:00 UTC
África (Ciudad del Cabo)	af-south-1	03:00–11:00 UTC
Asia-Pacífico (Hong Kong)	ap-east-1	06:00–14:00 UTC
Asia-Pacífico (Hyderabad)	ap-south-2	06:30 – 14:30 UTC
Asia-Pacífico (Yakarta)	ap-southeast-3	08:00 a 16:00 h UTC
Asia-Pacífico (Melbourne)	ap-southeast-4	11:00–19:00 UTC
Asia Pacífico (Bombay)	ap-south-1	06:00–14:00 UTC
Asia Pacific (Osaka)	ap-northeast-3	22:00 — 23:59 UTC
Asia Pacific (Seoul)	ap-northeast-2	13:00 — 21:00 UTC
Asia-Pacífico (Singapur)	ap-southeast-1	14:00 — 22:00 UTC
Asia Pacífico (Sídney)	ap-southeast-2	12:00 — 20:00 UTC
Asia Pacífico (Tokio)	ap-northeast-1	13:00 — 21:00 UTC
Canadá (centro)	ca-central-1	03:00 — 11:00 UTC
Oeste de Canadá (Calgary)	ca-west-1	18:00 — 02:00 UTC
China (Pekín)	cn-north-1	06:00–14:00 UTC
China (Ningxia)	cn-northwest-1	06:00–14:00 UTC
Europe (Fráncfort)	eu-central-1	21:00 — 05:00 UTC
Europe (Irlanda)	eu-west-1	22:00 — 06:00 UTC
Europe (Londres)	eu-west-2	22:00 — 06:00 UTC
Europa (Milán)	eu-south-1	02:00 — 10:00 UTC
Europa (París)	eu-west-3	23:59–07:29 UTC
Europa (España)	eu-south-2	02:00 — 10:00 UTC
Europa (Estocolmo)	eu-north-1	23:00 — 07:00 UTC
Europa (Zúrich)	eu-central-2	02:00 — 10:00 UTC
Israel (Tel Aviv)	il-central-1	03:00 — 11:00 UTC
Medio Oriente (Baréin)	me-south-1	06:00–14:00 UTC
Medio Oriente (EAU)	me-central-1	05:00 a 13:00 h UTC
América del Sur (São Paulo)	sa-east-1	00:00–08:00 UTC
AWS GovCloud (EE. UU. Este)	us-gov-east-1	17:00 — 01:00 UTC
AWS GovCloud (Oeste de EE. UU.)	us-gov-west-1	06:00–14:00 UTC

Actualizaciones de versiones secundarias automáticas para clústeres de base de datos de Aurora

La configuración de Actualización automática de la versión secundaria especifica si Aurora aplica automáticamente las actualizaciones al clúster de base de datos. Estas actualizaciones incluyen nuevas versiones secundarias con características adicionales y revisiones que contienen correcciones de errores.

Esta función se activa de forma predeterminada. Para cada clúster de base de datos nuevo, elija el valor adecuado para esta configuración. Este valor se basa en su importancia, duración prevista y la cantidad de pruebas de verificación que realice después de cada actualización.

Para obtener instrucciones sobre cómo activar o desactivar la configuración de Actualización automática de versiones secundarias, consulte lo siguiente:

• Activación de las actualizaciones de versiones secundarias automáticas para un clúster de base de datos de Aurora

• Activación de las actualizaciones de versiones secundarias automáticas para instancias de base de datos individuales en un clúster de base de datos de Aurora

importante

Recomendamos encarecidamente que, para los clústeres de bases de datos nuevos y existentes, aplique esta configuración al clúster de base de datos y no a las instancias de base de datos del clúster de forma individual. Si alguna instancia de base de datos del clúster tiene esta configuración desactivada, el clúster de base de datos no se actualiza automáticamente.

La siguiente tabla muestra cómo funciona la configuración de Actualización automática de versiones secundarias cuando se aplica a los niveles de clúster e instancia.

Acción	Configuración del clúster	Configuraciones de la instancia	¿El clúster se ha actualizado automáticamente?
Se establece en True en el clúster de base de datos.	True	True para todas las instancias nuevas y existentes	Sí
Se establece en False en el clúster de base de datos.	False	False para todas las instancias nuevas y existentes	No
Se ha establecido previamente en True en el clúster de base de datos. Lo ha establecido en False en al menos una instancia de base de datos.	Cambia a False	False para una o varias instancias	No
Se ha establecido previamente en False en el clúster de base de datos. Lo ha establecido en True en al menos una instancia de base de datos, pero no en todas las instancias.	False	True para una o más instancias, pero no para todas las instancias	No
Se ha establecido previamente en False en el clúster de base de datos. Lo ha establecido en True en todas las instancias de base de datos.	Cambia a True	True para todas las instancias	Sí

Las actualizaciones automáticas de versiones secundarias se comunican de antemano a través de un evento de clúster de base de datos de Amazon RDS con una categoría maintenance e ID de RDS-EVENT-0156. Para obtener más información, consulte Categorías y mensajes de eventos de Amazon RDS para Aurora.

La actualización automática se produce durante el período de mantenimiento. Si las instancias de base de datos individuales del clúster de base de datos tienen períodos de mantenimiento diferentes a las de la ventana de mantenimiento del clúster, la ventana de mantenimiento del clúster tiene prioridad.

Para obtener más información acerca de las actualizaciones de motor de Aurora PostgreSQL, consulte Actualizaciones del motor de base de datos de Amazon Aurora PostgreSQL.

Para obtener más información acerca de la configuración de Auto minor version upgrade (Actualización automática de la versión secundaria) para Aurora MySQL, consulte Activación de actualizaciones automáticas entre versiones secundarias de Aurora MySQL. Para obtener más información general acerca de las actualizaciones del motor de Aurora MySQL, consulte Actualizaciones del motor de base de datos de Amazon Aurora MySQL.

Activación de las actualizaciones de versiones secundarias automáticas para un clúster de base de datos de Aurora

Siga el procedimiento general de Modificación del clúster de base de datos con la consola, CLI y API.

Consola

En la página Modificar el clúster de base de datos, en la sección Mantenimiento, seleccione la casilla de verificación Habilitar actualización automática de versiones secundarias.

AWS CLI

Ejecute el comando de la AWS CLI modify-db-clúster. Especifique el nombre del clúster de base de datos para la opción --db-cluster-identifier y true para la opción --auto-minor-version-upgrade. Si lo desea, especifique la opción --apply-immediately para habilitar inmediatamente esta configuración para el clúster de base de datos.

API de RDS

Llame a la operación ModifyDBclúster de la API y especifique el nombre del clúster de base de datos para el parámetro DBClusterIdentifier y true para el parámetro AutoMinorVersionUpgrade. Como opción, defina el parámetro ApplyImmediately en true para activar inmediatamente esta configuración para el clúster de base de datos.

Activación de las actualizaciones de versiones secundarias automáticas para instancias de base de datos individuales en un clúster de base de datos de Aurora

Siga el procedimiento general de Modificación de una instancia de base de datos en un clúster de base de datos.

Consola

En la página Modificar la instancia de base de datos, en la sección Mantenimiento, seleccione la casilla de verificación Habilitar actualización automática de versiones secundarias.

AWS CLI

Ejecute el comando de la AWS CLI modify-db-instance. Especifique el nombre de la instancia de base de datos para la opción --db-instance-identifier y true para la opción --auto-minor-version-upgrade. Si lo desea, especifique la opción --apply-immediately para habilitar inmediatamente esta configuración para su instancia de base de datos. Ejecute un comando modify-db-instance independiente para cada instancia de base de datos del clúster.

API de RDS

Llame a la operación ModifyDBInstance de la API y especifique el nombre del clúster de base de datos para el parámetro DBInstanceIdentifier y true para el parámetro AutoMinorVersionUpgrade. Como opción, defina el parámetro ApplyImmediately en true para activar inmediatamente esta configuración para la instancia de base de datos. Llame a una acción ModifyDBInstance independiente para cada instancia de base de datos del clúster.

Puede utilizar un comando de la CLI como el siguiente para comprobar el estado de la configuración AutoMinorVersionUpgrade para todas las instancias de base de datos de los clústeres de Aurora MySQL.

aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

El resultado de este comando debería ser similar al siguiente:

[
  {
      "DBInstanceIdentifier": "db-writer-instance",
      "DBClusterIdentifier": "my-db-cluster-57",
      "AutoMinorVersionUpgrade": true
  },
  {
      "DBInstanceIdentifier": "db-reader-instance1",
      "DBClusterIdentifier": "my-db-cluster-57",
      "AutoMinorVersionUpgrade": false
  },
  {
      "DBInstanceIdentifier": "db-writer-instance2",
      "DBClusterIdentifier": "my-db-cluster-80",
      "AutoMinorVersionUpgrade": true
  },
... output omitted ...

En este ejemplo, Habilitar actualización automática de versiones secundarias está desactivado para el clúster de base de datos my-db-cluster-57, porque está desactivado para una de las instancias de base de datos del clúster.

Selección de frecuencia de actualizaciones de mantenimiento de Aurora MySQL

Puede controlar si las actualizaciones de Aurora MySQL ocurren con frecuencia o rara vez para cada clúster de base de datos. La mejor opción depende del uso de Aurora MySQL y de las prioridades de las aplicaciones que se ejecuten en Aurora. Para obtener información acerca de las versiones de estabilidad a largo plazo (LTS) de Aurora MySQL que requieren actualizaciones menos frecuentes, consulte Versiones de soporte a largo plazo (LTS) de Aurora MySQL.

Podría elegir actualizar un clúster de Aurora MySQL rara vez si se aplican algunas o todas las condiciones siguientes:

• El ciclo de prueba de su aplicación tarda mucho tiempo para cada actualización al motor de base de datos de Aurora MySQL.

• Tiene muchos clústeres de base de datos o muchas aplicaciones ejecutándose en la misma versión de Aurora MySQL. Prefiere actualizar todos sus clústeres de base de datos y aplicaciones asociadas al mismo tiempo.

• Se utilizan Aurora MySQL y RDS para MySQL. Prefiere mantener los clústeres de Autora MySQL y las instancias de base de datos de RDS àra MySQL compatibles con el mismo nivel de MySQL.

• Su aplicación de Aurora MySQL está en producción o bien es crítica para la empresa. No puede permitirse períodos de inactividad para actualizaciones fuera de los raros casos para parches críticos.

• Su aplicación de Aurora MySQL no está limitada por problemas de rendimiento o falta de características que se resuelven en versiones siguientes de Aurora MySQL.

Si los factores anteriores son aplicables a su caso, puede limitar el número de actualizaciones forzadas para un clúster de base de datos de Aurora MySQL. Lo hace eligiendo una versión de Aurora MySQL específica conocida como versión de «Soporte a largo plazo» (LTS) al crear o actualizar dicho clúster de base de datos. Al hacerlo se minimiza el número de ciclos de actualización, ciclos de prueba e interrupciones relacionadas con actualizaciones para dicho clúster de base de datos.

Podría elegir actualizar un clúster de Aurora MySQL frecuentemente si se aplican algunas o todas las condiciones siguientes:

• El ciclo de prueba de la aplicación es sencillo y breve.

• La aplicación sigue en la fase de desarrollo.

• El entorno de la base de datos usa diversas versiones de Aurora MySQL o Aurora MySQL y versiones de RDS para MySQL. Cada clúster de Aurora MySQL tiene su propio ciclo de actualización.

• Espera mejoras de características o rendimiento específico antes de aumentar el uso de Aurora MySQL.

Si los factores anteriores son aplicables a su situación, puede habilitar Aurora para aplicar actualizaciones importantes con mayor frecuencia. Para ello, actualice un clúster de base de datos de Aurora MySQL a una versión de Aurora MySQL de más reciente que la versión de LTS. Al hacerlo las últimas mejoras de rendimiento, correcciones de errores y características disponibles están disponibles para usted más rápidamente.