Re: viewing connectioninfo used by subscriber on the publication server when inactive

From: Wim Bertels <wim(dot)bertels(at)ucll(dot)be>
To: Keith Fiske <keith(dot)fiske(at)crunchydata(dot)com>
Cc: pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: viewing connectioninfo used by subscriber on the publication server when inactive
Date: 2020-05-14 14:50:28
Message-ID: f9e920d37c2a5101b62cb066d09134cca72193dd.camel@ucll.be
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Keith Fiske schreef op do 14-05-2020 om 10:34 [-0400]:
> WAL is always cluster/instance-wide. Locally generated WAL files are,
> by default, always 16MB in size no matter how little has changed. So
> if you have archive_timeout set and only a single row has changed,
> that WAL file will still be 16MB (although it will compress down very
> small if you're archiving elsewhere).
>
> How much of an impact this will be is entirely dependent on the write
> rate of your cluster. If you have very few writes you may be fine.
> But I would definitely suggest getting some monitoring in place if
> you expect to have offline subscribers for any long period of time.

this is not a typical use case,
and this server is just setup for only this purpose, there are very
little writes, but i understand your concern for other people reading
this without the proper context of this thread.

monitoring: as this was part of my original question, do you have a
suggestion for this setup?, preferably using a solution that is
available in the debian repo (apt.postgresql or debian)

>
> But, again, I would still try and rethink this strategy. Offline
> subscribers can be a very big problem if they never come back. Not
> only because you'd eventually fill up your disk, but also because
> that no longer allows PG to recycle its WAL files, or can cause
> excessive cleanup operations when that subscriber finally comes back,
> which can have big IO impacts.

as it is a demo/exercise setup with very little writes,
and was planning on using pg_cron weekly to cleanup inactive slots.

--
mvg,
Wim
--
The bone-chilling scream split the warm summer night in two, the first
half being before the scream when it was fairly balmy and calm and
pleasant, the second half still balmy and quite pleasant for those who
hadn't heard the scream at all, but not calm or balmy or even very nice
for those who did hear the scream, discounting the little period of time
during the actual scream itself when your ears might have been hearing it
but your brain wasn't reacting yet to let you know.
-- Winning sentence, 1986 Bulwer-Lytton bad fiction contest.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Jeff Janes 2020-05-14 15:26:11 Re: what is the best way to access cold data on another server?
Previous Message Scott Ribe 2020-05-14 14:40:27 Re: viewing connectioninfo used by subscriber on the publication server when inactive