Re: Streaming replication failover/failback
| От | Adrian Klaver |
|---|---|
| Тема | Re: Streaming replication failover/failback |
| Дата | |
| Msg-id | 4d716d32-e396-e331-e26e-efd42f7a02dd@aklaver.com обсуждение исходный текст |
| Ответ на | Streaming replication failover/failback (Israel Brewster <israel@ravnalaska.net>) |
| Ответы |
Re: Streaming replication failover/failback
|
| Список | pgsql-general |
On 11/16/2016 04:51 PM, Israel Brewster wrote: > I've been playing around with streaming replication, and discovered that > the following series of steps *appears* to work without complaint: > > - Start with master on server A, slave on server B, replicating via > streaming replication with replication slots. > - Shut down master on A > - Promote slave on B to master > - Create recovery.conf on A pointing to B > - Start (as slave) on A, streaming from B > > After those steps, A comes up as a streaming replica of B, and works as > expected. In my testing I can go back and forth between the two servers > all day using the above steps. > > My understanding from my initial research, however, is that this > shouldn't be possible - I should need to perform a new basebackup from B > to A after promoting B to master before I can restart A as a slave. Is > the observed behavior then just a "lucky fluke" that I shouldn't rely You don't say how active the database is, but I going to say it is not active enough for the WAL files on B to go out for scope for A in the time it takes you to do the switch over. > on? Or is it expected behavior and my understanding about the need for a > new basebackup is simply off? Does the new pg_rewind feature of 9.5 > change things? If so, how? > > Thanks for your time! > ----------------------------------------------- > Israel Brewster > Systems Analyst II > Ravn Alaska > 5245 Airport Industrial Rd > Fairbanks, AK 99709 > (907) 450-7293 > ----------------------------------------------- > > > > > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: