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 base 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. El valor predeterminado es 15.

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

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 versión principal de tu clúster:

  1. Una actualización local de la versión principal que recomendamos usar.
  2. Migrar los datos con una exportación de datos basada en archivos
  3. 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 que elegiste. 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 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 operaciones de escritura en la base de datos en el clúster original hasta que el nuevo clúster esté completamente operativo. Tu aplicación experimenta un tiempo de inactividad más corto que comienza cuando quieres cambiarla para que use el clúster nuevo.
Se espera 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 deseas incluir en tu exportación y puedes elegir 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 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 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, incluida la migración de tus datos.

Actualización de la versión principal in situ

Esto proporciona una experiencia de actualización sin problemas 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 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:

  1. Crea un clúster que esté configurado con la versión principal de compatibilidad con PostgreSQL que deseas usar. Crea el clúster en la misma región que tu clúster actual.

  2. Configura el clúster nuevo con la nueva versión principal para que coincida con la configuración del clúster actual:

    1. Crea instancias adicionales del grupo de lectura 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.

  3. Exporta tus datos del clúster anterior a archivos con psql o pg_dump.

  4. Importa tus datos de los archivos al clúster nuevo.

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

Cómo migrar 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 específica para las fuentes de datos de AlloyDB, pero AlloyDB es compatible con PostgreSQL, por lo que puedes usar la configuración destinada a fuentes genéricas de PostgreSQL.

Esta ruta de migración no es una actualización in situ 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 cuidadosamente las siguientes limitaciones para asegurarte de que esta ruta de migración se adapte a tu caso de actualización.

Limitaciones
  • Las conexiones SSL deben estar inhabilitadas en tu 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 hacer que la tarea 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
Ciertos tipos de datos, como los objetos grandes, no se migran. Para obtener la lista completa de los datos admitidos, consulta Fiabilidad 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 los 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, 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 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

Una vez 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 sentencias 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

  1. Enable the Database Migration Service API.

    Enable the API

  2. 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 Grant access.

    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 un rol.
    6. Para otorgar funciones adicionales, haz clic en Agregar otro rol y agrega cada rol adicional.
    7. Haz clic en Guardar.
    8. Asegúrate de que la red de VPC del proyecto de Google Cloud que usas esté configurada para el acceso a servicios privados a AlloyDB.
    9. Decide en qué región deseas 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.
    10. 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 creas 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 del clúster de origen al nuevo clúster de destino.

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

    1. Configura marcas de base 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.

      Para calcular el valor mínimo, usa 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 cumplan 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 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 configuras max_replication_slots flag en 70 y ya usas 2 remitentes, max_wal_senders debe ser de al menos 82 (se calcula 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.
    2. 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 el usuario de migración en cada base de datos de tus instancias.

    Para configurar tus bases de datos, sigue estos pasos:

    1. Conéctate a la base de datos postgres predeterminada con el cliente psql.

    2. Ejecuta el siguiente comando para instalar la extensión pglogical:

      CREATE EXTENSION IF NOT EXISTS pglogical;

    3. 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 comienzan con 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;

      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 comienzan con el prefijo pg_. Puedes obtener una lista de todos los esquemas de bases de datos con el metacomando \dn.

    4. Otorga 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;

      Reemplaza USER_NAME por el nombre del usuario de la base de datos que preparaste en la sección Antes de comenzar.

    5. 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}.

    6. Repite este procedimiento para cada instancia de tu clúster de AlloyDB fuente.

    Ejecuta la migración en Database Migration Service

    Lleva a cabo los pasos siguientes:

    1. Crea un perfil de conexión fuente para tu clúster de AlloyDB. Usa los siguientes valores:

      • Motor de base de datos: Selecciona PostgreSQL.
      • Nombre de host o IP: Usa la dirección IP de la instancia principal de tu clúster.
      • Nombre de usuario o contraseña: Ingresa las credenciales del usuario de la base de datos que preparaste en la sección Antes de comenzar.
      • Puerto: Ingresa 5432.
      • Región: Selecciona la región en la que se encuentra tu clúster de destino.
      • Tipo de encriptación: Selecciona Ninguna.

    2. Crea y ejecuta el trabajo de migración.

      Puedes crear tu nuevo clúster de AlloyDB con anticipación o hacer que Database Migration Service lo cree por ti durante la configuración del trabajo de migración. Para obtener más información, consulta la descripción general de los trabajos de migración en la documentación de Database Migration Service.

      Si deseas que Database Migration Service cree el clúster de destino por ti durante la configuración del trabajo de migración, sigue los pasos que se indican en el procedimiento Crea un trabajo de migración para una instancia de destino nueva.

      Si deseas crear el clúster de destino fuera de Database Migration Service, sigue los pasos del procedimiento Crea un trabajo de migración para una instancia de destino existente.

    3. Cuando el estado de tu trabajo de migración cambie a CDC, promociona el trabajo de migración. Puedes verificar el estado del trabajo de migración en la página de descripción general de la migración. Consulta Cómo revisar un trabajo de migración en la documentación de Database Migration Service.

      Esta acción hace que el clúster de destino salga del modo de inicio (es decir, el clúster de destino de AlloyDB ya no está en estado de solo lectura).

    4. (Opcional) Verifica si faltan instrucciones en las tablas que no tienen claves primarias.

      Si tus bases de datos de AlloyDB de origen contienen tablas que no tienen claves primarias, es posible que debas migrar manualmente las instrucciones UPDATE o DELETE que falten. Consulta Cómo migrar operaciones UPDATE y DELETE para clave primaria no primarias en la documentación de Database Migration Service.

    5. Cambia tu aplicación al clúster nuevo. Ahora tus aplicaciones pueden conectarse a las instancias del clúster nuevo en sus direcciones IP nuevas.