Mantenimiento en instancias de Cloud SQL

En esta página, se explica cómo se producen las actualizaciones de mantenimiento en las instancias de Cloud SQL y cómo se puede controlar el tiempo de estas actualizaciones. Para comenzar, consulta Busca y configura períodos de mantenimiento.

Descripción general

Como servicio administrado, Cloud SQL actualiza las instancias de forma automática para garantizar que el hardware, el sistema operativo y el motor de base de datos subyacentes sean confiables, tengan un buen rendimiento, sean seguros y estén actualizados. La mayoría de estas actualizaciones se realizan mientras la instancia de Cloud SQL está en funcionamiento. Sin embargo, algunas actualizaciones del sistema requieren que se realice una breve interrupción del servicio. Estas actualizaciones se denominan mantenimiento.

El mantenimiento actualiza el sistema operativo y el motor de base de datos. Debido a que estas actualizaciones requieren que la instancia se reinicie, generan cierto tiempo de inactividad. Las actualizaciones de mantenimiento ofrecen los siguientes beneficios:

  • Características de Cloud SQL. Para iniciar funciones nuevas, se actualiza el motor de base de datos y se instalan complementos nuevos en la base de datos.

  • Actualizaciones de versiones de bases de datos. El proveedor de software de base de datos que desarrolla PostgreSQL lanza versiones secundarias nuevas varias veces al año. Con cada versión nueva, se incluyen correcciones de errores, parches de seguridad, mejoras de rendimiento y características nuevas de la base de datos. Puedes encontrar la versión secundaria más reciente que admite Cloud SQL para PostgreSQL si revisas las notas de la versión o las versiones de bases de datos y políticas de versiones. Las instancias de Cloud SQL se actualizan a la versión más reciente de la base de datos poco después del lanzamiento para que te beneficies de ejecutar el software de base de datos más reciente.

  • Parches del sistema operativo. Supervisamos de forma continua las vulnerabilidades de seguridad recién identificadas en el sistema operativo. Después de la detección, aplicamos un parche al sistema operativo para protegerte de los riesgos nuevos.

Impacto en el mantenimiento

Durante un evento de mantenimiento, una instancia de Cloud SQL para PostgreSQL pierde conectividad por menos de 30 segundos en promedio.

El tiempo de inactividad puede ser mayor para las instancias que tienen una actividad alta al comienzo del mantenimiento o que tienen conjuntos de datos muy grandes. Por lo general, Cloud SQL programa el mantenimiento una vez cada varios meses.

Puedes tomar medidas para asegurarte de que el mantenimiento tenga el menor impacto posible en tus operaciones; para ello, usa la configuración de mantenimiento y haz que los sistemas sean resilientes a los errores transitorios.

Configuración de mantenimiento

Cloud SQL te ofrece la capacidad de configurar actualizaciones de mantenimiento a través de un conjunto de ajustes de mantenimiento.

Puedes configurar el mantenimiento para que se programe en momentos en los que un tiempo de inactividad breve cause el menor impacto en las aplicaciones. Para cada instancia de Cloud SQL, puedes configurar lo siguiente:

  • Período de mantenimiento. El día de la semana y la hora en que Cloud SQL programa el mantenimiento. Los períodos de mantenimiento duran una hora. Obtén más información sobre cómo configurar un período de mantenimiento.

  • Orden de actualización. Establece el orden en el que se actualiza la instancia de Cloud SQL en relación con otras instancias de la misma región. El orden de la actualización se puede establecer como Any, Earlier o Later. Las instancias Later se actualizan una semana después de las instancias Earlier con el mismo período de mantenimiento en la misma región. Debes establecer el orden de actualización cuando configuras un período de mantenimiento.

  • Período de rechazo del mantenimiento. Un bloque de días en el que Cloud SQL no programa el mantenimiento. Los períodos de rechazo del mantenimiento pueden tener hasta 90 días. Obtén más información sobre cómo configurar un período de rechazo del mantenimiento.

Ejemplo de mantenimiento

Supongamos que eres desarrollador de un minorista que administra un servicio de carrito de compras. Tienes una instancia de Cloud SQL para un entorno de producción y otra para un entorno de etapa de pruebas. Quieres que el mantenimiento se realice en el momento en que tu instancia administra la menor cantidad de tráfico, que es alrededor de la medianoche los domingos. También puedes omitir el mantenimiento durante la temporada de compras para las fiestas de fin de año.

En este caso, establece la configuración de mantenimiento de tu instancia de producción como se indica a continuación:

  • Período de mantenimiento: domingos entre las 12:00 a.m. y la 1:00 a.m. ET
  • Orden de actualización: Later
  • Período de rechazo del mantenimiento: del 1 de noviembre al 15 de enero

La configuración de mantenimiento del entorno de etapa de pruebas sería idéntica, excepto que el orden de actualización se establecería en Earlier. Esto garantiza que puedas ejecutar pruebas de aceptación operativas para una versión de mantenimiento en etapa de pruebas al menos siete días antes del lanzamiento de mantenimiento a producción. Si algo sale mal en el entorno de etapa de pruebas, tienes tiempo para diagnosticar y solucionar el problema, de modo que el entorno de producción no se vea afectado.

Próximas notificaciones de mantenimiento

Puedes recibir una notificación sobre el próximo mantenimiento enviado a tu correo electrónico al menos una semana antes de que se programe el mantenimiento. Si deseas configurar un filtro de correo electrónico para las notificaciones, el título del correo electrónico es Próximo mantenimiento para la instancia de Cloud SQL instancename.

Las notificaciones de mantenimiento no se envían de forma predeterminada. Debes habilitar las notificaciones de mantenimiento. También debes seleccionar un período de mantenimiento antes de recibir notificaciones.

Notificaciones se envían a la dirección de correo electrónico asociada con tu Cuenta de Google. No se puede configurar un alias de correo electrónico personalizado (por ejemplo, un alias de correo electrónico del equipo).

Habilita las notificaciones de mantenimiento para todas las instancias de Cloud SQL que tienen períodos de mantenimiento en un proyecto determinado. Recibes una notificación por instancia. Las próximas notificaciones de mantenimiento no se envían para las réplicas de lectura.

También puedes ver la próxima información de mantenimiento en Google Cloud Console.

  • En la lista de Instancias, en la columna Mantenimiento. Si el mantenimiento está programado, verás la fecha y la hora en que está programado el inicio. Puedes filtrar la lista de instancias mediante el término Mantenimiento a fin de encontrar todas las instancias con mantenimiento programado. La columna Mantenimiento solo se muestra cuando el mantenimiento está programado en una o más instancias del proyecto. Si no hay mantenimiento programado, la columna se oculta.
  • En la página Detalles de la instancia del panel Mantenimiento. Si el mantenimiento está programado, en Próximo, verás una fecha y hora de inicio programado.
  • En la página ACTIVIDAD de Google Cloud Console, puedes ver una lista de instancias con mantenimiento programado. Si el mantenimiento está programado, las instancias tienen el mensaje Mantenimiento de SQL, y la fecha y hora de inicio.

Reprograma el mantenimiento

Si tienes un período de mantenimiento para tu instancia, puedes reprogramar el mantenimiento en cualquier momento antes de que el mantenimiento esté programado. Por ejemplo, si tienes un servicio nuevo que se lanza durante la hora de mantenimiento original, es posible que desees reprogramar el período de mantenimiento unos días después del lanzamiento.

Puedes reprogramar el mantenimiento varias veces, siempre que no sea más de una semana después de la hora programada en un principio.

