Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>
>> On Wed, Sep 22, 2010 at 1:09 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>>
>>> On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote:
>>>
>>>> But it CAN'T be a system catalog, because, among other problems, that
>>>> rules out cascading slaves, which are a feature a lot of people
>>>> probably want to eventually have.
>>>>
>>> I guarantee you there is a way around the cascade slave problem.
>>>
>
>
>> And that would be...?
>>
>
> Indeed. If it's a catalog then it has to be exactly the same on the
> master and every slave; which is probably a constraint we don't want
> for numerous reasons, not only cascade arrangements.
>
It might be an idea to store the replication information outside of all
clusters involved in the replication, to not depend on any failure of
the master or any of the slaves. We've been using Apache's zookeeper
http://hadoop.apache.org/zookeeper/ to keep track of configuration-like
knowledge that must be distributed over a number of servers. While
Zookeeper itself is probably not fit (java) to use in core Postgres to
keep track of configuration information, what it provides seems like the
perfect solution, especially group membership and a replicated
directory-like database (with per directory node a value).
regards,
Yeb Havinga