Esta página se ha traducido con Cloud Translation API.

Actualizar la versión principal del servidor de un clúster

En esta página se describe el proceso de AlloyDB para PostgreSQL para actualizar las versiones del servidor de bases de datos y se explica cómo migrar los datos a un clúster compatible con una versión posterior de PostgreSQL.

Para obtener más información sobre cómo crear un clúster, consulta Crear un clúster y su instancia principal.

Compatibilidad de clústeres y versiones de PostgreSQL

Cuando creas un clúster de AlloyDB, eliges la versión principal de PostgreSQL que es compatible con las instancias del clúster. El valor predeterminado es 16.

AlloyDB realiza actualizaciones automáticas de la versión secundaria de la base de datos durante el mantenimiento periódico. Por ejemplo, si has creado un clúster con compatibilidad con la versión 16, AlloyDB mantiene los servidores de bases de datos actualizados a la última versión secundaria de 16.

Sin embargo, para actualizar una versión principal de PostgreSQL, debes planificar, probar y realizar la actualización tú mismo.

Hay varios métodos para actualizar la versión principal de tu clúster:

Una actualización de versión principal in situ que te recomendamos usar.
Migrar los datos con una exportación de datos basada en archivos.
Usar Database Migration Service.

Cada solución de actualización ofrece ventajas e inconvenientes diferentes. Consulta la siguiente tabla para ver una breve comparación que te ayudará a elegir el enfoque adecuado para tu situación.

Actualización de versión principal in situ	Exportación de datos basada en archivos	Migración con Database Migration Service
Tu clúster, incluidas las instancias de lectura, se actualiza a la versión principal superior elegida.	Las exportaciones basadas en archivos transfieren una vista general puntual de tus bases de datos.	Database Migration Service ofrece funciones de replicación continua durante el proceso de migración, lo que reduce las probabilidades de que falten datos en tu nuevo clúster.
Puedes seguir trabajando en tu clúster durante la fase previa a la actualización.	Tu aplicación experimenta un tiempo de inactividad más largo que empieza cuando exportas los datos. No puedes aceptar escrituras en la base de datos de tu clúster original hasta que el nuevo clúster esté totalmente operativo.	Tu aplicación experimentará un tiempo de inactividad más corto que empezará cuando quieras cambiar la aplicación para que use el nuevo clúster.
Durante el proceso de actualización, el tiempo de inactividad será de unos 20 minutos o más, en función de tu esquema. Después de la actualización, puedes acceder al clúster con la misma dirección IP.	Tiene un control más detallado sobre los datos que quiere incluir en la exportación y puede decidir no migrar determinadas tablas u otras entidades.	Database Migration Service migra automáticamente todas las bases de datos presentes en tus instancias y todas las instancias de tu clúster. No puedes excluir determinadas tablas o vistas de los datos de migración.
	Tu clúster puede tener habilitado el modo de aplicación de SSL.	Para realizar la migración, Database Migration Service requiere que inhabilite el modo de aplicación de SSL en el clúster de origen.

En la siguiente sección se describe el proceso para actualizar una versión principal, incluida la migración de datos.

Actualización de versión principal in situ

De esta forma, podrás disfrutar de una experiencia de actualización fluida sin tener que configurar ningún clúster adicional. Para obtener más información, consulta Actualizar una versión principal de una base de datos in situ.

Migrar mediante la exportación de datos basada en archivos

Para usar un servidor de bases de datos compatible con una versión principal superior de PostgreSQL, debes crear un clúster funcionalmente idéntico en la misma región y, a continuación, migrar tus datos a él.

Sigue estos pasos:

Crea un clúster configurado con la versión principal de compatibilidad de PostgreSQL que quieras usar. Crea el clúster en la misma región que el clúster actual.
Configura el nuevo clúster con la nueva versión principal para que coincida con la configuración del clúster actual:
1. Crea más instancias de grupo de lectura según sea necesario.
2. Crea clústeres secundarios según sea necesario.
  
  Cuando creas clústeres secundarios, no tienes que especificar un número de versión principal de PostgreSQL. AlloyDB aplica la versión de PostgreSQL del clúster principal a todos sus clústeres secundarios.
3. Actualiza las marcas de la base de datos del nuevo clúster para que coincidan con la configuración de las marcas del clúster actual.
4. Habilita las extensiones que necesiten tus aplicaciones.
Exporta tus datos del clúster antiguo a archivos mediante psql o pg_dump.
Importa los datos de los archivos al nuevo clúster.

