En este documento se describen las actualizaciones de versión principal in situ de la base de datos AlloyDB para PostgreSQL, que te permiten actualizar una base de datos a una versión superior sin migrar datos ni sustituir la instancia.
La comunidad de PostgreSQL publica periódicamente nuevas versiones principales que contienen nuevas funciones, mejoras de rendimiento y medidas de seguridad. Cuando PostgreSQL lanza una nueva versión principal, AlloyDB añade 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 nuevo clúster de AlloyDB.
Para obtener más información, consulta las políticas de versiones de bases de datos.
Las actualizaciones de la 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, así como los ajustes 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.
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 comprobaciones previas a la actualización para detectar incompatibilidades que puedan afectar a la actualización.
- Prepara 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. Empieza el tiempo de descanso. Las lecturas se pueden seguir realizando 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. El tiempo de descanso ha terminado.
- Inicia una copia de seguridad posterior a la actualización.
- Actualiza las instancias del grupo de lectura.
Una vez que se hayan superado las comprobaciones previas a la actualización, tu clúster se clonará en un clúster interno del mismo proyecto. El proceso de copia de seguridad y restauración necesario para clonar el clúster tarda unos 10 minutos por terabyte de datos.
Durante la operación de clonación, puedes seguir usando tu clúster original. Una vez completada la clonación, se iniciará el proceso de actualización. La instancia principal no estará disponible para lecturas ni escrituras hasta que se actualice. El tiempo de inactividad previsto suele ser de entre 20 minutos y una hora, y depende principalmente del esquema de la base de datos y del número de objetos.
Una vez que se haya actualizado la instancia principal, las instancias del grupo de lectura dejarán de estar disponibles. Las actualizaciones se intentan en todas las instancias del grupo de lectura simultáneamente. El tiempo de inactividad será de unos 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.
Una vez que se haya actualizado la instancia principal, la versión del clúster se actualizará a la versión de destino y no se activará ninguna reversión si se produce algún error a partir de ese momento. Por ejemplo, AlloyDB no revierte el clúster si falla la actualización de una o varias instancias de grupo de lectura. En estos casos, ponte en contacto con el equipo de Asistencia de la CLI de Google Cloud.
En la siguiente tabla se muestra una estimación aproximada del tiempo que tarda en completarse la actualización en clústeres de diferentes tamaños de base de datos:
| Tamaño de la base de datos | Antes de la actualización (sin tiempo de inactividad) | Tiempo de inactividad principal | Leer el tiempo de inactividad del grupo | Duración total |
|---|---|---|---|---|
| 100 GB | Unos 15 minutos | Unos 20 minutos | Unos 20 minutos | ~1 hora |
| 1 TB | Unos 30 minutos | Unos 20 minutos | Unos 20 minutos | Alrededor de 1 hora y 15 minutos |
| 4 TB | ~1 hora | Unos 20 minutos | Unos 20 minutos | ~1 hora y 45 minutos |
| 16 TB | 3 horas aprox. | Unos 20 minutos | Unos 20 minutos | 3 horas y 45 minutos (aproximadamente) |
| 32 TB | 5 horas y media aprox. | Unos 20 minutos | Unos 20 minutos | 6 horas y 15 minutos (aproximadamente) |
| 64 TB | 11 horas aprox. | Unos 20 minutos | Unos 20 minutos | 12 horas aprox. |
| 128 TB | Unas 21 horas y 30 minutos | Unos 20 minutos | Unos 20 minutos | 22 horas y 15 minutos (aproximadamente) |
Para obtener más información, consulta Actualizar una versión principal de una base de datos in situ.
Estado de la actualización
Puedes monitorizar el estado de una operación de actualización de la versión principal de una base de datos in situ mientras está en curso.
El proceso de actualización incluye las siguientes fases:
ALLOYDB_PRECHECKPG_UPGRADE_CHECKPREPARE_FOR_UPGRADEPRIMARY_INSTANCE_UPGRADEREAD_POOL_INSTANCES_UPGRADEROLLBACK(solo en caso de fallo antes de las actualizaciones del grupo de lectura)CLEANUP
Los posibles estados de estas fases son los siguientes:
NOT_STARTEDIN_PROGRESSSUCCESSFAILEDCANCEL_IN_PROGRESSCANCELLED
Cancelaciones de la 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 haya superado ese punto, no podrás cancelar la actualización.
En la consola de Google Cloud , la operación no se puede cancelar si el botón Cancelar actualización está atenuado. Con Google Cloud CLI o la API REST, puedes determinar si puedes cancelar la actualización comprobando upgradeClusterStatus en el estado de la actualización:
- Si
cancellableestrue, puedes cancelar la actualización. - Si
cancellableesfalseo no aparece en el estado, no puedes cancelar la actualización.
Copias de seguridad automáticas antes y después de la actualización
Cuando realizas una actualización de versión principal, AlloyDB crea automáticamente las siguientes copias de seguridad continuas, donde 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 empiece la actualización. El nombre de esta copia de seguridad sigue el formato
pre-upgrade-bkp-pgXX-pgYY-<uuid>. Puedes usar esta copia de seguridad para restaurar el estado anterior a la actualización. Ten en cuenta que la restauración 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. El nombre de esta copia de seguridad sigue el formato
post-upgrade-bkp-pgXX-pgYY-<uuid>.
Una copia de seguridad continua es incremental, lo que significa que solo almacena los datos que han cambiado con respecto a la copia de seguridad continua anterior. Este enfoque reduce el tamaño y el coste (en recursos) de la copia de seguridad, y acelera el proceso de creación de copias de seguridad. Para obtener más información, consulte el artículo Información general sobre la copia de seguridad y la recuperación de datos.
Cuando veas tu lista de copias de seguridad, las copias de seguridad de la actualización se mostrarán con el tipo
CONTINUOUS. Para obtener más información, consulta Ver una lista de copias de seguridad.
Para realizar una recuperación a un momento dado (PITR), es necesario que haya disponible una copia de seguridad de una versión. La recuperación no estará disponible en el clúster actualizado hasta que se complete la copia de seguridad posterior a la actualización u otra copia de seguridad que se inicie después de actualizar la instancia principal.