From: | Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com> |
---|---|
To: | Massimo Ortensi <mortensi(at)unimaticaspa(dot)it> |
Cc: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: compression in replication |
Date: | 2021-06-16 14:54:08 |
Message-ID: | CAM+6J97VdKJjaU2Uwn_GYThy23q0-29c2hjRrbZZh3_8eO-oJA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Wed, 16 Jun 2021 at 13:41, Massimo Ortensi <mortensi(at)unimaticaspa(dot)it>
wrote:
> is there any way to compress the traffic for streaming replication ?
> --
>
I think this should help reduce traffic as it would decompress only when
replaying.
I have not used it, but now that you asked, I will test it out.
PostgreSQL: Documentation: 13: 19.5. Write Ahead Log
<https://www.postgresql.org/docs/current/runtime-config-wal.html#wal_compression>
Also, pg_basebackup supports gzip stream, and so does COPY but I do not see
exclusive mention of compression support in replication slot details.
But if you try having a sidecar like envoyproxy or any tcpproxy per server,
maybe communication between sidecars can be compressed but not db to
sidecar.
Gzip Compressor — envoy 1.19.0-dev-069478 documentation (envoyproxy.io)
<https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/compression/gzip/compressor/v3/gzip.proto>
(this is not pg stuff but ... )
[pg -> sidecar -> compressed wal stream] -> [sidecar -> decompress -> pg]
I have not tried any option, FYI.
--
Thanks,
Vijay
Mumbai, India
From | Date | Subject | |
---|---|---|---|
Next Message | Vijaykumar Jain | 2021-06-16 14:55:39 | Re: compression in replication |
Previous Message | Vijaykumar Jain | 2021-06-16 14:26:09 | Re: How does vacuum full works if table is partitioned? |