Hay varias opciones de programación para el nuevo período de mantenimiento:

  • Aplicar actualizaciones de inmediato. Puedes aplicar la actualización a tu instancia de forma inmediata en lugar de esperar el período de mantenimiento programado. En este caso, el mantenimiento suele comenzar en cinco minutos.
  • Reprogramarlo para otro horario. Puedes posponer un evento de mantenimiento programado de dos maneras:

    • Siguiente período de disponibilidad. Esto aplaza el mantenimiento una semana.
    • Tiempo determinado. Esto te permite elegir cualquier horario específico en un plazo de una semana después del tiempo de mantenimiento programado originalmente.

Para reprogramar el mantenimiento ahora, consulta Reprograma el mantenimiento planificado.

Cómo funciona el mantenimiento

Para que el mantenimiento sea breve, Cloud SQL usa un flujo de trabajo de conmutación por error de mantenimiento que se asemeja mucho a nuestro flujo de trabajo de conmutación por error automático para las instancias con alta disponibilidad.

En resumen, estos son los pasos:

  1. Configura una VM actualizada con el software nuevo.
  2. Detén la VM original.
  3. Inicia la VM actualizada.
  4. Cambia el disco y la IP estática a la VM actualizada.

Revisa las siguientes pestañas para obtener detalles del flujo de trabajo, incluidos los previos y posteriores al mantenimiento.

Antes del mantenimiento

Antes del mantenimiento, el cliente se comunica con la VM original a través de una dirección IP estática. Los datos se almacenan en un disco persistente que se adjunta a la VM original. En este ejemplo, la instancia de Cloud SQL tiene una alta disponibilidad configurada, lo que significa que otra VM está en espera para apropiarse en caso de una interrupción no planificada. La instancia de Cloud SQL entrega tráfico a la aplicación.

Diagrama que muestra el estado previo al mantenimiento

Paso 1

Configura la VM nueva.

Se configura una máquina virtual (VM) nueva con el software de base de datos y la VM sistema operativo (OS) más recientes. Se iniciará el SO de la VM actualizada. En este punto, el motor de la base de datos aún no se inició. Para instancias con alta disponibilidad, también se configura una nueva VM en espera.

El tiempo de inactividad total se acorta de manera considerable mediante la instalación de la actualización de software en otra VM mientras la instancia original de Cloud SQL aún entrega tráfico.

Diagrama que muestra la configuración de la VM

Paso 2

Apaga la VM original.

El motor de la base de datos se apaga para que el disco pueda desconectarse de la VM original y conectarse a la VM actualizada. Antes de apagarse, el motor de la base de datos espera algunos segundos para que se confirmen las transacciones en curso y se desvíen las conexiones existentes de las solicitudes. Después de eso, las transacciones abiertas o de larga duración se revierten. La base de datos deja de aceptar conexiones nuevas y se descartan las conexiones existentes. La instancia deja de estar disponible y comienza el tiempo de inactividad por mantenimiento.

Diagrama de la instancia después de la conmutación por error

Paso 3

Cambia a la VM actualizada.

El disco está desconectado de la VM original y conectado a la VM actualizada. La dirección IP estática se vuelve a configurar para que apunte a la VM actualizada. Esto garantiza que la aplicación use la misma dirección IP después del mantenimiento que antes. La caché de la base de datos se borra con la VM original, lo que significa que la caché de la base de datos se borra de manera efectiva durante el mantenimiento.

Diagrama de cambio a la VM actualizada

Paso 4

Inicia la VM actualizada.

El motor de base de datos actualizada se inicia en el disco de datos. El uso de un disco de datos común garantiza que todas las transacciones escritas en la instancia original antes del mantenimiento sigan presentes en la base de datos actualizada después del mantenimiento. Si alguna transacción incompleta no terminó de revertirse durante el cierre de la base de datos, la base de datos pasa de forma automática a la recuperación ante fallas para asegurarse de que se restablezca a un estado utilizable.

Diagrama de inicio de la VM actualizada

Después del mantenimiento

