Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

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

Actualizar tu clúster de AlloyDB para PostgreSQL a una versión principal posterior de PostgreSQL te permite usar las funciones de base de datos, las mejoras de rendimiento y las actualizaciones de seguridad más recientes. Puedes actualizar la versión principal de un clúster in situ o migrar tus datos a un clúster que ejecute 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 versiones de clústeres y 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 17.

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 17, AlloyDB mantiene los servidores de bases de datos actualizados a la versión secundaria más reciente de la 17.

Sin embargo, una actualización de la 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 versiones principales de tu clúster:

Una actualización de versión principal in situ que 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 de la 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 mueven 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 la posibilidad de que falten datos en tu clúster nuevo.
Puedes seguir trabajando en tu clúster durante la etapa previa a la actualización.	La aplicación experimenta un tiempo de inactividad más largo que comienza cuando exportas los datos. No puedes aceptar escrituras de bases de datos en tu clúster original hasta que el nuevo clúster esté completamente operativo.	Tu aplicación experimenta un tiempo de inactividad más breve que comienza cuando deseas cambiar la aplicación para usar el clúster nuevo.
Puedes esperar un tiempo de inactividad de aproximadamente 20 minutos o más durante el proceso de actualización, 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 los datos que se incluirán en la exportación y puedes elegir no migrar ciertas tablas o algunas 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 elegir excluir ciertas tablas o vistas de tus datos de migración.
Tu clúster puede tener habilitado el modo de aplicación forzosa de SSL.	Tu clúster puede tener habilitado el modo de aplicación forzosa de SSL.	Para la migración, Database Migration Service requiere que inhabilites el modo de aplicación forzosa 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, lo que incluye la migración de tus datos.

Actualización de la versión principal in situ

Una actualización local actualiza tu clúster existente sin necesidad de configurar clústeres adicionales. Para obtener más información, consulta Actualiza la versión principal de una base de datos de manera local.

Migra con la exportación de datos basada en archivos

Para usar un servidor de base de datos compatible con una versión principal más alta de PostgreSQL, debes crear un clúster idéntico desde el punto de vista funcional en la misma región y, luego, migrar tus datos a él.

Lleva a cabo los pasos siguientes:

Crea un clúster que esté configurado con la versión principal de compatibilidad con PostgreSQL que quieras 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 grupos 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 las 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 los datos de los archivos al clúster nuevo.

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

Migra con Database Migration Service

Puedes usar Database Migration Service para mover datos de bases de datos de PostgreSQL a clústeres de AlloyDB. Database Migration Service no proporciona una configuración dedicada específicamente para 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 local 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, considera con atención las siguientes limitaciones para asegurarte de que esta ruta de migración se ajuste a tu situación de actualización.

Limitaciones

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 el trabajo de migración falle.
Todas las limitaciones estándar para las migraciones de PostgreSQL a AlloyDB se aplican a esta situación. 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 algunos tipos de datos, como los objetos grandes. Para obtener la lista completa de los datos compatibles, 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 mover 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 por una, a medida que se crea el volcado de datos inicial.

Cuando se complete la migración, deberás detener todas las operaciones de escritura en la base de datos de origen antes de poder cambiar tu aplicación al clúster nuevo. Este procedimiento requiere un 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 escritos en tus bases de datos de origen.

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

Antes de comenzar

Habilita la API de Database Migration Service si aún no está habilitada.
Roles necesarios para habilitar las APIs
Para habilitar las APIs, necesitas el permiso serviceusage.services.enable. Si creaste el proyecto, es probable que ya tengas este permiso a través del rol de propietario (roles/owner). De lo contrario, puedes obtenerlo a través del rol de administrador de Service Usage (roles/serviceusage.serviceUsageAdmin). Obtén información para otorgar roles.
Habilitar la API

Asegúrate de tener los siguientes roles en el proyecto:
- Uno de los siguientes:
  - AlloyDB > Administrador de AlloyDB
  - Básico > Propietario
  - Básico > Editor
- También debes tener el permiso compute.networks.list en el proyecto de Google Cloud que estás usando. Para obtener este permiso mientras sigues el principio de privilegio mínimo, pídele a tu administrador que te otorgue el rol de Compute Engine > Usuario de red de Compute (roles/compute.networkUser).
- Administrador de Database Migration
Verifica los roles
1. En la consola de Google Cloud , dirígete a la página IAM.
  Ir a IAM
2. Selecciona el proyecto.
3. En la columna Principal, busca todas las filas que te identifiquen a ti o a un grupo en el que se te incluya. Para saber en qué grupos estás incluido, comunícate con tu administrador.
4. Para todas las filas en las que se te especifique o se te incluya, verifica la columna Rol para ver si la lista de roles incluye los roles necesarios.
Otorga los roles
1. En la consola de Google Cloud , dirígete a la página IAM.
  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. Haz clic en Selecciona un rol y, luego, busca el rol.
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 nube privada virtual (VPC) en el proyecto de Google Cloud que usas esté configurada para el acceso privado a servicios a AlloyDB.
Decide en qué región quieres crear tu 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 el clúster de destino.
Prepara un usuario de base de datos que quieras conectar a tu clúster y ejecuta sentencias 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 base de datos en cada instancia de tu clúster de origen. Usa los siguientes valores:

Marca	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 that you use for your read replicas)` Considera un ejemplo en el que se cumple lo siguiente: No tienes réplicas de lectura en tu fuente. Tienes 30 bases de datos en la instancia de origen principal. Quieres 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 de al menos `70`, calculada como `30 * 2 + 10 + 0`.
`max_wal_senders`	Establece esta marca en, al menos, 10 más que el valor de `max_replication_slots` más la cantidad de remitentes que ya se usaron en tu instancia. Por ejemplo, si estableces la marca `max_replication_slots` en `70` y ya usas 2 remitentes, `max_wal_senders` debe ser al menos `82` (calculado como `70 + 10 + 2 = 82`).
`max_worker_processes`	Establece 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 forzosa 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 predeterminada de postgres con el cliente de psql.
Instala la extensión pglogical con 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 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: Es 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 la base 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 de psql con el comando \connect DATABASE_NAME.
Repite este procedimiento para cada instancia de tu clúster de AlloyDB de origen.

Ejecuta la migración en Database Migration Service