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

Vista previa — AlloyDB for PostgreSQL

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Puedes procesar los datos personales para esta función como se describe en el Anexo de Procesamiento de Datos de Cloud, sujeto a las obligaciones y restricciones que se describen en el acuerdo en virtud del cual accedes a Google Cloud. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En este documento, se describen las actualizaciones de versión principal de la base de datos de AlloyDB para PostgreSQL, que te permiten actualizar una base de datos a una versión más reciente sin migrar datos ni reemplazar la instancia existente.

Nota: La función de actualización de versión principal sin interrupciones de AlloyDB solo admite la actualización del clúster de PostgreSQL 14 a PostgreSQL 15.

La comunidad de PostgreSQL lanza periódicamente nuevas versiones principales que contienen funciones nuevas, mejoras de rendimiento y de seguridad. Después de que PostgreSQL lanza 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 de AlloyDB nuevo.

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

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

• AlloyDB retiene 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 la base de datos, después de la actualización.
• No es necesario que cambies 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.

Nota: Para verificar el proceso de actualización y comprobar si hay incompatibilidades, te recomendamos que verifiques el proceso de actualización en un clúster clonado antes de actualizar tu clúster real.

Flujo de trabajo de actualización de 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 versión principal, que incluye la creación de un clon interno del clúster.
3. Hace que la instancia principal no esté disponible. Comienza el tiempo de descanso. Las operaciones de lectura se pueden realizar a través de 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 del grupo de lectura.

Nota: Cuando realizas una actualización local de versión principal, es posible que cambien los valores predeterminados específicos de la versión de las marcas de la base de datos. Para obtener más información, consulta Configura las marcas de base de datos de una instancia.

Después de que se aprueben las verificaciones previas a la actualización, tu clúster se clonará en un clúster interno del mismo proyecto. La copia de seguridad y el restablecimiento necesarios para clonar el clúster pueden tardar un poco en completarse, según el tamaño de la base de datos. Los siguientes son ejemplos del tamaño de la base de datos y las duraciones de las copias de seguridad y los restablecimientos correspondientes:

• 1 TB tarda alrededor de 30 minutos en clonar tu clúster.
• 10 TB tarda alrededor de 2 horas en clonar tu clúster.

Durante la operación de clonación, puedes seguir usando tu clúster original. Una vez que se complete la operación de clonación, comenzará el proceso de actualización. La instancia principal no estará disponible para las operaciones de lectura y escritura 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.

Nota: Puedes seguir usando las instancias del grupo de lectura mientras se actualiza la instancia principal.

Si la actualización de 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 actualizar la instancia principal, la versión del clúster se actualiza a la versión objetivo y no se activan reversiones por fallas después de este punto. Por ejemplo, AlloyDB no revierte el clúster si fallan una o más actualizaciones de instancias de grupo de lectura. En estas situaciones, comunícate con el equipo de asistencia de Google Cloud CLI.

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 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 fallas antes de las actualizaciones del grupo de lectura)
• CLEANUP

Los estados posibles 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 cierto punto durante la actualización de la instancia principal. Una vez que se supere ese punto, no podrás 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 actualizar 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 solo almacena 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 copias de seguridad. Para obtener más información, consulta Descripción general de la copia de seguridad y recuperación de datos.

Cuando veas tu lista de copias de seguridad, las copias de seguridad de actualización se enumerarán 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 haya una copia de seguridad de una versión disponible. La recuperación no estará 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?

• Actualiza la versión principal de una base de datos de manera local.