Actualizaciones de 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 puedes controlar el momento en que se realizan. Para empezar, consulta el artículo Ver y definir ventanas de mantenimiento.

Información general

Como servicio gestionado, Cloud SQL actualiza automáticamente las instancias para garantizar que el hardware, el sistema operativo y el motor de base de datos subyacentes sean fiables, eficaces, seguros y estén actualizados. La mayoría de estas actualizaciones se realizan mientras la instancia de Cloud SQL está en funcionamiento. No obstante, es posible que algunas actualizaciones del sistema requieran una breve interrupción del servicio. Estas actualizaciones se denominan mantenimiento.

El mantenimiento actualiza el motor de la base de datos y, en algunos casos, el sistema operativo. Como estas actualizaciones requieren que se reinicie la instancia, conllevan un tiempo de inactividad. Las actualizaciones de mantenimiento ofrecen las siguientes ventajas:

  • Funciones de Cloud SQL Para lanzar nuevas funciones, se actualiza el motor de la base de datos y se instalan nuevos complementos en la base de datos.

  • Actualizaciones de versiones de bases de datos. El proveedor del software de base de datos que desarrolla SQL Server lanza nuevas versiones secundarias varias veces al año. Cada nueva versión incluye correcciones de errores, parches de seguridad, mejoras de rendimiento y nuevas funciones de la base de datos. Para consultar la última versión secundaria compatible con Cloud SQL para SQL Server, consulta las notas de la versión o las versiones y políticas de versiones de la base de datos. Las instancias de Cloud SQL se actualizan a la versión de base de datos más reciente poco después de su lanzamiento, de modo que puedas beneficiarte de la ejecución del software de base de datos más reciente.

  • Parches del sistema operativo. Monitorizamos continuamente las vulnerabilidades de seguridad recién identificadas en el sistema operativo. Cuando las detectamos, aplicamos parches al sistema operativo para protegerte de los nuevos riesgos.

Impacto del mantenimiento

En la edición Enterprise Plus de Cloud SQL, Cloud SQL ofrece mantenimiento programado con un tiempo de inactividad casi nulo.

Cloud SQL programa una actualización de mantenimiento normalmente una vez cada varios meses. La actualización de mantenimiento puede tardar entre 5 y 10 minutos en cada instancia. Si la instancia tiene réplicas de lectura, la duración total de la actualización de mantenimiento puede ser mayor. Sin embargo, durante el evento de actualización de mantenimiento, cada instancia de Cloud SQL Enterprise Edition pierde la conectividad durante menos de 120 segundos de media. El tiempo de inactividad puede ser mayor en una instancia que esté experimentando una gran cantidad de actividad durante el evento de actualización de mantenimiento o que tenga un conjunto de datos muy grande.

Puedes tomar medidas para que el mantenimiento afecte lo menos posible a tus operaciones. Para ello, utiliza nuestros ajustes de mantenimiento y haz que tus sistemas sean resistentes a los errores transitorios.

Mantenimiento planificado con un tiempo de inactividad casi nulo

Con el mantenimiento programado con un tiempo de inactividad casi nulo, las instancias de la edición Enterprise Plus de Cloud SQL suelen perder la conectividad durante menos de 1 segundo durante el mantenimiento programado.

El tiempo de inactividad puede ser mayor en las instancias que tengan una actividad alta durante el mantenimiento.