Después del paso 4, la instancia de Cloud SQL estará disponible para aceptar conexiones y volverá a entregar tráfico a la aplicación.

Para la aplicación, además del software actualizado, la instancia de Cloud SQL tiene el mismo aspecto. La aplicación aún se conecta a la instancia de Cloud SQL mediante la misma dirección IP estática y la VM actualizada se ejecuta en la misma zona que la VM original. Se conservan todos los datos escritos en la base de datos original.

Diagrama del mantenimiento posterior

Preguntas frecuentes sobre el mantenimiento

¿El tiempo de inactividad de mantenimiento se considera dentro del ANS?

El tiempo de inactividad del mantenimiento normal no se considera dentro del ANS. Sin embargo, Cloud SQL cuenta el tiempo de inactividad de mantenimiento urgente en el ANS.

¿Cómo afecta el mantenimiento a las réplicas de lectura?

Las réplicas de lectura no tienen en cuenta los períodos de mantenimiento y pueden recibir actualizaciones de mantenimiento en cualquier momento. No hay garantías sobre cuándo se producen las actualizaciones, además, es posible que estas puedan superponerse o que sucedan en un momento muy cercano a la actualización de la instancia principal.

¿Puedo cancelar el mantenimiento programado?

No puedes cancelar un período de mantenimiento programado, pero puedes volver a programarlo.

Reprograma las limitaciones

Debes tener en cuenta los siguientes factores acerca de la reprogramación:

  • Debes reprogramar el mantenimiento al menos 24 horas antes del evento de mantenimiento programado en un principio.

  • Puedes reprogramar el mantenimiento de una o varias instancias del proyecto. Sin embargo, solo puedes reprogramar una instancia a la vez (la reprogramación masiva no está disponible).

  • Puedes reprogramar el mantenimiento a un momento que se encuentre dentro de un rechazo del período de mantenimiento, o incluso fuera del período de mantenimiento, siempre que el tiempo no supere el límite de reprogramación de una semana.

  • Si hay una operación de mantenimiento en curso, la reprogramación se retrasa hasta que se complete la operación.

¿Qué sucede si se cancela el evento de mantenimiento?

Si Cloud SQL cancela un evento de mantenimiento, recibirás una notificación en la que se indicará que se canceló el mantenimiento con anticipación, cuando sea posible.

Cuando se vuelva a programar el evento de mantenimiento, recibirás una notificación nueva del próximo mantenimiento.

Limitaciones del rechazo del período de mantenimiento

Debes tener en cuenta lo siguiente sobre los períodos de rechazo del mantenimiento:

  • Puedes tener un rechazo del período de mantenimiento incluso si no tienes configurados períodos de mantenimiento para tu instancia. Los períodos de rechazo de mantenimiento pueden variar de 1 a 90 días.

  • El período de mantenimiento de rechazo tiene prioridad sobre los de mantenimiento programados. Si hay un conflicto entre el momento de un período de mantenimiento y el período de mantenimiento rechazado, el período de rechazo anula el de mantenimiento.

  • Los rechazos de períodos de mantenimiento y la programación relativa son características independientes. Un rechazo del período de mantenimiento especificado en una instancia Earlier no tiene efecto en la programación de la instancia Later. No se envían notificaciones si el programa de mantenimiento se encuentra dentro del rechazo del período de mantenimiento para instancias Earlier o Later.

  • Cuando se establece un rechazo del período en una instancia principal, el mantenimiento de todas las réplicas asociadas a esta también se rechaza. Como ejemplo, una instancia principal ubicada en la región A tiene tres réplicas de lectura: dos en la región A y una en la región B. Cuando se establece un rechazo del período en la instancia principal, ninguna de las réplicas, incluida la réplica en la región B, recibirá mantenimiento hasta que venza el rechazo del período en la instancia principal.

  • Se omite la actualización si se establece un rechazo del período de mantenimiento después de que este se programe de modo que el rechazo del período de mantenimiento se superponga con el tiempo de mantenimiento programado.

  • Puedes configurar el rechazo del período de mantenimiento para que se repita cada año si no incluyes el año en los parámetros de fecha de inicio y finalización. Si se especifica el año, el rechazo del período de mantenimiento se establece solo para ese año.

  • Puedes configurar varios períodos de denegación de mantenimiento en un año. Recomendamos que evites encadenar períodos de denegación para omitir los eventos de mantenimiento programados consecutivos. Es importante mantenerse al día en el mantenimiento de Cloud SQL para garantizar que tu instancia funcione de manera confiable. Por lo general, el mantenimiento de Cloud SQL se programa una vez cada pocos meses.

  • Para garantizar la confiabilidad del servicio, Cloud SQL puede notificar a los usuarios con instancias que ejecutan actualizaciones de mantenimiento que tienen más de 12 meses de antigüedad que se requiere el próximo lanzamiento de mantenimiento.

  • Cuando finaliza un rechazo del período de mantenimiento, se reanuda el comportamiento habitual de mantenimiento.

