Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Dominando la Replicación de PostgreSQL: Tipos y Configuración Explicados

Domine la replicación de PostgreSQL con esta guía completa. Aprenda sobre la replicación en streaming (física) y lógica, sus casos de uso y cómo configurarlas. Asegure alta disponibilidad, recuperación ante desastres y escalabilidad de lectura para su base de datos relacional de código abierto avanzada.

46 vistas

Dominando la replicación de PostgreSQL: Tipos y configuración explicados

En el mundo de las bases de datos relacionales avanzadas de código abierto, PostgreSQL destaca por su robustez, extensibilidad y potentes características. Entre ellas, la redundancia de datos y la alta disponibilidad son primordiales para las aplicaciones de misión crítica. La replicación de PostgreSQL es el mecanismo que le permite lograr estos objetivos copiando datos de un servidor PostgreSQL (el primario) a uno o más servidores PostgreSQL adicionales (las réplicas o standbys).

Este artículo profundizará en los conceptos centrales de la replicación de PostgreSQL, explorando los diferentes tipos disponibles y proporcionando una guía práctica sobre cómo configurarlos. Comprender estos mecanismos es crucial para asegurar que sus datos estén siempre accesibles, protegidos contra fallas de hardware y que puedan manejar cargas de lectura crecientes. Cubriremos tanto la replicación por streaming como la replicación lógica, explicando sus casos de uso, ventajas y pasos de configuración.

Por qué es importante la replicación de PostgreSQL

Antes de sumergirnos en el 'cómo', es esencial entender el 'porqué'. La pérdida de datos o un tiempo de inactividad prolongado pueden tener graves consecuencias para las empresas. La replicación aborda estas preocupaciones mediante:

  • Alta Disponibilidad (HA): Si el servidor primario falla, una réplica puede ser promovida rápidamente para convertirse en el nuevo primario, minimizando el tiempo de inactividad.
  • Recuperación ante Desastres (DR): Las réplicas pueden ubicarse en diferentes ubicaciones geográficas, protegiendo sus datos de desastres específicos del sitio.
  • Escalabilidad de Lectura: La descarga de cargas de trabajo intensivas en lectura a las réplicas puede mejorar el rendimiento del servidor primario, que permanece dedicado a las operaciones de escritura.
  • Protección de Datos: La replicación actúa como una copia de seguridad continua, ofreciendo una copia de sus datos más actualizada que las copias de seguridad periódicas tradicionales.

PostgreSQL ofrece dos métodos principales de replicación: Replicación por Streaming y Replicación Lógica. Aunque ambos logran la sincronización de datos, operan bajo principios diferentes y son adecuados para distintos escenarios.

Replicación por Streaming (Replicación Física)

La replicación por streaming es la forma más común y fundamental de replicación en PostgreSQL. Funciona enviando registros de Write-Ahead Log (WAL) desde el servidor primario a una o más réplicas. Estos registros WAL representan cada cambio realizado en la base de datos. Las réplicas aplican luego estos registros WAL a sus propios archivos de datos, asegurando que permanezcan consistentes con el primario.

Tipos de Replicación por Streaming:

  1. Replicación Síncrona: En modo síncrono, el servidor primario espera la confirmación de al menos una (o un número especificado) de réplicas de que los registros WAL han sido recibidos y escritos en su búfer WAL antes de confirmar el commit de la transacción al cliente. Esto garantiza que las transacciones confirmadas existan en al menos una réplica, proporcionando el nivel más alto de consistencia de datos.

    • Pros: Garantiza la no pérdida de datos para las transacciones confirmadas en la réplica síncrona.
    • Contras: Puede introducir latencia en los commits de las transacciones, ya que el primario debe esperar la confirmación de la réplica.

  2. Replicación Asíncrona: En modo asíncrono, el servidor primario envía registros WAL a las réplicas pero no espera la confirmación antes de confirmar la transacción. El primario confirma el commit al cliente inmediatamente después de escribir el WAL localmente. Esto ofrece una menor latencia, pero conlleva un riesgo de pérdida de datos si el primario falla antes de que los registros WAL sean enviados y aplicados a la réplica.

    • Pros: Impacto mínimo en la latencia de commit de transacciones.
    • Contras: Potencial pérdida de datos si el primario falla y los registros WAL aún no han llegado a la réplica.

Configuración de la Replicación por Streaming (Ejemplo Asíncrono)

Configurar la replicación por streaming implica la configuración tanto del servidor primario como del servidor réplica. Aquí tiene una guía simplificada:

1. Configurar el Servidor Primario (postgresql.conf y pg_hba.conf)

En el servidor primario, debe habilitar el archivado WAL y las conexiones de replicación.

  • Modificaciones en postgresql.conf:

    ```ini
    wal_level = replica # or logical for logical replication
    max_wal_senders = 5 # Number of concurrent replication connections
    wal_keep_size = 512MB # Or wal_keep_segments for older versions

    For synchronous replication, add:

    synchronous_standby_names = 'replica1,replica2'

    Or for specific server name/priority:

    synchronous_standby_names = '1 (replica1), 2 (replica2)'

    archive_mode = on
    archive_command = 'cp %p /path/to/wal_archive/%f'
    `` *wal_level: Debe ser al menosreplicapara la replicación por streaming. *max_wal_senders: Especifica cuántos servidores en espera pueden conectarse simultáneamente. *wal_keep_size: Evita que los archivos WAL sean eliminados antes de que las réplicas puedan recuperarlos (una alternativa más simple aarchive_commandpara configuraciones básicas, pero se recomienda el archivado para mayor robustez). *archive_modeyarchive_command`: Cruciales para la recuperación en un momento dado (PITR) y esenciales si una réplica se queda demasiado atrás o necesita ser reconstruida.

  • Modificaciones en pg_hba.conf:

    Permita que la réplica se conecte para la replicación. Reemplace replica_ip_address con la IP real de su réplica.

    ```ini

    TYPE DATABASE USER ADDRESS METHOD

    host replication replication_user replica_ip_address/32 md5
    ```

    También deberá crear un usuario de replicación:

    sql -- On the primary server: CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'your_password';

    Después de modificar estos archivos, recargue la configuración de PostgreSQL:

    ```bash
    pg_ctl reload

    Or restart PostgreSQL if needed

    ```

2. Preparar el Servidor Réplica

Antes de iniciar la réplica, esta debe tener un directorio de datos que sea una copia del directorio de datos del primario en un momento específico. La forma más sencilla es usar pg_basebackup.

  • Detenga PostgreSQL en la réplica (si está en ejecución).

  • Realice una copia de seguridad base:

    ```bash

    Ensure PGDATA is empty or removed first

    pg_basebackup -h primary_host_ip -p 5432 -U replication_user -D /var/lib/postgresql/data/ -Fp -Xs -P
    `` *-h,-p,-U: Especifique los detalles de conexión del servidor primario. *-D: El directorio de datos para la réplica. *-Fp: El formato es simple (plain). *-Xs: Use transmisión de TSL/WAL por streaming. Equivalente a la configuraciónprimary_conninfode transmisión de WAL. *-P: Mostrar progreso. * Se le solicitará la contraseña delreplication_user`.

3. Configurar el Servidor Réplica (postgresql.conf y recovery.conf o postgresql.conf para PG12+)

  • Modificaciones en postgresql.conf (para PG12+):

    ```ini
    hot_standby = on # Allows read-only queries on the replica
    primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'

    For synchronous replication, add:

    primary_promote_delay = 10 # seconds

    Or use a trigger file mechanism

    `` *hot_standby: Habilita consultas de solo lectura en el standby (servidor en espera). *primary_conninfo`: Cadena de conexión al servidor primario.

  • recovery.conf (para versiones de PostgreSQL anteriores a la 12):

    Cree un archivo recovery.conf en el directorio de datos de la réplica con el siguiente contenido:

    ```ini
    standby_mode = 'on'
    primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'

    If using archive recovery instead of streaming, you'd specify restore_command

    restore_command = 'cp /path/to/wal_archive/%f %p'

    recovery_target_timeline = 'latest'

    ```

    Para PG12+, primary_conninfo y hot_standby se configuran directamente en postgresql.conf.

4. Iniciar el Servidor Réplica

Inicie el servicio PostgreSQL en la réplica. Se conectará al primario, recibirá los registros WAL y comenzará a sincronizarse. Puede verificar los logs para confirmación.

Consejo: Para una HA robusta, considere usar herramientas como Patroni o repmgr, que automatizan la conmutación por error y la gestión.

Replicación Lógica

La replicación lógica es una forma de replicación más flexible y granular introducida en PostgreSQL 10. En lugar de replicar bloques completos de datos o registros WAL, replica los cambios de datos basándose en su significado lógico (por ejemplo, sentencias INSERT, UPDATE, DELETE) a nivel de fila. Esto se logra decodificando los registros WAL en un flujo de cambios lógicos.