Requisitos previos y restricciones

  • Admite entre 1 y 100 bases de datos por instancia.
  • Solo está disponible en la edición Cloud SQL Enterprise Plus.
  • Disponible para las siguientes ediciones de SQL Server:
    • SQL Server Enterprise 2019
    • SQL Server Enterprise 2022
  • Si usas el proxy de autenticación de Cloud SQL o los conectores de lenguaje de Cloud SQL, asegúrate de que estén actualizados a la versión más reciente.
  • El nombre interno del servidor de SQL Server SERVERPROPERTY('servername') puede cambiar durante el mantenimiento. Si tu aplicación hace referencia al nombre de host o al nombre del equipo, es posible que tengas que actualizar estos valores después del mantenimiento. Las cadenas de conexión de Cloud SQL y la dirección IP de la instancia no cambiarán.
  • No se admiten réplicas. Esto incluye réplicas principales y secundarias (réplicas de lectura).
  • Solo admite bases de datos de usuarios. Las bases de datos del sistema no se pueden agregar a grupos de disponibilidad.
  • No se admiten los siguientes tipos de bases de datos:
    • Bases de datos de solo lectura
    • Bases de datos de un solo usuario
    • Bases de datos designadas como AUTO_CLOSE
  • Las siguientes funciones no se admiten:
  • Durante el mantenimiento, los registros de la base de datos tendrán mensajes de dos máquinas virtuales diferentes.
  • Si se emite un DDL durante el mantenimiento programado, es posible que los cambios tengan una marca de tiempo de creación o modificación posterior a la marca de tiempo del mantenimiento.
  • Las cadenas de conexión y los ajustes de consulta del lado del cliente, como el tipo de conexión, los tiempos de espera de las consultas y la agrupación de conexiones, pueden influir en el tiempo de inactividad observado. No olvides probar la configuración de tu aplicación para encontrar los ajustes que mejor se adapten a tus necesidades.

Simular un mantenimiento programado con un tiempo de inactividad casi nulo

Para probar el tiempo de inactividad del mantenimiento programado de tu instancia principal de la edición Enterprise Plus de Cloud SQL sin actualizar tu instancia de base de datos, puedes simular un mantenimiento programado con un tiempo de inactividad prácticamente nulo.

Para ello, invoca la simulación de un evento de mantenimiento en una instancia de la edición Enterprise Plus de Cloud SQL que cumpla los requisitos para el mantenimiento programado 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 que antes de la operación.

Puedes realizar la simulación aunque tengas una actualización de mantenimiento pendiente en la instancia. La versión de la instancia sigue siendo la misma durante toda la simulación.

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

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

Sustituye INSTANCE_NAME por el nombre de la instancia en la que quieras ejecutar el evento de mantenimiento simulado.

Ajustes de mantenimiento

Cloud SQL te permite configurar actualizaciones de mantenimiento mediante un conjunto de ajustes de mantenimiento.

Puedes programar el mantenimiento para que se realice en momentos en los que el breve tiempo de inactividad tenga el menor impacto posible en tus aplicaciones. En cada instancia de Cloud SQL, puedes configurar lo siguiente:

  • Hora de mantenimiento (antes Orden de actualización). La semana del periodo de lanzamiento para actualizar tu instancia de Cloud SQL. Dispone de las siguientes opciones:

    • Any: la actualización de mantenimiento puede realizarse en cualquier momento, pero suele hacerse en la primera semana.
    • Week 1: el mantenimiento se realiza entre 7 y 14 días después de que se envíe 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íe la notificación.
    • Week 5: la actualización de mantenimiento se realiza entre 35 y 42 días después de que se envíe la notificación.

    Puedes definir la programación de la actualización de mantenimiento cuando configures una ventana de mantenimiento.

  • Ventana de mantenimiento. El día de la semana y la hora en los que Cloud SQL programa el mantenimiento. Las ventanas de mantenimiento duran una hora. Consulta cómo configurar una ventana de mantenimiento.

  • Rechazo del periodo de mantenimiento. Un bloque de días en los que Cloud SQL no programa mantenimiento. Puedes definir un periodo de mantenimiento denegado de hasta 90 días. Consulta cómo configurar un periodo de mantenimiento denegado.

Ventanas de mantenimiento predeterminadas

Si no configuras ninguna ventana de mantenimiento, Cloud SQL actualizará tu instancia en las siguientes ventanas predeterminadas según la zona horaria de la instancia:

  • Ventana de días laborables (de lunes a viernes): de 22:00 a 6:00
  • Ventana de fin de semana: desde el viernes a las 22:00 hasta el lunes a las 6:00

