Acerca del mantenimiento de 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 MySQL 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 MySQL 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.

    Debes realizar actualizaciones de versiones secundarias de MySQL 8.0 de forma manual. Consulta Configura la versión secundaria de MySQL para una instancia.

  • 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 MySQL pierde conectividad durante menos de 60 segundos en promedio.

Para la edición Enterprise Plus de Cloud SQL, Cloud SQL ofrece mantenimiento planificado con tiempo de inactividad cercano a cero.

El tiempo de inactividad puede ser mayor para las instancias que tienen una actividad alta durante el 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.

Mantenimiento planificado con tiempo de inactividad cercano a cero

Con un tiempo de inactividad planificado casi nulo, las instancias de edición de Cloud SQL Enterprise Plus con alta disponibilidad suelen perder conectividad por menos de 10 segundos durante el mantenimiento planificado.

El tiempo de inactividad puede ser mayor para las instancias que tienen actividad alta durante el mantenimiento.

Requisitos previos y restricciones

  • Si usas alguna de las siguientes marcas, se deben configurar como valores predeterminados:

    • sync_binlog, valor: 1
    • innodb_flush_log_at_trx_commit, valor 1
    • replica_skip_errors, valor OFF
    • binlog_order_commit, valor ON

    Para obtener más información, consulta Configura marcas de bases de datos.

  • Si usas el proxy de Cloud SQL Auth o los conectores de lenguaje de Cloud SQL, asegúrate de que estén actualizados a su versión más reciente.

  • Si tienes réplicas externas con GTID habilitado, debes configurar esas réplicas para que usen el posicionamiento automático basado en GTID o la replicación se interrumpirá después del mantenimiento. Para obtener más información, consulta Posicionamiento automático de GTID.

  • El UID del servidor MySQL cambiará durante el mantenimiento.

  • Durante el mantenimiento, los registros de la base de datos tendrán mensajes de dos VMs diferentes.
  • Si se emite un DDL durante el mantenimiento planificado, los cambios pueden tener una marca de tiempo de creación o modificación que sea posterior a la marca de tiempo de mantenimiento.

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 rechazo del período de mantenimiento.

Períodos de mantenimiento predeterminados

Si no configuras un período de mantenimiento, Cloud SQL actualiza la instancia en los siguientes períodos predeterminados según la zona horaria de la instancia:

  • Período de días de la semana (de lunes a viernes): De 10 p.m. a 6 a.m.
  • Período de fines de semana: Del viernes a las 10 p.m. al lunes a las 6 a.m.

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. Antes de recibir notificaciones, también debes seleccionar un período de mantenimiento.

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 la consola de Google Cloud.

  • 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 la consola de Google Cloud, 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.

Reprogramar 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 sean más de 28 días 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. Esta opción aplaza el mantenimiento hasta el siguiente período de mantenimiento disponible después de la hora de mantenimiento programada actual, que suele ser una semana después.
    • Tiempo determinado. Esta opción te permite elegir cualquier horario específico dentro de los 28 días posteriores a la hora de mantenimiento programada en un principio.

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. Cambia el disco y la IP estática a la VM actualizada.
  4. Inicia 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

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.

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 entregan con rapidez y Cloud SQL las cuenta como tiempo de inactividad en el ANS.

Mantenimiento de autoservicio

Cloud SQL lanza con regularidad mejoras y parches de software para vulnerabilidades de seguridad a través de versiones de mantenimiento nuevas que puedes instalar en tus instancias. Cloud SQL mantiene un registro de cambios de mantenimiento de Cloud SQL para cada versión principal del motor de base de datos. Para obtener más información, consulta Registros de cambios de mantenimiento de Cloud SQL.

Si bien Cloud SQL programa actualizaciones de mantenimiento una vez cada varios meses para garantizar que tengas el software más reciente, puedes usar el mantenimiento de autoservicio para mantener actualizada tu instancia si se cumple lo siguiente:

  • Necesitas actualizar antes del próximo evento de mantenimiento programado.
  • Quieres mantenerte al día con el software más reciente después de omitir la actualización de mantenimiento más reciente.

Si usas réplicas de lectura, puedes usar el mantenimiento de autoservicio para actualizar todas tus réplicas de lectura. Especificas la instancia principal, y la solicitud de mantenimiento actualiza todas las réplicas de lectura de la instancia principal a la versión de mantenimiento especificada. Luego, la instancia principal se actualiza a la versión de mantenimiento.

Limitaciones de mantenimiento

En esta sección, se describen las limitaciones del mantenimiento de Cloud SQL.

Reprograma 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 28 días.

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

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.

  • Los períodos de rechazo del mantenimiento no afectan las operaciones activadas por el usuario, como el mantenimiento de autoservicio.

Preguntas frecuentes sobre el mantenimiento

¿Cómo afecta el mantenimiento a las instancias de conmutación por error de HA heredadas?

Las instancias de conmutación por error de HA heredadas se retiran para llevar a cabo las actualizaciones de mantenimiento. Reciben las actualizaciones de mantenimiento justo antes que la instancia principal. No puedes establecer un período de mantenimiento directamente en una instancia de conmutación por error de HA heredada, ya que estas instancias comparten el período de mantenimiento de la instancia principal.

¿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?

  • Cloud SQL siempre mantiene réplicas de lectura antes de la instancia principal. Si la instancia principal tiene un período de mantenimiento, las réplicas de lectura observan el mismo período de mantenimiento.
  • Si tu instancia principal tiene varias réplicas de lectura, Cloud SQL puede actualizar algunas de las réplicas de forma simultánea.
  • Las réplicas de lectura observan el rechazo del período de mantenimiento establecido para la instancia principal.

¿Puedo cancelar el mantenimiento programado?

No puedes cancelar un período de mantenimiento programado, pero puedes volver a programarlo. También puedes configurar un período de mantenimiento de rechazo que se superponga con el tiempo de mantenimiento programado para omitir el mantenimiento de forma eficaz.

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

¿El mantenimiento de Cloud SQL es acumulativo?

Las actualizaciones de mantenimiento son acumulativas. No es necesario aplicar cada actualización de mantenimiento que puedas haber pasado por alto. La última versión de mantenimiento se aplica en la próxima actualización de mantenimiento programada. O bien, puedes aplicar la última actualización de mantenimiento mediante el mantenimiento de autoservicio.

¿Cuánto tarda el mantenimiento de autoservicio para todas las réplicas de lectura de una instancia principal?

El tiempo que tarda una actualización de mantenimiento de autoservicio depende de la cantidad total de réplicas de lectura de tu instancia principal. Para reducir la cantidad de tiempo que puede tardar la actualización de mantenimiento de autoservicio, puedes actualizar algunas réplicas de lectura de forma individual y, luego, realizar la actualización en la instancia principal para actualizar el resto de las réplicas de lectura.

La segunda actualización omite cualquier réplica que ya tenga la versión de mantenimiento objetivo.

Si tengo varias réplicas de lectura de mi instancia principal, ¿puedo realizar el mantenimiento de autoservicio en una sola réplica de lectura?

Sí, puedes realizar el mantenimiento de autoservicio en una instancia de réplica de lectura individual. Sin embargo, te recomendamos actualizar el resto de las réplicas de lectura y la instancia principal a la misma versión de mantenimiento poco después. Te recomendamos que operes todas las réplicas de lectura y la instancia principal con una versión de mantenimiento idéntica.

¿Qué sigue?