From: | Mark Steben <mark(dot)steben(at)drivedominion(dot)com> |
---|---|
To: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Another streaming replication question |
Date: | 2018-11-06 17:13:18 |
Message-ID: | CADyzmyys52hHwdYXAx3FPeTHuPk3V_ewL2bCoOXNfRieeRqPjA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Good morning,
Thank you all for your responses to my questions about streaming/cascading
replication. I have them ironed out and running on three postgres 9.4
sandbox servers.
My question is not 'how to ' but more 'best practices'. We currently have
hot standby non-streaming replication with one master serving two standbys
in parallel. We wish to convert
to streaming replication. My concern is that the logshipping load can be
quite high - up to 40 16MB logs per minute (during off-hours maintenance).
In our current hot standby
environment the logs can queue up on the master side during this period -
eventually, during times of lower load they do catch up. So, a couple
questions:
1. Can streaming replication work in this high-load situation?
2. What, if anything, can I do to make it work better? Perhaps convert
to cascade? Master -->standby1 ---> standby2
I have attached the postgres.conf file for our master for reference.
Any insights welcome. Thank you.
--
*Mark Steben*
Database Administrator
@utoRevenue <http://www.autorevenue.com/> | Autobase
<http://www.autobase.net/>
CRM division of Dominion Dealer Solutions
95D Ashley Ave.
West Springfield, MA 01089
t: 413.327-3045
f: 413.383-9567
www.fb.com/DominionDealerSolutions
www.twitter.com/DominionDealer
www.drivedominion.com <http://www.autorevenue.com/>
Attachment | Content-Type | Size |
---|---|---|
postgresql.conf.prime | application/octet-stream | 23.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Johannes Truschnigg | 2018-11-06 21:08:06 | Re: Another streaming replication question |
Previous Message | Tom Lane | 2018-11-06 14:58:23 | Re: PostgreSQL 10.5 : Strange pg_wal fill-up, solved with the shutdown checkpoint |