Ejemplo de mantenimiento

Supongamos que eres desarrollador de una tienda que gestiona un servicio de carrito de la compra. Tienes una instancia de Cloud SQL para un entorno de producción y otra para un entorno de pruebas. Quieres que el mantenimiento se realice cuando tu instancia gestione la menor cantidad de tráfico, que es alrededor de la medianoche de los domingos. También querrás evitar el mantenimiento durante la ajetreada temporada de compras de final de año.

En este caso, debes definir los ajustes de mantenimiento de tu instancia de producción de la siguiente manera:

  • Ventana de mantenimiento: los domingos entre las 00:00 y la 01:00 (ET)
  • Hora del mantenimiento: Week 2
  • Rechazo del periodo de mantenimiento: del 1 de noviembre al 15 de enero.

Los ajustes de mantenimiento de tu entorno de pruebas serían idénticos, excepto que el tiempo de mantenimiento se establecería en Week 2. De esta forma, puedes realizar pruebas de aceptación operativas de una versión de mantenimiento en el entorno de preproducción al menos siete días antes de que se lance en producción. Si algo va mal en el entorno de pruebas, tienes tiempo para diagnosticar y solucionar el problema o para configurar un periodo de mantenimiento denegado para que tu entorno de producción no se vea afectado.

Notificaciones de mantenimiento programado

Puedes recibir una notificación sobre el mantenimiento programado en tu correo electrónico al menos una semana antes de que se lleve a cabo. Si quieres configurar un filtro de correo para las notificaciones, el título del correo es Mantenimiento programado próximamente para tu instancia de Cloud SQL instancename.

Las notificaciones de mantenimiento no se envían de forma predeterminada. Debes habilitar las notificaciones de mantenimiento. Para recibir notificaciones, también debes seleccionar una ventana de mantenimiento.

Las notificaciones se envían a la dirección de correo asociada a tu cuenta de Google. No es posible configurar un alias de correo personalizado (por ejemplo, un alias de correo de equipo).

Habilitar las notificaciones de mantenimiento de todas las instancias de Cloud SQL que tengan ventanas de mantenimiento en un proyecto determinado. Recibirás una notificación por cada instancia. Las notificaciones de mantenimiento programado no se envían a las réplicas de lectura.

También puedes consultar información sobre el mantenimiento programado en la Google Cloud consola.

  • En la lista Instancias, en la columna Mantenimiento. Si el mantenimiento está programado, verás la fecha y la hora en las que se ha programado que empiece. Puedes filtrar la lista de instancias con el término Mantenimiento para encontrar todas las instancias cuyo mantenimiento esté programado. La columna Mantenimiento solo se muestra cuando se ha programado el mantenimiento de una o varias instancias del proyecto. Si no hay ninguna tarea de mantenimiento programada, la columna se oculta.
  • En la página Instance details (Detalles de la instancia) del panel Maintenance (Mantenimiento). Si el mantenimiento está programado, en Próximo verás la fecha y la hora en las que está programado que empiece.

  • En la página Explorador de registros de la Google Cloud consola. Usa el menú desplegable Nombre de todos los registros para buscar maintenance-events y, a continuación, haz clic en Aplicar. Si se ha programado el mantenimiento de una instancia, el registro muestra el nombre de la instancia y la hora de inicio del mantenimiento programado.

Otras notificaciones de mantenimiento

Si habilitas las notificaciones de mantenimiento, recibirás notificaciones sobre determinados eventos:

  • Próximo mantenimiento programado
  • Started maintenance
  • Mantenimiento completado
  • Mantenimiento cancelado

Reprogramar el mantenimiento

Si tu instancia tiene una ventana de mantenimiento, puedes reprogramar la actualización hasta 24 horas antes de que se produzca. Por ejemplo, si vas a lanzar un nuevo servicio durante la ventana de mantenimiento programada, puede que quieras posponer la actualización de mantenimiento unos días después del lanzamiento.