Ahora, tus aplicaciones pueden conectarse a las instancias del nuevo clúster con sus nuevas direcciones IP.

Migrar con Database Migration Service

Puedes usar Database Migration Service para mover datos de bases de datos PostgreSQL a clústeres de AlloyDB. Database Migration Service no proporciona una configuración específica para las fuentes de datos de AlloyDB, pero AlloyDB es compatible con PostgreSQL, por lo que puedes usar la configuración diseñada para fuentes de PostgreSQL genéricas.

Esta ruta de migración no es una actualización in situ y da como resultado la creación de un nuevo clúster con una dirección IP diferente. Te recomendamos que primero clones tu clúster y realices una migración de prueba para verificar si tu aplicación es compatible con este método.

Cuestiones importantes

Antes de preparar la migración con Database Migration Service, ten en cuenta las siguientes limitaciones para asegurarte de que esta ruta de migración se adapta a tu situación de actualización.

Limitaciones

Las conexiones SSL deben estar inhabilitadas en el clúster de origen.
No se admiten instancias de AlloyDB configuradas con Private Service Connect.
No puedes realizar actualizaciones de instancias ni solicitudes de conmutación por error en el clúster de origen durante la migración. Estas operaciones pueden provocar que la tarea de migración falle.
En este caso, se aplican todas las limitaciones estándar de las migraciones de PostgreSQL a AlloyDB. Para ver la lista completa de otras limitaciones, consulta la sección Limitaciones conocidas de la documentación de Database Migration Service.

Fidelidad de la migración

No se migran determinados tipos de datos, como los objetos grandes. Para ver la lista completa de los datos admitidos, consulta la sección Fidelidad de la migración en la documentación de Database Migration Service.

Bloqueo y tiempo de inactividad de la base de datos de origen

Database Migration Service usa migraciones continuas para transferir datos a clústeres de AlloyDB. Este tipo de migración conlleva un breve bloqueo (menos de 10 segundos) de las tablas de la base de datos de origen, una a una, mientras se crea el volcado de datos inicial.

Cuando se haya completado la migración, debes detener todas las escrituras en la base de datos de origen antes de cambiar tu aplicación al nuevo clúster. Este procedimiento requiere un tiempo de inactividad. Para obtener una descripción más detallada, consulta la sección sobre migraciones continuas en la documentación de Database Migration Service.

Limitaciones de la replicación

Una vez que la tarea de migración pasa a la fase de captura de datos modificados (CDC), Database Migration Service replica continuamente los datos nuevos que se escriben en las bases de datos de origen.

En las tablas que no tienen claves principales, solo se replican las instrucciones INSERT durante la fase de CDC. Las acciones de CREATE, UPDATE o DELETE que se realicen en tablas que no tengan claves principales durante la fase de CDC deben volver a crearse manualmente en la base de datos de destino para evitar la pérdida de datos.

Antes de empezar

Enable the Database Migration Service API.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.
Enable the API

Make sure that you have the following role or roles on the project:
- One of the following:
  - Cloud AlloyDB > Cloud AlloyDB admin
  - Basic > Owner
  - Basic > Editor
- You must also have the compute.networks.list permission in the Google Cloud project you are using. To gain this permission while following the principle of least privilege, ask your administrator to grant you the Compute Engine > Compute Network User role (roles/compute.networkUser).
- Database Migration admin
Check for the roles
1. In the Google Cloud console, go to the IAM page.
  Go to IAM
2. Select the project.
3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.
Grant the roles
1. In the Google Cloud console, go to the IAM page.
  Ir a IAM
2. Selecciona el proyecto.
3. Haz clic en Conceder acceso.
4. En el campo Nuevos principales, introduce tu identificador de usuario. Normalmente, se trata de la dirección de correo de una cuenta de Google.
5. En la lista Selecciona un rol, elige un rol.
6. Para conceder más roles, haz clic en Añadir otro rol y añade cada rol adicional.
7. Haz clic en Guardar.
Asegúrate de que la red de VPC del Google Cloud proyecto que estás usando esté configurada para el acceso privado a los servicios de AlloyDB.
Decide en qué región quieres crear el clúster de destino. Todas las entidades del servicio de migración de bases de datos (perfiles de conexión, trabajos de migración) deben crearse en la misma región que el clúster de destino.
Prepara un usuario de la base de datos al que quieras conectarte con tu clúster y ejecuta instrucciones de migración en tus bases de datos de origen. Este usuario de la base de datos requiere un conjunto específico de permisos y roles. Te recomendamos que crees un usuario de base de datos y lo designes específicamente para realizar la migración.

