On 8/2/19 12:45 PM, Julie Nishimura wrote:
Thanks for your replies.
1) We use streaming replication, and due to hardware limitation, we
cannot add more drives to the existing host. That is why we thought by
breaking the existing streaming replication (from a->b), instead of
currently identical standby (b), we can introduce twice larger host,
then start the replication to the newly larger host, and when it is
caught up, break it again. Then break rep again, make modification to
'a" host, making it larger, then replicate b->a. After it is caught up,
break the rep again, switch master->standby (if necessary).
Is this new host going to be an entirely new machine?
If so and there is a place for it why not something like:
1)
a) --> b) --> c)(new host)
Seed using pg_basebackup
Replicate in background
2)
Take down a)
Promote either b) or c) to primary and the other as standby.
3)
Bring up a) and have it replicate off the standby in 2) and then
decide which of a) or c) is the primary or standby.
2) I am not sure about the time, but it is understood it is required 2
full replication cycles, and might be up to 2 weeks with no standby
situation
3) Yes, we will clean up whatever we can to buy us time
4) by pg_basebackup and restore
As of now, we are thinking about possibly other solutions, as of
splitting existing 37 databases on the cluster into 2 hosts with their
own standbys. This solution requires breaking up existing replication as
well. Can you please point me to some document which lists all steps
describing breaking up the existing replication properly? we are using
9.6 postgres
Thank you!
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