Minimiza el impacto del mantenimiento

En general, Google Cloud recomienda que los usuarios que ejecutan aplicaciones en la nube hagan que sus sistemas sean resistentes a los errores transitorios, que son problemas de comunicación momentáneos entre los servicios que causan la falta de disponibilidad temporal. Es inevitable que haya errores transitorios ocasionales en la nube.

Algunos de los errores transitorios que ocurren durante el mantenimiento son conexiones descartadas y transacciones fallidas en curso. Si diseñas tus sistemas y ajustas tus aplicaciones para que sean resilientes a los errores transitorios, también puedes minimizar los impactos debido al mantenimiento de la base de datos.

Para minimizar el impacto de las conexiones descartadas, puedes usar grupos de conexiones. Mientras que las conexiones entre el agrupador y la base de datos se descartan durante el mantenimiento, se conservan las conexiones entre la aplicación y el agrupador. De esta manera, el trabajo de restablecer las conexiones es transparente para la aplicación y se descarga al agrupador de conexiones.

Para reducir las fallas de transacción, puedes limitar la cantidad de transacciones de larga duración. Volver a escribir las consultas para que sean más pequeñas y eficientes no solo reduce el tiempo de inactividad del mantenimiento, sino que también mejora el rendimiento y la confiabilidad de la base de datos.

Puedes usar Estadísticas de consultas para identificar consultas lentas.

Para recuperarte de manera eficiente de las pérdidas de conexión y las fallas de transacción, puedes administrar las conexiones de tu base de datos de manera eficiente. Puedes compilar una lógica de consulta y de reintento de conexión con retirada exponencial en tus aplicaciones y agrupadores de conexiones. En caso de que una consulta falle o se pierda una conexión, el sistema establece un período de espera antes de reintentar, lo que aumenta para cada reintento posterior. Por ejemplo, el sistema puede esperar unos segundos para el primer reintento, pero hasta un minuto para el cuarto. Seguir este patrón garantiza que se corrijan estas fallas sin sobrecargar el servicio.

Otras soluciones de creatividades también pueden minimizar los impactos de mantenimiento, desde usar secuencias de comandos para preparar la caché de la base de datos después del mantenimiento hasta optimizar la cantidad de tablas en las bases de datos. Recomendamos seguir las prácticas recomendadas de administración de bases de datos y los lineamientos operativos para garantizar que el mantenimiento se realice sin problemas.

Mantenimiento urgente

En casos muy raros, es posible que Cloud SQL deba programar el mantenimiento fuera de la configuración de mantenimiento para aplicar parches a problemas de estabilidad graves o vulnerabilidades urgentes. Estas actualizaciones se lanzan con rapidez y Cloud SQL las cuenta como tiempo de inactividad en el ANS.

¿Qué sigue?