From: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
---|---|
To: | Ben Chobot <bench(at)silentmedia(dot)com> |
Cc: | Sascha Zenglein <zenglein(at)gessler(dot)de>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Reducing bandwidth usage of database replication |
Date: | 2022-11-04 09:20:38 |
Message-ID: | CANbhV-FGa-yyr8VprR+=Psk70vFT937sWiG=jc-TgNi-rm+QKQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 3 Nov 2022 at 15:28, Ben Chobot <bench(at)silentmedia(dot)com> wrote:
> I want to use the postgres-native logical replication to have multiple clients receive and send data to a central database.
> Real-time is far less important than network usage, and with my current test setup it appears both instances communicate frequently if a subscription is active, even if nothing is happening.
>
> Is there a good way to reduce data usage, for example by limiting the amount of keep-alive messages? One database will likely be idle most of the time.
Keep-alive messages are the largest concern on an otherwise quiet link.
Probably makes sense to let the connection time out, then set a large
wal_retrieve_retry_interval, so it doesn't immediately reconnect.
> It sounds like you are trying to use logical replication to give yourself a multi-master database setup, and that you've squeezed as much optimization as you can from logical replication and found it to be unworkable. If that's a fair assessment, you might look into something like bucardo instead. I haven't done the network comparison but it is a different solution that might meet your goals.
The overhead of Bucardo has been measured as being more than 3x that
of logical replication.
--
Simon Riggs http://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Sascha Zenglein | 2022-11-04 09:25:44 | AW: Reducing bandwidth usage of database replication |
Previous Message | Thomas Kellerer | 2022-11-04 09:19:23 | Calculating average block write time |