Se usó la API de Cloud Translation para traducir esta página.

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

En esta página, se detalla el proceso de AlloyDB para PostgreSQL para actualizar las versiones del servidor de bases de datos y se explica cómo migrar tus 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 Crea 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. De forma predeterminada, es 16.

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

Sin embargo, una actualización de versión principal de PostgreSQL requiere que planifiques, pruebes y realices la actualización por tu cuenta.

Existen varios métodos para realizar actualizaciones de la versión principal de tu clúster:

Una actualización local de la versión principal que te recomendamos usar.
Migra los datos con una exportación de datos basada en archivos.
Usa Database Migration Service.

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

Actualización in situ de la versión principal	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 instantánea única de tus bases de datos.	Database Migration Service ofrece capacidades de replicación continua durante el proceso de migración, lo que reduce las posibilidades de que falten datos en tu clúster nuevo.
Puedes seguir trabajando en tu clúster durante la etapa previa a la actualización.	Tu aplicación experimenta un tiempo de inactividad más prolongado que comienza cuando exportas los datos. No puedes aceptar escrituras en la base de datos de tu clúster original hasta que el clúster nuevo esté en pleno funcionamiento.	Tu aplicación experimenta un tiempo de inactividad más breve que comienza cuando deseas cambiar la aplicación para que use el clúster nuevo.
Durante el proceso de actualización, es posible que se produzca un tiempo de inactividad de aproximadamente 20 minutos o más, según tu esquema. Después de la actualización, puedes acceder al clúster con la misma dirección IP.	Tienes un mayor control detallado sobre qué datos incluir en tu exportación y puedes optar por no migrar ciertas tablas o 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 optar por excluir ciertas tablas o vistas de tus datos de migración.
	Tu clúster puede tener habilitado el modo de aplicación de SSL.	Para fines de migración, Database Migration Service requiere que inhabilites el modo de aplicación de SSL en el clúster de origen.

En la siguiente sección, se detalla el proceso para realizar una actualización de versión principal, incluida la migración de tus datos.

Actualización in situ de la versión principal

Esto proporciona una experiencia de actualización perfecta sin necesidad de configurar clústeres adicionales. Para obtener más información, consulta Actualiza una versión principal de la base de datos in situ.

Migra con 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, luego, migrar tus datos a él.

Lleva a cabo los pasos siguientes:

Crea un clúster configurado con la versión principal de compatibilidad de PostgreSQL que deseas usar. Crea el clúster en la misma región que el clúster actual.
Configura el clúster nuevo con la versión principal nueva para que coincida con la configuración del clúster actual:
1. Crea instancias de grupo de lectura adicionales según sea necesario.
2. Crea clústeres secundarios según sea necesario.
  
  Cuando creas clústeres secundarios, no necesitas 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 clúster nuevo para que coincidan con la configuración de marcas del clúster actual.
4. Habilita las extensiones que necesiten tus aplicaciones.
Exporta tus datos del clúster anterior a archivos con psql o pg_dump.
Importa tus datos de los archivos al clúster nuevo.

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

Migra con Database Migration Service

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

Esta ruta de migración no es una actualización en el lugar y genera la creación de un clúster nuevo 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 enfoque.

Consideraciones importantes

Antes de prepararte para migrar con Database Migration Service, ten en cuenta cuidadosamente las siguientes limitaciones para asegurarte de que esta ruta de migración se ajuste a tu situación de actualización.

Limitaciones

Las conexiones SSL deben inhabilitarse en tu clúster de origen.
No se admiten las 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 hacer que falle el trabajo de migración.
En este caso, se aplican todas las limitaciones estándar para las migraciones de PostgreSQL a AlloyDB. Para obtener la lista completa de otras limitaciones, consulta Limitaciones conocidas en la documentación de Database Migration Service.

Fidelidad en la migración

No se migran ciertos tipos de datos, como los objetos grandes. Para obtener la lista completa de los datos admitidos, consulta 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 genera un bloqueo breve (menos de 10 segundos) en las tablas de la base de datos de origen, una a la vez, a medida que se crea el volcado de datos inicial.

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

Limitaciones de la replicación

