Descripción general de la actualización local de la versión principal de la base de datos

Para adoptar nuevas funciones de PostgreSQL, mejoras de rendimiento y mejoras de seguridad sin migrar datos ni cambiar las cadenas de conexión de la aplicación, puedes realizar una actualización de versión principal in situ en tu clúster de AlloyDB para PostgreSQL.

La comunidad de PostgreSQL lanza periódicamente nuevas versiones principales que contienen nuevas funciones y mejoras de rendimiento y seguridad. Después de que PostgreSQL lance una nueva versión principal, AlloyDB agrega compatibilidad con la versión compatible. Para mantener tu base de datos actualizada, puedes actualizar tu clúster de AlloyDB a una versión principal superior. Puedes actualizar tu clúster con esta función de actualización in situ o migrando tus datos a un clúster nuevo de AlloyDB.

Para obtener más información, consulta Políticas de versiones de bases de datos.

Las actualizaciones locales de versión principal son una forma eficiente de actualizar la versión principal de tu clúster por los siguientes motivos:

  • AlloyDB conserva los detalles del clúster y de la instancia, y la configuración de la base de datos, como el nombre de la instancia, la dirección IP y las marcas de base de datos, después de la actualización.
  • No es necesario cambiar las cadenas de conexión de la aplicación.
  • Todas las instancias del clúster (principal y grupo de lectura) se actualizan como parte de la misma operación.

Además, no se conservan las membresías de roles con otorgantes inexistentes (membresías huérfanas). Si algún clúster contiene membresías huérfanas en el catálogo pg_auth_members, estas membresías de rol se perderán después de la actualización. Para obtener más información, consulta Prepara el clúster para una actualización de versión principal.

Flujo de trabajo de actualización de la versión principal in situ

Cuando inicias una actualización en tu clúster, AlloyDB realiza las siguientes acciones:

  1. Ejecuta verificaciones previas a la actualización para encontrar incompatibilidades que puedan afectar la actualización.
  2. Se prepara para la actualización de la versión principal, que incluye la creación de una clonación interna del clúster.
  3. Hace que la instancia principal no esté disponible. Comienza el tiempo de descanso. Las lecturas se pueden seguir realizando a través de los grupos de lectura.
  4. Inicia una copia de seguridad previa a la actualización.
  5. Actualiza la instancia principal.
  6. Hace que las instancias del grupo de lectura no estén disponibles.
  7. Hace que la instancia principal esté disponible. Finaliza el tiempo de descanso.
  8. Inicia una copia de seguridad posterior a la actualización.
  9. Actualiza las instancias de grupos de lectura.

Después de que se aprueban las verificaciones previas a la actualización, tu clúster se clona en un clúster interno en el mismo proyecto. La copia de seguridad y el restablecimiento necesarios para clonar el clúster tardan aproximadamente 10 minutos por terabyte de datos.

Durante la operación de clonación, puedes seguir usando el clúster original. Una vez que se completa la operación de clonación, comienza el proceso de actualización. La instancia principal no está disponible para lecturas ni escrituras hasta que se actualice. El tiempo de inactividad esperado suele ser de 20 minutos a una hora y depende principalmente del esquema de la base de datos y de la cantidad de objetos.

Después de actualizar la instancia principal, las instancias de grupo de lectura dejan de estar disponibles. Las actualizaciones se intentan en todas las instancias de grupos de lectura de forma simultánea. Se espera que el tiempo de inactividad dure aproximadamente 20 minutos.

Si la actualización de la versión principal falla en cualquier paso antes de que se actualice la instancia principal, AlloyDB revierte automáticamente todos los cambios.

Después de que se actualiza la instancia principal, la versión del clúster se actualiza a la versión de destino y no se activan reversiones para ninguna falla después de este punto. Por ejemplo, AlloyDB no revierte el clúster si fallan una o más actualizaciones de instancias de grupos de lectura. En estas situaciones, comunícate con el equipo de Google Cloud asistencia.

En la siguiente tabla, se proporciona una estimación aproximada del tiempo que tarda en completarse la actualización para clústeres de diferentes tamaños de bases de datos:

Tamaño de la base de datos Actualización previa (sin tiempo de inactividad) Tiempo de inactividad principal Tiempo de inactividad del grupo de lectura Duración total
100 GB ~15 minutos ~20 minutos ~20 minutos Alrededor de 1 hora
1 TB Aprox. 30 minutos ~20 minutos ~20 minutos ~1 hora y 15 minutos
4 TB Alrededor de 1 hora ~20 minutos ~20 minutos ~1 hora y 45 minutos
16 TB Aprox. 3 horas ~20 minutos ~20 minutos ~3 horas y 45 minutos
32 TB Aprox. 5 horas y 30 minutos ~20 minutos ~20 minutos ~6 horas y 15 minutos
64 TB Aprox. 11 horas ~20 minutos ~20 minutos Aprox. 12 horas
128 TB ~21 horas y 30 minutos ~20 minutos ~20 minutos ~22 horas y 15 minutos

Para obtener más información, consulta Actualiza la versión principal de una base de datos de manera local.

Estado de actualización

Puedes supervisar el estado de una operación de actualización de la versión principal de la base de datos in situ mientras está en curso.

El proceso de actualización incluye las siguientes etapas:

  • ALLOYDB_PRECHECK
  • PG_UPGRADE_CHECK
  • PREPARE_FOR_UPGRADE
  • PRIMARY_INSTANCE_UPGRADE
  • READ_POOL_INSTANCES_UPGRADE
  • ROLLBACK(solo en caso de falla antes de las actualizaciones del grupo de lectura)
  • CLEANUP

Los posibles estados de estas etapas incluyen los siguientes:

  • NOT_STARTED
  • IN_PROGRESS
  • SUCCESS
  • FAILED
  • CANCEL_IN_PROGRESS
  • CANCELLED

Cancelaciones de actualizaciones

Puedes cancelar la operación de actualización hasta un punto determinado durante la actualización de la instancia principal. Una vez que se cruza ese punto, no puedes cancelar una actualización.

En la consola de Google Cloud , la operación no se puede cancelar si el botón Cancelar actualización está inhabilitado. Con Google Cloud CLI o la API de REST, puedes determinar si puedes cancelar la actualización verificando upgradeClusterStatus en el estado de la actualización:

  • Si cancellable es true, puedes cancelar la actualización.
  • Si cancellable es false o falta en el estado, no puedes cancelar la actualización.

Copias de seguridad automáticas previas y posteriores a la actualización

Cuando realizas una actualización de versión principal, AlloyDB crea automáticamente las siguientes copias de seguridad continuas, en las que XX es la versión principal de origen y YY es la versión principal de destino.

  • La copia de seguridad previa a la actualización se crea inmediatamente antes de que comience la actualización. Esta copia de seguridad se nombra con el formato pre-upgrade-bkp-pgXX-pgYY-<uuid>. Puedes usar esta copia de seguridad para restablecer el estado anterior a la actualización. Ten en cuenta que el restablecimiento no es una operación in situ y que crea un clúster nuevo.
  • La copia de seguridad posterior a la actualización se crea después de que se actualiza la instancia principal. Esta copia de seguridad se nombra con el formato post-upgrade-bkp-pgXX-pgYY-<uuid>.

Una copia de seguridad continua es incremental, lo que significa que la copia de seguridad almacena solo los datos que cambiaron en relación con la copia de seguridad continua anterior. Este enfoque reduce el tamaño y el costo (en recursos) de la copia de seguridad, y acelera el proceso de creación de la copia de seguridad. Para obtener más información, consulta Descripción general de la copia de seguridad y la recuperación de datos.

Cuando ves tu lista de copias de seguridad, las copias de seguridad de actualización se enumeran con el tipo CONTINUOUS. Para obtener más información, consulta Visualiza una lista de copias de seguridad.

Para realizar la recuperación de un momento determinado (PITR), se requiere que esté disponible una copia de seguridad de una versión. La recuperación no está disponible en el clúster actualizado hasta que se complete la copia de seguridad posterior a la actualización o cualquier otra copia de seguridad que se inicie después de que se actualice la instancia principal.

¿Qué sigue?