On 08/26/2013 12:47 AM, Jim Nasby wrote:
> On 8/23/13 11:23 AM, Greg Stark wrote:
>> This doesn't generate a unique id. You could back up a standby and
>> restore it and point it at the original master and end up with two
>> standbies with the same id.
Yeah, not as easy as I imagined. It will fix itself once the 2nd slave
starts to follow the 1st, bt this has the disadvantage that for a
connected client a running system suddenly changes its "unique id".
If we want it happen automatically we have to allow erring on "too
often" or "not often enough" side for some users/usages.
>
> If you want to enforce something unique throughout a cluster, I think
> we're stuck with having the cluster communicate IDs across an entire
> cluster. AFAIK that's how both Slony and londiste 3 do it.
>
> I think it's also noteworthy that Slony and londiste both rely on the
> user specifying node identifiers. They don't try to be magic about it.
> I think there's 2 advantages there:
>
> - Code is simpler
> - Users can choose a naming schema that makes sense for them
3rd - really only users can determine when a "system" is unique and when
it is a copy of another.
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