Re: viewing connectioninfo used by subscriber on the publicationserver when inactive

Поиск
Список
Период
Сортировка
От Wim Bertels
Тема Re: viewing connectioninfo used by subscriber on the publicationserver when inactive
Дата
Msg-id f9e920d37c2a5101b62cb066d09134cca72193dd.camel@ucll.be
обсуждение исходный текст
Ответ на Re: viewing connectioninfo used by subscriber on the publicationserver when inactive  (Keith Fiske <keith.fiske@crunchydata.com>)
Список 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.




В списке pgsql-admin по дате отправления:

Предыдущее
От: Scott Ribe
Дата:
Сообщение: Re: viewing connectioninfo used by subscriber on the publicationserver when inactive
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: what is the best way to access cold data on another server?