En este documento, se describen las actualizaciones locales de la versión principal 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.
Periódicamente, la comunidad de PostgreSQL lanza nuevas versiones principales que contienen nuevas funciones, mejoras de rendimiento y mejoras 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 nuevo clúster de AlloyDB.
Para obtener más información, consulta las 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 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.
Flujo de trabajo de actualización in situ de la versión principal
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 descanso. Las lecturas se pueden seguir realizando a través de los 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 descanso.
- Inicia una copia de seguridad posterior a la actualización.
- Actualiza las instancias del grupo de lectura.
Después de que se aprueben las verificaciones previas a la actualización, se clonará tu clúster en un clúster interno del 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 complete la operación de clonación, comenzará el proceso de actualización. La instancia principal no está disponible para lecturas ni escrituras hasta que se actualiza. 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 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 de 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 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 | Aproximadamente 15 minutos | 20 minutos aprox. | 20 minutos aprox. | Alrededor de 1 hora |
| 1 TB | 30 minutos aprox. | 20 minutos aprox. | 20 minutos aprox. | Alrededor de 1 hora y 15 minutos |
| 4 TB | Alrededor de 1 hora | 20 minutos aprox. | 20 minutos aprox. | Aproximadamente 1 hora y 45 minutos |
| 16 TB | Aprox. 3 horas | 20 minutos aprox. | 20 minutos aprox. | Aprox. 3 horas y 45 minutos |
| 32 TB | Aprox. 5 horas y 30 minutos | 20 minutos aprox. | 20 minutos aprox. | Aprox. 6 horas y 15 minutos |
| 64 TB | Aprox. 11 horas | 20 minutos aprox. | 20 minutos aprox. | Aprox. 12 horas |
| 128 TB | Aprox. 21 horas y 30 minutos | 20 minutos aprox. | 20 minutos aprox. | Aprox. 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 local de versión principal de la base de datos 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 posibles estados de estas etapas incluyen los siguientes:
NOT_STARTEDIN_PROGRESSSUCCESSFAILEDCANCEL_IN_PROGRESSCANCELLED
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 la actualización.
En la consola Google Cloud , la operación no se puede cancelar si el botónCancelar 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
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, 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 previo 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 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 copias de seguridad. Para obtener más información, consulta la Descripción general de la copia de seguridad y 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), debe haber 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.