Los clústeres y las instancias de AlloyDB dependen de muchos recursos internos de bajo nivel deGoogle Cloud . Estos incluyen las instancias de máquina virtual (VM) que funcionan como nodos de AlloyDB y balanceadores de cargas, y los volúmenes de almacenamiento que contienen tus datos. Debido a que AlloyDB es un servicio administrado, Google se encarga de mantener actualizados estos recursos internos. Esto ayuda a garantizar que tus clústeres e instancias de AlloyDB sigan siendo confiables, seguros y con un buen rendimiento.
La mayoría de estas actualizaciones no requieren tiempo de inactividad, pero algunas actualizaciones del sistema requieren una breve interrupción del servicio. Nos referimos a estas actualizaciones como mantenimiento. Debido a que estas actualizaciones requieren que se reinicie el nodo afectado, pueden generar tiempo de inactividad.
Las operaciones de mantenimiento no disruptivas de AlloyDB limitan el tiempo de inactividad a menos de 1 segundo para las instancias principales y secundarias, y a cero segundos para los grupos de lectura. Este tiempo de inactividad cercano a cero y cero se logra preparando un servidor de reemplazo con las actualizaciones y, luego, cambiando el servidor de la base de datos. Como puedes ver en los registros, el tiempo de operación es mayor que el tiempo de inactividad.
Motivos del mantenimiento
Las actualizaciones de mantenimiento pueden ocurrir por los siguientes motivos:
Nuevas funciones de AlloyDB. Para lanzar nuevas funciones, Google debe actualizar el software de AlloyDB que se ejecuta en los nodos de tu clúster. Esto también puede implicar la actualización de las extensiones de PostgreSQL que se incluyen con AlloyDB o la instalación de extensiones nuevas.
Actualizaciones de compatibilidad de la base de datos. La comunidad de PostgreSQL lanza periódicamente actualizaciones de versiones secundarias para las versiones principales compatibles de PostgreSQL. Google incorpora estas actualizaciones en AlloyDB y las aplica a los clústeres configurados para la compatibilidad con la versión principal afectada. Para obtener más información, consulta las políticas de versiones de bases de datos.
Parches del sistema operativo. Google supervisa de forma continua las vulnerabilidades de seguridad en los sistemas operativos que se ejecutan en los recursos internos que constituyen los clústeres de AlloyDB. Después de la detección, aplicamos un parche a los sistemas operativos de los recursos para protegerte de los riesgos nuevos.
Horario y preferencias de mantenimiento
Puedes establecer períodos de mantenimiento para los clústeres de AlloyDB principales y secundarios. De forma predeterminada, no se establece ningún período de mantenimiento en un clúster de AlloyDB. El mantenimiento no urgente de un clúster de AlloyDB sin períodos de mantenimiento configurados puede ocurrir en cualquier momento, excepto entre las 6 a.m. y las 10 p.m. los días laborables, en la hora local de la región en la que se encuentra el clúster.
También puedes especificar un período de mantenimiento. Un período de mantenimiento define la hora y el día de la semana que prefieres para que tu clúster comience sus eventos de mantenimiento. Por ejemplo, puedes configurar un clúster para que tenga un período de mantenimiento que comience a las 11 a.m. los domingos (UTC).
Si configuras un período de mantenimiento, AlloyDB programa los futuros eventos de mantenimiento que no sean de emergencia para que comiencen a más tardar una hora después de la hora especificada. Además, si habilitas la opción para recibir notificaciones por correo electrónico sobre los próximos eventos de mantenimiento de AlloyDB, recibirás una notificación automática sobre el evento en cuanto se programe. Los eventos de mantenimiento se programan con al menos una semana de anticipación.
No puedes establecer la hora de finalización de un período de mantenimiento, ya que el tiempo total requerido para un solo evento de mantenimiento puede variar según la complejidad del clúster (es decir, la cantidad de instancias del grupo de lectura que requieren actualización) y la naturaleza de la actualización. Si bien el tiempo de inactividad requerido para cualquier instancia individual puede ser muy breve, el mantenimiento completo puede llevar horas. Por este motivo, puedes usar un período de mantenimiento para controlar la hora general del día en que las instancias de tu clúster experimentan tiempo de inactividad por mantenimiento, pero no puedes especificar un período de inactividad de un minuto para ninguna instancia.
Los eventos de mantenimiento de emergencia, como la aplicación de parches de seguridad urgentes, pueden ocurrir fuera de los horarios de mantenimiento predeterminados o los períodos de mantenimiento configurados, incluso durante los períodos de rechazo del mantenimiento.
Prácticas recomendadas para el período de mantenimiento
Te recomendamos que configures períodos de mantenimiento en tus clústeres de producción y que no configures períodos de mantenimiento en tus clústeres que no son de producción. Esto se debe al siguiente orden general de eventos en torno a una actualización de mantenimiento:
- Primero, Google actualiza todos los clústeres que no tienen ventanas de mantenimiento.
- A continuación, Google programa actualizaciones para todos los clústeres que tienen ventanas de mantenimiento. Estas actualizaciones tienen al menos una semana de anticipación.
- Si habilitaste la opción para recibir comunicaciones sobre los próximos eventos de mantenimiento de AlloyDB, Google te enviará un correo electrónico con una notificación sobre el mantenimiento programado.
- Google realiza las actualizaciones de mantenimiento en los horarios programados.
Por lo tanto, una notificación de mantenimiento próximo también significa que las mismas actualizaciones ya se aplicaron a todos tus clústeres sin períodos de mantenimiento establecidos. Si dejas tus clústeres que no son de producción sin períodos de mantenimiento, puedes garantizar que reciban las actualizaciones del sistema primero y usar las notificaciones de mantenimiento próximo como un mensaje para probar o previsualizar las actualizaciones en un entorno que no sea de producción.