On Sun, Jun 17, 2012 at 1:11 PM, Josh Berkus wrote:
>
>> Instead of using re-synchronization (e.g. repmgr in its relation to
>> rsync), I intend to proxy and also inspect the streaming replication
>> traffic and then quiesce all standbys and figure out what node is
>> farthest ahead. Once I figur
> Instead of using re-synchronization (e.g. repmgr in its relation to
> rsync), I intend to proxy and also inspect the streaming replication
> traffic and then quiesce all standbys and figure out what node is
> farthest ahead. Once I figure out the node that is farthest ahead, if
> it is not a no
Simon,
> The "major limitation" was solved by repmgr close to 2 years ago now.
> So while you're correct that the patch to fix that assumed that
> archiving worked as well, it has been possible to operate happily
> without it.
repmgr is not able to remaster using only streaming replication. It
a
On Fri, Jun 15, 2012 at 3:53 PM, Simon Riggs wrote:
> On 10 June 2012 19:47, Joshua Berkus wrote:
>
>> So currently we have a major limitation in binary replication, where it is
>> not possible to "remaster" your system (that is, designate the most
>> caught-up standby as the new master) based
On Sat, Jun 16, 2012 at 6:53 AM, Simon Riggs wrote:
> On 10 June 2012 19:47, Joshua Berkus wrote:
>
>> So currently we have a major limitation in binary replication, where it is
>> not possible to "remaster" your system (that is, designate the most
>> caught-up standby as the new master) based
On 10 June 2012 19:47, Joshua Berkus wrote:
> So currently we have a major limitation in binary replication, where it is
> not possible to "remaster" your system (that is, designate the most caught-up
> standby as the new master) based on streaming replication only. This is a
> major limitati
On 6/10/12 11:47 AM, Joshua Berkus wrote:
> So currently we have a major limitation in binary replication, where it is
> not possible to "remaster" your system (that is, designate the most caught-up
> standby as the new master) based on streaming replication only. This is a
> major limitation b
On Sun, Jun 10, 2012 at 11:47 AM, Joshua Berkus wrote:
> So currently we have a major limitation in binary replication, where it is
> not possible to "remaster" your system (that is, designate the most caught-up
> standby as the new master) based on streaming replication only. This is a
> majo
So currently we have a major limitation in binary replication, where it is not
possible to "remaster" your system (that is, designate the most caught-up
standby as the new master) based on streaming replication only. This is a
major limitation because the requirement to copy physical logs over
