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 motor de base de datos y, en algunos casos, el sistema operativo. 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

En el caso de Cloud SQL Enterprise Plus, Cloud SQL ofrece mantenimiento planificado con un tiempo de inactividad casi nulo.

Cloud SQL programa un evento de actualización de mantenimiento una vez cada varios meses, por lo general. La actualización de mantenimiento puede demorar entre 5 y 10 minutos para cada instancia. Si la instancia tiene réplicas de lectura, la duración total de la actualización de mantenimiento puede llevar más tiempo. Sin embargo, durante el evento de actualización de mantenimiento, cada instancia de Cloud SQL Enterprise pierde conectividad durante menos de 60 segundos en promedio. El tiempo de inactividad puede ser mayor para una instancia que experimenta una gran cantidad de actividad durante el evento de actualización de mantenimiento o que tiene un conjunto de datos muy grande.

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 suelen perder conectividad por menos de 1 segundo 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

  • Debes habilitar el registro binario en tu instancia.

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

Simula un tiempo de inactividad planificado casi nulo

Para probar el tiempo de inactividad de mantenimiento planificado de tu instancia principal de la edición de Cloud SQL Enterprise Plus sin actualizar tu instancia de base de datos, puedes simular el mantenimiento planificado de casi cero.

Para hacerlo, invoca la simulación de un evento de mantenimiento en una instancia de edición de Cloud SQL Enterprise Plus que sea apta para el mantenimiento planificado con un tiempo de inactividad casi nulo. La solicitud de simulación da como resultado una operación de actualización de la instancia a la misma versión de mantenimiento antes de la operación.

Puedes realizar la simulación incluso si tienes una actualización de mantenimiento pendiente en la instancia. La versión de la instancia permanece igual durante toda la simulación.

Para simular un evento de mantenimiento planificado con un tiempo de inactividad casi nulo, usa el siguiente comando de la gcloud CLI:

gcloud sql instances patch INSTANCE_NAME --simulate-maintenance-event

Reemplaza INSTANCE_NAME por el nombre de la instancia en la que quieren ejecutar el evento de mantenimiento simulado.

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:

  • Horario de mantenimiento (antes Orden de actualización). La semana del período de lanzamiento para actualizar la instancia de Cloud SQL. Tienes las siguientes opciones:

    • Any: La actualización de mantenimiento puede ocurrir en cualquier momento, pero suele ocurrir dentro de la semana 1.
    • Week 1: El mantenimiento se realiza entre 7 y 14 días después de que se envía la notificación de mantenimiento.
    • Week 2: La actualización de mantenimiento se realiza entre 15 y 21 días después de que se envía la notificación.
    • Week 5: La actualización de mantenimiento ocurre entre 35 y 42 días después del envío de la notificación.

    Debes establecer el programa de la actualización de mantenimiento configurar un período de mantenimiento.

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

  • Período de rechazo del mantenimiento. Un bloque de días en el que Cloud SQL no programa el mantenimiento. Puedes establecer un rechazo del período de mantenimiento de 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
  • Horario de mantenimiento: Week 2
  • 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 tiempo de mantenimiento se establece en Week 2. 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 en el entorno de etapa de pruebas, tienes tiempo para diagnosticar y solucionar el problema, o configurar un rechazo del período de mantenimiento que tu entorno de producción no se ve 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.

Las 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 la actualización de mantenimiento hasta 24 horas antes de que se programe la actualización de mantenimiento. Por ejemplo, si lanzas un servicio nuevo durante el período de mantenimiento programado, es posible que desees posponer la actualización de mantenimiento unos días después del lanzamiento.

Existen algunos límites para reprogramar las actualizaciones de mantenimiento. Después de que Cloud SQL envíe el correo electrónico de notificación, Cloud SQL realiza la actualización de mantenimiento dentro de un período de siete semanas para evitar cualquier superposición con la siguiente actualización de mantenimiento de Cloud SQL. Por ejemplo, si seleccionas un horario de mantenimiento de la semana 1 o la semana 2, puedes reprogramar la actualización de mantenimiento hasta un máximo de 4 semanas (28 días) después de la fecha programada en un principio. Si configuras tu instancia con un horario de mantenimiento de la semana 5, solo puedes reprogramar el evento de mantenimiento hasta un máximo de una semana (7 días) después de la fecha original. Puedes reprogramar el mantenimiento varias veces, siempre que el evento de mantenimiento reprogramado se encuentre dentro de la duración de reprogramación definida por el tiempo de mantenimiento que configuraste para la instancia.

Para conocer todas las demás limitaciones, consulta Reprograma limitaciones.

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 un momento específico para la duración de la reprogramación definida por el horario de mantenimiento que configuraste para tu instancia.
      • 28 días si seleccionas el tiempo de mantenimiento de la semana 1 o 2
      • 7 días si seleccionas el tiempo de mantenimiento de la semana 5

Para obtener instrucciones sobre cómo reprogramar el mantenimiento, 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 base de datos en la VM original.
  3. Cambia el disco y la IP estática a la VM actualizada.
  4. Inicia la base de datos en 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

Detén la base de datos en 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 base de datos en 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 para actualizar todas tus réplicas de lectura. Especifica la instancia principal, y la solicitud de mantenimiento actualizará 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 la duración de la reprogramación se encuentre dentro del período definido por los tiempos de mantenimiento que configuraste para tu instancia.

  • 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 los tiempos de mantenimiento son características independientes. Si creas un rechazo del período de mantenimiento para una instancia que tieneWeek 1 tiempo de mantenimiento, no tiene efecto en la actualización programada de una instancia con los tiempos de mantenimiento de Week 2. Si una actualización de mantenimiento programada se encuentra dentro de un rechazo del período de mantenimiento, Cloud SQL no envía una notificación para las instancias que configuraste con los horarios de mantenimiento.

  • 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 rechazos de períodos de 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 versión de mantenimiento más reciente se aplica en para la próxima actualización de mantenimiento programada. O bien, puedes aplicar la última actualización de mantenimiento mediante el mantenimiento de autoservicio.

¿Qué sucede si la instancia se detiene durante la actualización de mantenimiento programada?

Si una instancia se detiene durante la actualización de mantenimiento programada, Cloud SQL omite la actualización de mantenimiento. Sin embargo, la próxima vez que reinicias la instancia, Cloud SQL la actualiza de forma automática con la última actualización de mantenimiento.

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