Los clústeres y las instancias de AlloyDB para PostgreSQL dependen de muchos recursos internos de bajo nivel.Google Cloud Entre ellos, se incluyen las instancias de máquina virtual que actúan como nodos y balanceadores de carga de AlloyDB, así como los volúmenes de almacenamiento que contienen tus datos. Como AlloyDB es un servicio gestionado, Google mantiene actualizados estos recursos internos. De esta forma, te aseguras de que tus clústeres e instancias de AlloyDB sigan siendo fiables, eficientes 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. A estas actualizaciones las llamamos mantenimiento. Como estas actualizaciones requieren que se reinicie el nodo afectado, pueden provocar un tiempo de inactividad. Las operaciones de mantenimiento no disruptivas de AlloyDB limitan el tiempo de inactividad a menos de 1 segundo en las instancias principales y a cero segundos en los grupos de lectura. Para conseguir un tiempo de inactividad casi nulo o nulo, AlloyDB prepara un servidor de sustitución con las actualizaciones y, a continuación, cambia el servidor de la base de datos.
Motivos del mantenimiento
Las actualizaciones de mantenimiento periódicas pueden producirse por los siguientes motivos:
Nuevas funciones y correcciones de errores 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 actualizaciones de las extensiones de PostgreSQL incluidas en AlloyDB o la instalación de nuevas extensiones. Las actualizaciones también pueden incluir correcciones de errores y de seguridad, o mejoras del rendimiento.
Actualizaciones de compatibilidad de bases de datos: la comunidad de PostgreSQL publica periódicamente actualizaciones de versiones secundarias para las versiones principales compatibles de PostgreSQL. Google incorpora estas actualizaciones en AlloyDB y las aplica a tus clústeres. Para obtener más información, consulta las políticas de versiones de bases de datos.
Hora y preferencias de mantenimiento
Puedes definir ventanas de mantenimiento tanto para los clústeres de AlloyDB principales como para los secundarios. De forma predeterminada, no se define ninguna ventana de mantenimiento en un clúster de AlloyDB. El mantenimiento no urgente de un clúster de AlloyDB sin ventanas de mantenimiento configuradas se puede llevar a cabo en cualquier momento, excepto entre las 6:00 y las 22:00 de los días laborables, según la hora local de la región en la que se encuentre el clúster.
También puedes especificar una ventana de mantenimiento. Una ventana de mantenimiento define la hora y el día de la semana que prefieres para que tu clúster empiece sus eventos de mantenimiento. Por ejemplo, puedes configurar un clúster para que tenga una ventana de mantenimiento que empiece a las 11:00 los domingos (UTC).
Si defines una ventana de mantenimiento, AlloyDB programará las tareas de mantenimiento no urgentes para que empiecen como máximo una hora después de la hora especificada. Además, si aceptas recibir notificaciones por correo sobre los eventos de mantenimiento programados 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 antelación.
No puedes definir cuándo finaliza una ventana de mantenimiento. Esto se debe a que el tiempo total que requiere un evento de mantenimiento puede variar. La duración de la ventana de mantenimiento depende de la complejidad del clúster, es decir, del número de instancias del grupo de lectura que requieran actualizaciones, y de la naturaleza de la actualización. AlloyDB primero actualiza los grupos de lectura simultáneamente y, a continuación, actualiza la instancia principal.
Aunque el tiempo de inactividad que requiere una instancia puede ser breve, todo el proceso de mantenimiento suele completarse en una hora. Solo puedes definir una ventana de mantenimiento de una hora. Sin embargo, en los clústeres con varios grupos de lectura, el tiempo de inactividad puede prolongarse más allá de la ventana de una hora, ya que el mantenimiento puede empezar en cualquier momento de esa ventana (por ejemplo, en el último minuto) y durar hasta una hora. Esto significa que el tiempo de inactividad puede producirse después de la ventana de mantenimiento.
Los eventos de mantenimiento de emergencia, como los parches de seguridad urgentes, pueden producirse fuera de los horarios de mantenimiento predeterminados o de las ventanas de mantenimiento configuradas. Esto incluye los periodos de mantenimiento rechazados.