Hay algunos límites para reprogramar las actualizaciones de mantenimiento. Después de que Cloud SQL envíe el correo de notificación, Cloud SQL realizará la actualización de mantenimiento en un plazo de siete semanas para evitar que coincida con la siguiente actualización de mantenimiento de Cloud SQL. Por ejemplo, si seleccionas la semana 1 o la semana 2 como periodo de mantenimiento, puedes reprogramar la actualización de mantenimiento hasta un máximo de 4 semanas (28 días) después de la fecha programada originalmente. Si configuras tu instancia para que el mantenimiento se realice en la semana 5, solo podrás reprogramar el evento de mantenimiento hasta 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 produzca dentro del periodo de reprogramación definido por la programación de mantenimiento que hayas configurado para tu instancia.

Para ver el resto de las limitaciones, consulta Limitaciones de la reprogramación.

Tienes varias opciones de programación para la nueva ventana de mantenimiento:

  • Aplica las actualizaciones inmediatamente. Puedes aplicar la actualización a tu instancia inmediatamente en lugar de esperar a la ventana de mantenimiento programada. En este caso, el mantenimiento suele empezar en un plazo de cinco minutos.

  • Reprograma la cita para otro momento. Puedes posponer un evento de mantenimiento programado de dos formas:

    • Próxima ventana disponible. Esta opción aplaza el mantenimiento hasta la siguiente ventana de mantenimiento disponible después de la hora de mantenimiento programada, que suele ser una semana después.
    • Hora específica. Esta opción te permite elegir una hora específica para la reprogramación, que se define en función del tiempo de mantenimiento que hayas configurado para tu instancia.
      • 28 días si selecciona la semana 1 o la semana 2 como periodo de mantenimiento
      • 7 días si selecciona la opción de mantenimiento de la semana 5

Para obtener instrucciones sobre cómo cambiar la fecha de mantenimiento, consulta Cambiar la fecha de mantenimiento programado.

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 parece mucho al flujo de trabajo de conmutación por error automática para instancias de alta disponibilidad.

En resumen, estos son los pasos que debes seguir:

  1. Configura una máquina virtual actualizada con el nuevo software.
  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.

Ve a las siguientes pestañas para ver los detalles del flujo de trabajo, incluido el mantenimiento previo y posterior.

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 está conectado a la VM original. En este ejemplo, la instancia de Cloud SQL tiene configurada la alta disponibilidad, lo que significa que hay otra máquina virtual en espera para hacerse cargo en caso de interrupción no planificada. La instancia de Cloud SQL está sirviendo tráfico a la aplicación.

Diagrama que muestra el estado antes del mantenimiento

Paso 1

Configura la nueva VM.

Se configura una nueva máquina virtual con el software de base de datos y el sistema operativo de la máquina virtual más recientes. Se inicia el SO de la VM actualizado. En este punto, el motor de la base de datos aún no se ha iniciado. En el caso de las instancias de alta disponibilidad, también se configura una nueva VM de reserva.

El tiempo de inactividad total se reduce considerablemente al instalar la actualización de software en otra VM mientras la instancia de Cloud SQL original sigue atendiendo el tráfico.

Diagrama que muestra cómo configurar la VM

Paso 2

Detén la base de datos en la VM original.

El motor de base de datos se cierra para que el disco se pueda separar de la VM original y se pueda adjuntar a la VM actualizada. Antes de cerrarse, el motor de la base de datos espera unos segundos a que se completen las transacciones en curso y se agoten las solicitudes de las conexiones existentes. Después, se revierte cualquier transacción abierta o de larga duración. La base de datos deja de aceptar nuevas conexiones y se eliminan las conexiones existentes. La instancia deja de estar disponible y empieza el tiempo de inactividad por mantenimiento.

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

Paso 3

