On Wed, Apr 11, 2012 at 9:08 PM, Ken Brush wrote:
> On Wed, Apr 11, 2012 at 9:50 AM, Sergey Konoplev wrote:
>> On Wed, Apr 11, 2012 at 8:12 PM, Ken Brush wrote:
>> 8. Copy the history file from the new master to the slave (it's the
>> most recent #.history file in the xlog directory)
>>>
On Wed, Apr 11, 2012 at 9:50 AM, Sergey Konoplev wrote:
> On Wed, Apr 11, 2012 at 8:12 PM, Ken Brush wrote:
> 8. Copy the history file from the new master to the slave (it's the
> most recent #.history file in the xlog directory)
>>>
>>> It will work in the case of archive_command presenc
On Wed, Apr 11, 2012 at 8:12 PM, Ken Brush wrote:
8. Copy the history file from the new master to the slave (it's the
most recent #.history file in the xlog directory)
>>
>> It will work in the case of archive_command presence only and I will
>> need to sync the whole pg_xlog content if
On Wed, Apr 11, 2012 at 9:03 AM, Sergey Konoplev wrote:
> On Wed, Mar 28, 2012 at 11:35 AM, Albe Laurenz
> wrote:
>>> 1. Master dies :(
>>> 2. Touch the trigger file on the most caught up slave
>
> If the master was stopped properly will the slaves be in sync to each other?
I don't think you ca
On Wed, Mar 28, 2012 at 11:35 AM, Albe Laurenz wrote:
>> 1. Master dies :(
>> 2. Touch the trigger file on the most caught up slave
If the master was stopped properly will the slaves be in sync to each other?
>> 3. Slave is now the new master.
>> 4. On the other slaves do the following:
>> 5. Sh
Ken Brush wrote:
> I notice that the documentation at:
> http://wiki.postgresql.org/wiki/Binary_Replication_Tutorial
>
> Doesn't contain steps in a Multiple Slave setup for re-establishing
> them after a slave has become the new master.
>
> Based on the documentation, here are the most fail-proof