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@aklaver.com