Características Clave y Casos de Uso:

  • Replicación Selectiva: Puede elegir qué tablas o incluso qué columnas replicar. Esto es muy beneficioso para mover datos de forma selectiva entre bases de datos.
  • Replicación entre Versiones: La replicación lógica puede replicar datos entre diferentes versiones principales de PostgreSQL.
  • Cambios de Esquema Selectivos: Puede replicar cambios para bases de datos o esquemas específicos, e incluso publicar solo ciertas tablas.
  • Transformación de Datos: Aunque no está incorporada, la replicación lógica proporciona una base para procesos ETL (Extraer, Transformar, Cargar) más complejos.
  • Replicación de un Primario a una Réplica que no es un clon completo: La base de datos de destino no necesita ser una copia física completa de la fuente.

Cómo Funciona:

  1. Publicador (Publisher): La base de datos de origen (primario) donde ocurren los cambios de datos. Necesita wal_level = logical. Los cambios se decodifican del WAL en un flujo lógico.
  2. Publicación (Publication): Un conjunto nombrado de tablas en el publicador cuyos cambios serán replicados.
  3. Suscriptor (Subscriber): La base de datos de destino (réplica) que recibe los cambios.
  4. Suscripción (Subscription): Una conexión en el suscriptor que se conecta al publicador y aplica los cambios de una publicación específica.

Configuración de la Replicación Lógica

1. Configurar el Publicador (Servidor Primario)

  • Modificaciones en postgresql.conf:

    ini wal_level = logical max_replication_slots = 10 # For logical replication slots max_wal_senders = 10 # Should be at least max_replication_slots

  • Crear una Publicación:

    ```sql
    -- On the publisher database:
    CREATE PUBLICATION my_publication FOR TABLE
    table1,
    table2
    WITH (publish = 'insert,update,delete');

    -- Or for all tables:
    -- CREATE PUBLICATION all_tables_pub FOR ALL TABLES;
    ```

    Recargue la configuración en el publicador.

2. Configurar el Suscriptor (Servidor Réplica)

  • Asegúrese de que existan las tablas de destino: La base de datos del suscriptor debe tener las tablas de destino con el mismo esquema que el publicador. Puede crearlas manualmente o usar pg_dump para extraer el esquema.

  • Crear una Suscripción:

    sql -- On the subscriber database: CREATE SUBSCRIPTION my_subscription CONNECTION 'host=publisher_host_ip port=5432 user=replication_user password=your_password dbname=publisher_db' PUBLICATION my_publication;

    El replication_user necesita permisos apropiados en el publicador.

    PostgreSQL creará automáticamente un slot de replicación en el publicador y comenzará a aplicar los cambios. Puede monitorear el estado de la suscripción usando pg_stat_subscription en el suscriptor.

Consejo: La replicación lógica requiere la extensión logical decoding, que suele estar integrada. Es más intensiva en recursos que la replicación por streaming, pero ofrece mayor flexibilidad.

Elección del Método de Replicación Correcto

  • Replicación por Streaming: Ideal para alta disponibilidad y recuperación ante desastres, donde se necesita una copia exacta, byte a byte, del primario. Es más sencilla de configurar para la replicación completa de la base de datos y proporciona la mejor escalabilidad de lectura para réplicas de solo lectura.
  • Replicación Lógica: Más adecuada para distribución selectiva de datos, migraciones, actualizaciones entre versiones, o cuando necesita replicar solo un subconjunto de datos. Permite escenarios más complejos como replicar a diferentes esquemas o realizar transformaciones de datos.

Conclusión

La replicación de PostgreSQL es una potente característica que permite una robusta disponibilidad, recuperación y escalabilidad de datos. Ya sea que opte por la completa duplicación de datos de la replicación por streaming o el enfoque flexible y selectivo de la replicación lógica, comprender sus mecanismos y configuraciones es clave para mantener un entorno PostgreSQL saludable y resistente. Al implementar la replicación, mejora significativamente la tolerancia a fallos y las capacidades de rendimiento de su base de datos.

Pruebe siempre a fondo su configuración de replicación, especialmente los escenarios de conmutación por error, y monitoree el retraso de replicación para asegurarse de que sus réplicas estén actualizadas. El aprendizaje continuo y la adaptación a las características en evolución de PostgreSQL consolidarán aún más su dominio de este sistema de base de datos indispensable.