Migrar a Managed Postgres con PeerDB

Aprenda a migrar sus datos de PostgreSQL a ClickHouse Managed Postgres con PeerDB

Esta guía ofrece instrucciones paso a paso para migrar su base de datos de PostgreSQL a ClickHouse Managed Postgres con PeerDB.

​

Requisitos previos

• Acceso a tu base de datos PostgreSQL de origen.
• Una instancia de ClickHouse Managed Postgres a la que quieras migrar tus datos.
• PeerDB instalado en una máquina. Puedes seguir las instrucciones de instalación en el repositorio de GitHub de PeerDB. Solo necesitas clonar el repositorio y ejecutar docker-compose up. Para esta guía, usaremos la UI de PeerDB, que estará disponible en http://localhost:3000 una vez que PeerDB esté en ejecución.

​

Consideraciones antes de la migración

Antes de iniciar la migración, ten en cuenta lo siguiente:

• Objetos de base de datos: PeerDB creará tablas automáticamente en la base de datos de destino según el esquema de origen. Sin embargo, algunos objetos de base de datos, como índices, restricciones y triggers, no se migran automáticamente. Tendrás que recrearlos manualmente en la base de datos de destino después de la migración.
• Cambios de DDL: Si habilitas la replicación continua, PeerDB mantendrá la base de datos de destino sincronizada con la de origen para las operaciones DML (INSERT, UPDATE, DELETE) y propagará las operaciones ADD COLUMN. Sin embargo, otros cambios de DDL (como DROP COLUMN y ALTER COLUMN) no se propagan automáticamente. Más información sobre la compatibilidad con cambios de esquema aquí
• Conectividad de red: Asegúrate de que tanto la base de datos de origen como la de destino sean accesibles desde la máquina en la que se ejecuta PeerDB. Puede que tengas que configurar reglas de firewall o la configuración del Security Group para permitir la conectividad.

​

Crear peers

Primero, debemos crear peers para las bases de datos de origen y destino. Un peer representa una conexión a una base de datos. En la UI de PeerDB, ve a la sección “Peers” haciendo clic en “Peers” en la barra lateral. Para crear un nuevo peer, haz clic en el botón + New peer.

​

Creación del peer de origen

Cree un peer para su base de datos PostgreSQL de origen completando los datos de conexión, como el host, el puerto, el nombre de la base de datos, el nombre de usuario y la contraseña. Una vez completados estos datos, haga clic en el botón Create peer para guardar el peer.

​

Creación del peer de destino

Del mismo modo, crea un peer para tu instancia de ClickHouse Managed Postgres proporcionando los datos de conexión necesarios. Puedes obtener los datos de conexión de tu instancia desde la consola de ClickHouse Cloud. Después de completar la información, haz clic en el botón Create peer para guardar el peer de destino.

Ahora deberías ver tanto el peer de origen como el peer de destino en la sección “Peers”.

​

Obtener el volcado del esquema de origen

Para replicar la configuración de la base de datos de origen en la base de datos de destino, necesitamos obtener un volcado del esquema de la base de datos de origen. Puedes usar pg_dump para crear un volcado solo del esquema de tu base de datos PostgreSQL de origen:

Instalar pg_dump

Ubuntu:

Actualiza las listas de paquetes:

sudo apt update

Instala el cliente de PostgreSQL:

sudo apt install postgresql-client

macOS:

Método 1: usar Homebrew (recomendado)

Instala Homebrew si no lo tienes:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Instala PostgreSQL:

brew install postgresql

Verifica la instalación:

pg_dump --version

pg_dump -d 'postgresql://<user>:<password>@<host>:<port>/<database>'  -s > source_schema.sql

​

Eliminar restricciones UNIQUE e índices del volcado del esquema

Antes de aplicar esto a la base de datos de destino, debemos eliminar las restricciones UNIQUE y los índices del archivo de volcado para que la ingestión de PeerDB en las tablas de destino no se vea bloqueada por estas restricciones. Esto puede hacerse con:

# Vista previa
grep -n "CONSTRAINT.*UNIQUE" <dump_file_path>
grep -n "CREATE UNIQUE INDEX" <dump_file_path>
grep -n -E "(CONSTRAINT.*UNIQUE|CREATE UNIQUE INDEX)" <dump_file_path>

# Eliminar
sed -i.bak -E '/CREATE UNIQUE INDEX/,/;/d; /(CONSTRAINT.*UNIQUE|ADD CONSTRAINT.*UNIQUE)/d' <dump_file_path>

​

Aplicar el volcado del esquema a la base de datos de destino

Después de limpiar el archivo de volcado del esquema, puedes cargarlo en tu base de datos de destino de ClickHouse Managed Postgres conectándote mediante psql y ejecutando el archivo de volcado del esquema:

psql -h <target_host> -p <target_port> -U <target_username> -d <target_database> -f source_schema.sql

Aquí, en el lado de destino, no queremos que la ingestión de PeerDB se vea bloqueada por restricciones de clave foránea. Para ello, podemos modificar el rol de destino (usado arriba en el peer de destino) para que tenga session_replication_role establecido en replica:

ALTER ROLE <target_role> SET session_replication_role = replica;

​

Crear un mirror

A continuación, debemos crear un mirror para definir el proceso de migración de datos entre los peers de origen y destino. En la UI de PeerDB, ve a la sección “Mirrors” haciendo clic en “Mirrors” en la barra lateral. Para crear un mirror nuevo, haz clic en el botón + New mirror.

1. Asigna a tu mirror un nombre que describa la migración.
2. Selecciona los peers de origen y destino que creaste anteriormente en los menús desplegables.
3. Asegúrate de que:

• Soft delete esté desactivado.
• Expande Advanced settings. Asegúrate de que Postgres type system esté habilitado y PeerDB columns esté deshabilitado.

4. Selecciona las tablas que quieres migrar. Puedes elegir tablas específicas o seleccionar todas las tablas de la base de datos de origen.

Selección de tablas

Asegúrate de que los nombres de las tablas de destino sean los mismos que los de las tablas de origen en la base de datos de destino, ya que en el paso anterior migramos el esquema tal cual.

5. Una vez configurado el mirror, haz clic en el botón Create mirror.

Deberías ver el mirror que acabas de crear en la sección “Mirrors”.

​

Espere a que termine la carga inicial

Después de crear el mirror, PeerDB iniciará la carga inicial de datos desde el origen hasta la base de datos de destino. Puede hacer clic en el mirror y, después, en la pestaña Carga inicial para supervisar el progreso de la migración inicial de datos.

Una vez completada la carga inicial, debería ver un estado que indique que la migración ha finalizado.

​

Supervisión de la carga inicial y la replicación

Si hace clic en el peer de origen, puede ver una lista de los comandos que está ejecutando PeerDB. Por ejemplo:

1. Inicialmente, ejecutamos una consulta COUNT para estimar el número de filas de cada tabla.
2. Luego ejecutamos una consulta de particionamiento con NTILE para dividir las tablas grandes en fragmentos más pequeños y hacer más eficiente la transferencia de datos.
3. Después ejecutamos comandos FETCH para obtener datos de la base de datos de origen, y luego PeerDB los sincroniza con la base de datos de destino.

​

Tareas posteriores a la migración

Estos pasos pueden variar según su caso de uso concreto y los requisitos de la aplicación. Lo importante es garantizar la coherencia de los datos, minimizar el tiempo de inactividad y validar la integridad de los datos migrados antes de completar el cambio al nuevo sistema.

Una vez completada la migración:

• Ejecute comprobaciones de validación previas al cambio

Compare las tablas principales entre el origen y el destino antes de redirigir el tráfico:

-- Comparación de recuento de filas para tablas críticas
SELECT 'public.orders' AS table_name, COUNT(*) AS row_count FROM public.orders;
SELECT 'public.customers' AS table_name, COUNT(*) AS row_count FROM public.customers;