Después de que el trabajo de migración pasa a la fase de captura de datos modificados (CDC), Database Migration Service replica de forma continua los datos nuevos que se escriben en tus bases de datos de origen.

En el caso de las tablas que no tienen claves primarias, solo se replican las sentencias INSERT durante la fase de CDC. Cualquier acción de CREATE, UPDATE o DELETE que se realice en tablas que no tengan claves primarias durante la fase de CDC se debe volver a crear manualmente en la base de datos de destino para evitar la pérdida de datos.

Antes de comenzar

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 Otorgar acceso.
4. En el campo Principales nuevas, ingresa tu identificador de usuario. Esta suele ser la dirección de correo electrónico de una Cuenta de Google.
5. En la lista Seleccionar un rol, elige uno.
6. Para otorgar roles adicionales, haz clic en Agregar otro rol y agrega uno más.
7. Haz clic en Guardar.
Asegúrate de que la red de VPC del proyecto Google Cloud que estás usando esté configurada para el acceso privado a servicios de AlloyDB.
Decide en qué región quieres crear el clúster de destino. Todas las entidades de Database Migration Service (perfiles de conexión, trabajos de migración) deben crearse en la misma región que tu clúster de destino.
Prepara un usuario de base de datos al que quieras conectarte a 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 nuevo y lo designes específicamente para realizar la migración.

Configura tus 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:

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

Marcar	Valor
`alloydb.logical_decoding`	Se define en `on`.
`alloydb.enable_pglogical`	Se define en `on`.
`max_replication_slots`	Esta marca define la cantidad máxima de ranuras de replicación que puede admitir la instancia de origen. El valor mínimo para 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)` Considera 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. Deseas crear 2 trabajos de migración para el clúster de origen. Quieres usar 10 ranuras para la replicación de tablas. En ese caso, la cantidad de `max_replication_slots` debe ser al menos `70`, que se calcula como `30 * 2 + 10 + 0`.
`max_wal_senders`	Configura esta marca en, al menos, 10 más que el valor de `max_replication_slots`, además de la cantidad de remitentes que ya se usaron en tu instancia. Por ejemplo, si estableces `max_replication_slots flag` en `70` y ya usas 2 remitentes, `max_wal_senders` debe ser al menos `82` (calculado como `70 + 10 + 2 = 82`).
`max_worker_processes`	Configura esta marca en, al menos, la cantidad de bases de datos de tu instancia más la cantidad de `max_worker_processes` que ya usas. Por ejemplo, si tienes 30 bases de datos en tu instancia de origen y no usas ningún proceso de trabajador, establece esta marca en `30`.

Inhabilita el modo de aplicación de SSL en cada instancia de tu clúster de origen.

Configura tus bases de datos de origen

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

Para configurar tus bases de datos, sigue estos pasos:

Conéctate a la base de datos postgres predeterminada con el cliente psql.
Instala la extensión pglogical ejecutando el siguiente comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Otorga permisos al usuario de la base de datos de migración en todos los esquemas excepto en el esquema information y los esquemas cuyos nombres comiencen con el prefijo pg_. Ejecuta las siguientes sentencias:
```
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;
```
Reemplaza lo siguiente:
- SCHEMA_NAME: El nombre de un esquema presente en tu base de datos
- USER_NAME: Es el nombre del usuario de la base de datos que preparaste en la sección Antes de comenzar.
Repite este paso para cada esquema de tu base de datos excepto el esquema information y los esquemas cuyos nombres comiencen con el prefijo pg_. Puedes enumerar todos los esquemas de bases de datos con el metacomando \dn.
Otorga los permisos restantes necesarios. Ejecuta las siguientes sentencias:
```
GRANT USAGE on SCHEMA pglogical to PUBLIC;
GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER_NAME;
ALTER USER USER_NAME with REPLICATION;
```
Reemplaza USER_NAME por el nombre del usuario de la base de datos que preparaste en la sección Antes de comenzar.
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 metacomando \list.
- Puedes cambiar a otra base de datos sin restablecer la conexión del cliente psql con el comando \connect {database_name_here}.
Repite este procedimiento para cada instancia de tu clúster de AlloyDB de origen.

Ejecuta la migración en Database Migration Service