La "replicación de transmisión" se refiere al envío continuo de registros WAL a través de una conexión TCP / IP entre el maestro y la réplica, utilizando el protocolo walsender a través de replicationconexiones. El maestro lee su propio WAL pg_xlogy lo envía a la réplica a pedido. Está configurado con una primary_conninfodirectiva recovery.confy pg_hba.confentradas en el maestro para permitir replicationconexiones. También necesita wal_keep_segmentsy algunas otras opciones cubiertas en los documentos.
El "envío de registros" se refiere al envío periódico de registros WAL como archivos WAL completos a través de un protocolo de transferencia de archivos a una ubicación de archivo desde donde la réplica puede recuperarlos. Está configurado con una restore_commanddirectiva en recovery.confy una archive_commanden el maestro. A PostgreSQL no le importa dónde están los archivos o cómo se transfieren, solo que los archive_commandcoloca allí y restore_commandobtiene el archivo requerido; Esto permite la construcción de sistemas como PgBarman y WAL-E.
La replicación de transmisión no tiene tanto retraso, ya que los registros se envían a medida que se generan. Sin embargo, requiere que tanto el maestro como la réplica estén en línea y puedan comunicarse directamente. También requiere que la réplica se mantenga lo suficientemente bien como para que el maestro todavía tenga copias en disco del WAL que necesita la réplica, y generalmente requiere que dedique un pg_xlogespacio adicional para retener WAL adicional para la réplica.
La replicación de envío de registros tiene más retraso porque la réplica solo ve WAL una vez que se envía un archivo completo. Sin embargo, puede funcionar incluso cuando el maestro y la réplica no pueden comunicarse directamente a través de TCP / IP mediante el uso de una ubicación de almacenamiento compartido. Continúa funcionando incluso si la réplica está inactiva por un tiempo, porque el maestro habrá descartado el WAL pg_xlogsolo después de archivarlo, por lo que el WAL todavía está en el archivo y puede ser utilizado por la réplica aunque el maestro no pueda enviarlo transmitiendo más. Tenga en cuenta que archive_commandnunca se rinde, por lo que pg_xlogpuede llenarse si el archivo falla; por esa razón, es mejor archivar en una ubicación confiable y luego hacer que el servidor de réplica obtenga de esa ubicación.
En general, combina los dos, es decir, usa ambos. En ese caso, la replicación de transmisión se usa cuando todo va bien. Si la réplica se queda demasiado atrás y el maestro ha descartado los xlogs que requiere, surge un problema de conectividad, etc., entonces la réplica cambiará a WAL de lectura archivada hasta que se recupere. Periódicamente volverá a intentar cambiar a transmisión hasta que tenga éxito.
Si solo va a usar uno, use el envío de registros, ya que la replicación de transmisión sin respaldo de envío de registros es (hasta PostgreSQL 9.4) potencialmente propensa a un retraso de replicación que causa fallas que obligan a reconstruir una réplica.
PostgreSQL 9.4 cambia esto un poco, porque la replicación de transmisión ahora puede usar "ranuras de replicación". Eso le permite al maestro realizar un seguimiento de cuánto WAL necesita una réplica y evitar tirarla hasta que la réplica la haya reproducido. Por lo tanto, no es necesario wal_keep_segmentssi usa una ranura de replicación (no la predeterminada).
Consulte mi artículo sobre las ranuras de replicación de transmisión en PostgreSQL 9.4 .
9.4 también presenta las bases para la replicación lógica de transmisión , que es otro mecanismo, diseñado para su uso por sistemas de replicación lógica como Londiste, Slony-I, y la nueva característica de replicación multidireccional asíncrona bidireccional .