Cambia a la máquina virtual actualizada.

El disco se separa de la VM original y se conecta a la VM actualizada. La dirección IP estática se vuelve a configurar para que apunte a la VM actualizada. De esta forma, la aplicación usa la misma dirección IP después del mantenimiento que antes. La caché de la base de datos se elimina con la VM original, lo que significa que se borra durante el mantenimiento.

Diagrama del cambio a la VM actualizada

Paso 4

Inicia la base de datos en la VM actualizada.

El motor de base de datos actualizado se inicia en el disco de datos. Si se usa un disco de datos común, se asegura 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 ha terminado de revertirse durante el cierre de la base de datos, esta se someterá automáticamente a una recuperación tras un fallo para asegurarse de que se restaura 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 está disponible para aceptar conexiones y vuelve a servir tráfico a la aplicación.

Para la aplicación, aparte del software actualizado, la instancia de Cloud SQL tiene el mismo aspecto. La aplicación sigue conectándose a la instancia de Cloud SQL con la misma dirección IP estática y la VM actualizada se ejecuta en la misma zona que la VM original. Todos los datos escritos en la base de datos original se conservan.

Diagrama de la situación tras el mantenimiento

Minimizar el impacto del mantenimiento

Por lo general, Google Cloud recomienda que los usuarios que ejecuten aplicaciones en la nube hagan que sus sistemas sean resistentes a los errores transitorios, que son problemas momentáneos de comunicación entre servicios causados por una indisponibilidad temporal. En la nube, es inevitable que se produzcan errores transitorios de vez en cuando.

Algunos de los errores transitorios que se producen durante el mantenimiento son conexiones perdidas y transacciones en curso fallidas. Si diseñas tus sistemas y ajustas tus aplicaciones para que sean resistentes a los errores transitorios, también podrás minimizar los impactos debidos al mantenimiento de la base de datos.

Para minimizar el impacto de las conexiones perdidas, puedes usar grupos de conexiones. Aunque las conexiones entre el gestor de conexiones y la base de datos se interrumpen durante el mantenimiento, las conexiones entre la aplicación y el gestor de conexiones se conservan. De esta forma, el trabajo de restablecer las conexiones es transparente para la aplicación y se descarga en el agrupador de conexiones.

Para reducir los errores de transacción, puedes limitar el número de transacciones de larga duración. Reescribir las consultas para que sean más pequeñas y eficientes no solo reduce el tiempo de inactividad por mantenimiento, sino que también mejora el rendimiento y la fiabilidad de la base de datos.

Para recuperarte de forma eficiente de las interrupciones de conexión y los errores de transacción, puedes gestionar tus conexiones de base de datos de forma eficiente. Puedes crear una lógica de reintento de conexión y de consulta con retroceso exponencial en tus aplicaciones y agrupadores de conexiones. Si una consulta falla o se pierde una conexión, el sistema establece un periodo de espera antes de volver a intentarlo, que aumenta con cada intento posterior. Por ejemplo, el sistema puede esperar solo unos segundos para el primer reintento, pero hasta un minuto para el cuarto. Si sigues este patrón, te asegurarás de que estos errores se corrijan sin sobrecargar el servicio.

También se pueden aplicar otras soluciones creativas para minimizar el impacto del mantenimiento, como usar secuencias de comandos para calentar la caché de la base de datos después del mantenimiento o reducir el número de tablas de las bases de datos. Te recomendamos que sigas las prácticas recomendadas y las directrices operativas de gestión de bases de datos para que el mantenimiento se realice sin problemas.

Mantenimiento urgente

En casos muy excepcionales, es posible que Cloud SQL tenga que programar tareas de mantenimiento fuera de los ajustes de mantenimiento para corregir problemas graves de estabilidad o vulnerabilidades que requieran una solución urgente. Estas actualizaciones se aplican rápidamente y Cloud SQL las considera tiempo de inactividad en el SLA.

