Transmisión de PostgreSQL versus replicación basada en archivos (en términos de comportamiento y configuración del servidor)

Estoy tratando de comprender los mejores usos de la replicación PostgreSQL y cómo funciona para poder solucionar problemas en un entorno de producción.

Me cuesta entender las diferencias entre estos 2 tipos de replicación en términos de (1) Configuración (2) Cómo funcionan los 2 servidores Maestro / Esclavo en cada escenario

La replicación en PostgreSQL (9.2+) es esencialmente archivos XLOG de 16 MB de tamaño (dependiendo de la configuración de frecuencia para crear cada archivo) se están creando en Master y se envían por algún método al Slave.

Mi configuración (para fines de esta pregunta)

Configuración de Postgresql.conf en Master
archive_command = 'rsync -av% p postgres @ [SlaveIP]: [wal_archive_folder] /% f'

Configuración de Recovery.conf en Slave para leer los archivos de registro
restore_command = 'cp [wal_archive_folder] /% f \ "% p \"'
primary_conninfo = 'host = [MasterIP] port = 5432 user = postgres'

Mi pregunta es ¿qué parte de esta configuración hace que esta replicación de "transmisión" versus "envío de registros"? Mi maestro está configurado para usar rsync para enviar registros al esclavo (¿se está enviando este registro?) Mi esclavo está configurado para poder conectarse al maestro en recovery.conf (¿se trata de transmisión?)

Segunda parte de la pregunta: ¿qué está pasando? Entiendo que hay otro protocolo en PostgreSQL a través de WAL_sender y WAL_receiver. Pero no tengo claro si esto se usa solo para transmisión y, de ser así, ¿cómo se usa rsync en el Master?

:) ¡¡Gracias!! Y perdón si esta es una pregunta obvia. He estado leyendo un montón de blogs / libros pero me ha costado mucho entenderlo. El wiki de Postgres es tan profundo que lleva mucho tiempo superarlo (y tengo plazos)

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 .