-- Verificación rápida de los registros más recientes en tablas de alta actividad
SELECT MAX(updated_at) FROM public.orders;
SELECT MAX(id) FROM public.orders;

• Detén las escrituras en el sistema de origen

Primero, pausa las operaciones de escritura de la aplicación. Como medida de protección adicional, configura la base de datos de origen en modo de solo lectura durante el cambio:

ALTER DATABASE <source_db> SET default_transaction_read_only = on;

Si es necesario revertir los cambios, puedes volver a habilitar las escrituras:

ALTER DATABASE <source_db> SET default_transaction_read_only = off;

• Confirma que la replicación esté completamente sincronizada

Verifica que la fila más reciente de una o varias tablas con alta tasa de escritura coincida en el origen y el destino:

-- Ejecutar en origen y destino y comparar los resultados
SELECT MAX(id) AS latest_id, MAX(updated_at) AS latest_ts FROM public.orders;

• Vuelva a crear y habilite las restricciones, los índices y los triggers

Si eliminó o pospuso restricciones/índices para la ingestión, vuelva a aplicarlos ahora. Restablezca también el rol de replicación en el destino si antes lo configuró como replica:

ALTER ROLE <target_role> SET session_replication_role = origin;

# Ejemplo: aplicar un archivo SQL que contiene restricciones/índices/triggers
psql -h <target_host> -p <target_port> -U <target_user> -d <target_db> -f post_migration_objects.sql

• Restablecer las secuencias de las tablas de destino

Después de cargar los datos, alinee las secuencias con los valores actuales de las tablas:

-- Restablecimiento genérico de secuencias para todas las columnas respaldadas por serial/identity en esquemas que no son del sistema
DO $$
DECLARE r RECORD;
BEGIN
    FOR r IN
        SELECT
            n.nspname AS schema_name,
            c.relname AS table_name,
            a.attname AS column_name,
            pg_get_serial_sequence(format('%I.%I', n.nspname, c.relname), a.attname) AS seq_name
        FROM pg_class c
        JOIN pg_namespace n ON n.oid = c.relnamespace
        JOIN pg_attribute a ON a.attrelid = c.oid
        WHERE c.relkind = 'r'
            AND a.attnum > 0
            AND NOT a.attisdropped
            AND n.nspname NOT IN ('pg_catalog', 'information_schema')
    LOOP
        IF r.seq_name IS NOT NULL THEN
            EXECUTE format(
                'SELECT setval(%L, COALESCE((SELECT MAX(%I) FROM %I.%I), 0) + 1, false)',
                r.seq_name, r.column_name, r.schema_name, r.table_name
            );
        END IF;
    END LOOP;
END $$;

• Redirigir el tráfico de la aplicación

Una vez superada la validación y con las secuencias/restricciones ya en su lugar:

1. Redirige el tráfico de lectura a ClickHouse Managed Postgres.
2. Redirige el tráfico de escritura a ClickHouse Managed Postgres.
3. Supervisa los errores de la aplicación, las infracciones de restricciones y el estado de la base de datos.

• Limpiar los recursos

Una vez que estés conforme con la migración y hayas cambiado tu aplicación para que use ClickHouse Managed Postgres, puedes eliminar el mirror y los peers en PeerDB.

Slots de replicación

Si habilitaste la replicación continua, PeerDB creará un slot de replicación en la base de datos PostgreSQL de origen. Asegúrate de eliminar manualmente el slot de replicación de la base de datos de origen cuando hayas terminado la migración para evitar el uso innecesario de recursos.

​

Referencias

• Documentación de ClickHouse Managed Postgres
• Guía de PeerDB para crear CDC
• FAQ de Postgres ClickPipe (también válida para PeerDB)

​

Próximos pasos

¡Enhorabuena! Ha migrado correctamente su base de datos de PostgreSQL a ClickHouse Managed Postgres con pg_dump y pg_restore. Ya está todo listo para explorar las funciones de Managed Postgres y su integración con ClickHouse. Aquí tiene una guía de inicio rápido de 10 minutos para comenzar:

• Guía de inicio rápido de Managed Postgres