Mantenimiento de autoservicio

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

Aunque Cloud SQL programa actualizaciones de mantenimiento cada pocos meses para asegurarse de que tienes el software más reciente, puedes usar el mantenimiento de autoservicio para mantener tu instancia actualizada si se da alguna de las siguientes circunstancias:

  • Necesitas una actualización antes de la próxima actualización de mantenimiento programada.
  • Quieres ponerte al día con el software más reciente después de saltarte la última actualización de mantenimiento.

Si usas réplicas de lectura, puedes usar el mantenimiento de autoservicio para actualizar todas tus réplicas de lectura. Especifica 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. A continuación, 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.

Limitaciones de la reprogramación

Debes tener en cuenta algunas cuestiones sobre la reprogramación:

  • Debes reprogramar el mantenimiento al menos 24 horas antes de que se produzca el evento de mantenimiento programado originalmente.

  • Puedes reprogramar el mantenimiento de una o varias instancias de tu proyecto. Sin embargo, solo puedes reprogramar una instancia a la vez (no se pueden reprogramar varias a la vez).

  • Puedes reprogramar el mantenimiento para que se realice en un momento que esté dentro de un periodo de mantenimiento denegado o incluso fuera de la ventana de mantenimiento, siempre que la duración de la reprogramación esté dentro del periodo definido por la programación del mantenimiento que hayas configurado 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 de rechazo del periodo de mantenimiento

Hay algunos aspectos que debes tener en cuenta sobre los periodos de mantenimiento rechazados:

  • A partir del 15 de agosto del 2025, no podrás definir un rechazo del periodo de mantenimiento en una instancia si su versión de mantenimiento tiene más de 12 meses de antigüedad. Todas las instancias que usen una versión de mantenimiento con más de 12 meses de antigüedad deben recibir una actualización. Para encontrar la fecha de la versión de mantenimiento instalada en tu instancia, usa el comando gcloud sql instances describe o consulta la sección Mantenimiento de la página Resumen de la instancia en la consolaGoogle Cloud . Para obtener más información sobre cómo encontrar la versión de mantenimiento de tu instancia, consulta Ver información de la instancia. Para determinar su fecha de lanzamiento, consulta el nombre de la versión de mantenimiento. Por ejemplo, si el nombre de la versión de mantenimiento es SQLSERVER_2022_ENTERPRISE_CU14.R20250302.00_28, la fecha de lanzamiento correspondiente es el 2 de marzo del 2025.

    Para actualizar la instancia, realiza el mantenimiento de autoservicio o espera a que se haga automáticamente durante la siguiente ventana de mantenimiento. Después de actualizar la instancia, puedes definir un periodo de rechazo del mantenimiento.

  • Puedes tener un periodo de mantenimiento denegado aunque no hayas configurado ventanas de mantenimiento para tu instancia. Los periodos de rechazo del mantenimiento pueden durar entre 1 y 90 días.

  • El periodo de mantenimiento rechazado tiene prioridad sobre cualquier ventana de mantenimiento programado. Si hay un conflicto entre el momento de una ventana de mantenimiento y el periodo de rechazo del mantenimiento, este último prevalecerá sobre la ventana de mantenimiento.

  • Los periodos de mantenimiento rechazados y la programación del mantenimiento son funciones independientes. Si creas un periodo de rechazo del mantenimiento para una instancia que tiene un Week 1 horario de mantenimiento, no tendrá ningún efecto en la determinación de la actualización programada de una instancia con un Week 2 horario de mantenimiento. Si una actualización de mantenimiento programada se produce durante un periodo de mantenimiento rechazado, Cloud SQL no envía ninguna notificación a las instancias que hayas configurado con la hora de mantenimiento.

  • Cuando se establece un periodo de denegación en una instancia principal, también se deniega el mantenimiento de todas las réplicas asociadas a la instancia principal. Por 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 periodo de denegación en la instancia principal, el mantenimiento de cada una de las réplicas, incluida la réplica de la región B, no se lleva a cabo hasta que finaliza el periodo de denegación en la instancia principal.

  • Si se define un periodo de rechazo del mantenimiento después de programar el mantenimiento de forma que el periodo de rechazo del mantenimiento se solape con la hora del mantenimiento programado, se omitirá la actualización.

  • Puedes configurar el periodo de mantenimiento denegado para que se repita cada año si no incluyes el año en los parámetros de fecha de inicio y de finalización. Si se especifica el año, el periodo de mantenimiento denegado se define solo para ese año.

  • Puedes definir varios periodos de mantenimiento denegado en un año. Sin embargo, no puedes definir un rechazo del periodo de mantenimiento para una instancia que ejecute una versión de mantenimiento de hace más de 12 meses. Evita encadenar periodos de rechazo para saltarte eventos de mantenimiento programado consecutivos. Es importante que tu instancia esté al día con el mantenimiento de Cloud SQL para que funcione de forma fiable. Por lo general, el mantenimiento de Cloud SQL se programa una vez cada varios meses.

  • Para ayudar a garantizar la fiabilidad del servicio, Cloud SQL notifica a los usuarios con instancias que ejecutan versiones de mantenimiento con más de 12 meses de antigüedad que es necesario realizar el próximo lanzamiento de mantenimiento.

  • Cuando finaliza un periodo de rechazo del mantenimiento, se reanuda el comportamiento habitual del mantenimiento.

  • Los periodos de mantenimiento denegados no afectan a las operaciones iniciadas por los usuarios, como el mantenimiento de autoservicio.