Configurar las instancias de origen

Database Migration Service requiere una configuración específica para poder conectarse y copiar datos de tu clúster de origen al nuevo clúster de destino.

Para configurar tus instancias de origen de AlloyDB, sigue estos pasos:

Configure marcas de bases de datos en cada instancia del clúster de origen. Usa los siguientes valores:

Bandera	Valor
`alloydb.logical_decoding`	Su valor debe ser `on`.
`alloydb.enable_pglogical`	Su valor debe ser `on`.
`max_replication_slots`	Esta marca define el número máximo de ranuras de replicación que puede admitir la instancia de origen. El valor mínimo de esta marca es `50`. Calcula el valor mínimo con la siguiente fórmula: `(the number of databases in your instance) * (the number of simultaneous migration jobs you want to perform) + (slots reserved for table synchronization) + (the number of replication slots you currently use for your read replicas)` Veamos un ejemplo en el que se cumplen las siguientes condiciones: No tienes réplicas de lectura en tu fuente. Tienes 30 bases de datos en la instancia de origen principal. Quieres crear dos tareas de migración para el clúster de origen. Quieres usar 10 ranuras para la replicación de tablas. En ese caso, el número de `max_replication_slots` debe ser al menos `70`, calculado como `30 * 2 + 10 + 0`.
`max_wal_senders`	Define esta marca con un valor que sea al menos 10 más que el valor de `max_replication_slots` más el número de remitentes que ya se hayan usado en tu instancia. Por ejemplo, si asignas el valor `max_replication_slots flag` a `70` y ya usas 2 remitentes, `max_wal_senders` debe ser al menos `82` (calculado como `70 + 10 + 2 = 82`).
`max_worker_processes`	Define esta marca con un valor igual o superior al número de bases de datos de tu instancia más el número de `max_worker_processes` que ya uses. Por ejemplo, si tienes 30 bases de datos en tu instancia de origen y no usas ningún proceso de trabajador, define esta marca como `30`.

Inhabilita el modo de implementación obligatoria de SSL en todas las instancias del clúster de origen.

Configurar las bases de datos de origen

Debes instalar la extensión pglogical y conceder los permisos necesarios al usuario de la base de datos que designes como usuario de migración en todas las bases de datos de tus instancias.

Para configurar tus bases de datos, sigue estos pasos:

Conéctate a la base de datos postgres predeterminada mediante el cliente psql.
Instala la extensión pglogical ejecutando el siguiente comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Concede permisos al usuario de la base de datos de migración en todos los esquemas excepto en el esquema information y en los esquemas cuyos nombres empiecen por el prefijo pg_. Ejecuta las siguientes instrucciones:
```
GRANT USAGE on SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL TABLES in SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA_NAME to USER_NAME;
```
Haz los cambios siguientes:
- SCHEMA_NAME: el nombre de un esquema presente en tu base de datos
- USER_NAME: el nombre del usuario de la base de datos que has preparado en la sección Antes de empezar
Repite este paso con todos los esquemas de tu base de datos excepto el esquema information y los esquemas cuyos nombres empiecen por el prefijo pg_. Puedes enumerar todos los esquemas de la base de datos con el metacommando \dn.
Concede los permisos necesarios restantes. Ejecuta las siguientes instrucciones:
```
GRANT USAGE on SCHEMA pglogical to PUBLIC;
GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER_NAME;
ALTER USER USER_NAME with REPLICATION;
```
Sustituye USER_NAME por el nombre del usuario de la base de datos que has preparado en la sección Antes de empezar.
Conéctate a todas las demás bases de datos de tu instancia y repite los pasos 2, 3 y 4.
- Puedes enumerar todas las bases de datos de tu instancia con el metacommando \list.
- Puedes cambiar a otra base de datos sin restablecer la conexión de tu cliente psql con el comando \connect {database_name_here}.
Repite este procedimiento con cada instancia de tu clúster AlloyDB de origen.

Ejecutar la migración en Database Migration Service