En este documento, se describen las actualizaciones de versión principal in situ de la base de datos de AlloyDB para PostgreSQL, que te permiten actualizar una base de datos a una versión superior sin migrar datos ni reemplazar la instancia existente.
La comunidad de PostgreSQL lanza periódicamente nuevas versiones principales que contienen funciones nuevas, mejoras de rendimiento y mejoras de seguridad. Después de que PostgreSQL lanza una versión principal nueva, AlloyDB agrega compatibilidad con la versión compatible. Para mantener actualizada tu base de datos, 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 de versión principal in situ 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 la base de datos después de la actualización.
- No es necesario que cambies los strings 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 funciones 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 funciones se pierden 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 versión principal in situ
Cuando inicias una actualización en tu clúster, AlloyDB realiza las siguientes acciones:
- Ejecuta verificaciones previas a la actualización para encontrar incompatibilidades que puedan afectar la actualización.
- Se prepara para la actualización de la versión principal, lo que incluye la creación de un clon interno del clúster.
- Hace que la instancia principal no esté disponible. Comienza el tiempo de inactividad. Las lecturas aún se pueden realizar a través de grupos de lectura.
- Inicia una copia de seguridad previa a la actualización.
- Actualiza la instancia principal.
- Hace que las instancias del grupo de lectura no estén disponibles.
- Hace que la instancia principal esté disponible. Finaliza el tiempo de inactividad.
- Inicia una copia de seguridad posterior a la actualización.
- Actualiza las instancias del grupo 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 tu clúster original. Una vez que se completa la operación de clonación, se inicia el proceso de actualización. La instancia principal no está disponible para lecturas ni escrituras hasta que se actualiza. 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 del grupo de lectura dejan de estar disponibles. Las actualizaciones se intentan en todas las instancias del grupo 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 actualizar la instancia principal, la versión del clúster se actualiza a la versión de destino y no se activan reversiones por ninguna falla después de este punto. Por ejemplo, AlloyDB no revierte el clúster si falla la actualización de una o más instancias del grupo de lectura. En estas situaciones, comunícate con el equipo de asistencia de Google Cloud CLI.
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 base 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 | Aprox. 15 minutos | Aprox. 20 minutos | Aprox. 20 minutos | Alrededor de 1 hora |
| 1 TB | Aprox. 30 minutos | Aprox. 20 minutos | Aprox. 20 minutos | Alrededor de 1 hora y 15 minutos |
| 4 TB | Alrededor de 1 hora | Aprox. 20 minutos | Aprox. 20 minutos | Alrededor de 1 hora y 45 minutos |
| 16 TB | Aprox. 3 horas | Aprox. 20 minutos | Aprox. 20 minutos | Alrededor de 3 horas y 45 minutos |
| 32 TB | Aprox. 5 horas y 30 minutos | Aprox. 20 minutos | Aprox. 20 minutos | Alrededor de 6 horas y 15 minutos |
| 64 TB | Alrededor de 11 horas | Aprox. 20 minutos | Aprox. 20 minutos | Alrededor de 12 horas |
| 128 TB | Alrededor de 21 horas y 30 minutos | Aprox. 20 minutos | Aprox. 20 minutos | Alrededor de 22 horas y 15 minutos |
Para obtener más información, consulta Actualiza una versión principal de la base de datos in situ.
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_PRECHECKPG_UPGRADE_CHECKPREPARE_FOR_UPGRADEPRIMARY_INSTANCE_UPGRADEREAD_POOL_INSTANCES_UPGRADEROLLBACK(solo en caso de falla antes de las actualizaciones del grupo de lectura)CLEANUP
Los estados posibles de estas etapas incluyen los siguientes:
NOT_STARTEDIN_PROGRESSSUCCESSFAILEDCANCEL_IN_PROGRESSCANCELLED
Cancelaciones de actualización
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 Google Cloud consola, la operación no se puede cancelar si el botón
Cancelar actualización aparece atenuado. Con Google Cloud CLI o la
API de REST, puedes
determinar si puedes cancelar la actualización verificando
upgradeClusterStatus en el estado de actualización:
- Si
cancellableestrue, puedes cancelar la actualización. - Si
cancellableesfalseo 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 el restablecimiento 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), es necesario 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.