Los clústeres y las instancias de AlloyDB dependen de muchos recursos internos de nivel inferior deGoogle Cloud . Estos incluyen las instancias de máquina virtual (VM) que funcionan como nodos y balanceadores de cargas de AlloyDB, y los volúmenes de almacenamiento que contienen tus datos. Debido a que AlloyDB es un servicio administrado, Google se encarga de mantener estos recursos internos actualizados. Esto ayuda a garantizar que tus instancias y clústeres de AlloyDB permanezcan confiables, eficaces y seguros.
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. Para lograr este tiempo de inactividad cercano a cero y cero, se prepara un servidor de reemplazo con las actualizaciones y, luego, se cambia el servidor de la base de datos. Como puedes ver en los registros, el tiempo de operación es más largo que el tiempo de inactividad.
Motivos del mantenimiento
Las actualizaciones de mantenimiento pueden ocurrir por los siguientes motivos:
Nuevas funciones de AlloyDB Para lanzar funciones nuevas, Google debe actualizar el software de AlloyDB que se ejecuta en los nodos de tu clúster. Esto también puede implicar actualizar las extensiones de PostgreSQL que se incluyen con AlloyDB o instalar extensiones nuevas.
Actualizaciones de compatibilidad de la base de datos. La comunidad de PostgreSQL publica actualizaciones de versiones secundarias con frecuencia 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.
Horarios y períodos de mantenimiento
Puedes configurar períodos de mantenimiento para los clústeres primarios y secundarios de AlloyDB. De forma predeterminada, el mantenimiento no de emergencia de un clúster de AlloyDB puede ocurrir en cualquier momento, excepto entre las 6 a.m. y las 10 p.m. de lunes a viernes, en la hora local de la región en la que se encuentra el clúster.
Si tu clúster funciona mejor con un horario de mantenimiento distinto del predeterminado, puedes especificar un período de mantenimiento. Un período de mantenimiento define la hora preferida, en términos de hora del día y día de la semana, para que el 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 futuros eventos de mantenimiento no urgentes 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 necesario para cualquier instancia individual puede ser muy breve, el mantenimiento completo puede tardar horas. Por este motivo, puedes usar un período de mantenimiento para controlar el horario general del día en el que las instancias de tu clúster experimentan un tiempo de inactividad por mantenimiento, pero no puedes especificar un período de inactividad exacto para ninguna instancia.
Los eventos de mantenimiento de emergencia, como la aplicación de parches de seguridad urgentes, pueden ocurrir fuera de los tiempos de mantenimiento predeterminados o de los períodos de mantenimiento configurados.
Prácticas recomendadas para los períodos 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 sean 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.
- Luego, Google programa actualizaciones para todos los clústeres que sí tengan ventanas de mantenimiento. Estas actualizaciones tienen al menos una semana de tiempo de preparación.
- Si habilitaste la recepción de comunicaciones sobre los próximos eventos de mantenimiento de AlloyDB, Google te enviará una notificación por correo electrónico 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 configurados. Si dejas tus clústeres que no son de producción sin períodos de mantenimiento, puedes garantizar que reciban primero las actualizaciones del sistema y usar las notificaciones de mantenimiento próximo como una indicación para probar o obtener una vista previa de las actualizaciones en un entorno que no sea de producción.