Preguntas frecuentes sobre el mantenimiento

¿El tiempo de inactividad por mantenimiento se tiene en cuenta en el SLA?

El tiempo de inactividad debido a tareas de mantenimiento normales no se tiene en cuenta en el SLA. Sin embargo, Cloud SQL contabiliza el tiempo de inactividad por mantenimiento urgente en el SLA.

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

  • Cloud SQL siempre mantiene las réplicas de lectura antes que la instancia principal. Si la instancia principal tiene una ventana de mantenimiento, las réplicas de lectura observan la misma ventana de mantenimiento.
  • Si tu instancia principal tiene varias réplicas de lectura, Cloud SQL puede actualizar algunas de las réplicas simultáneamente.
  • Las réplicas de lectura respetan el periodo de mantenimiento rechazado que se haya definido para la instancia principal.

¿Puedo cancelar el mantenimiento programado?

No puedes cancelar una ventana de mantenimiento programada, pero sí puedes reprogramarla. También puedes configurar un rechazo del periodo de mantenimiento que se solape con el tiempo de mantenimiento programado para omitir el mantenimiento.

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

Si Cloud SQL cancela un evento de mantenimiento, recibirás una notificación de cancelación con antelación, si es posible.

Recibirás una nueva notificación de mantenimiento programado cuando se vuelva a programar el evento de mantenimiento.

¿El mantenimiento de Cloud SQL es acumulativo?

Las actualizaciones de mantenimiento son acumulativas. No es necesario que apliques todas las actualizaciones de mantenimiento que te hayas perdido. La versión de mantenimiento más reciente se aplicará en la próxima actualización de mantenimiento programada. También puedes aplicar la última actualización de mantenimiento mediante el mantenimiento de autoservicio.

¿Qué ocurre 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 omitirá la actualización de mantenimiento. Sin embargo, la próxima vez que reinicies la instancia, Cloud SQL la actualizará automáticamente con la última actualización de mantenimiento.

¿Cuánto tiempo se tarda en realizar el mantenimiento de autoservicio de todas las réplicas de lectura de una instancia principal?

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

La segunda actualización omite las réplicas que ya tienen la versión de mantenimiento de destino.

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, le recomendamos que actualice 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 utilices la misma versión de mantenimiento en todas las réplicas de lectura y en la instancia principal.

Siguientes pasos