Omar Mehmood <omarmehmood@yahoo.com> writes:
> I really don't want to use separate schemas for each master to
> logically partition the data. I ensure that the data on each master
> will not clash with each other (in terms of any DB level contraints
> such as PK), so I'd much prefer they all reside in a single schema.
> Also, my understanding is that Slony uses DB triggers to track changes
> (but I want to avoid using DB triggers).
If you want to avoid all PostgreSQL features… well I don't see that I
can help you here.
If you were to change your mind the following document talks about how
to federate data from several databases to the same central one, and
using either inheritance or triggers to move the incoming data from the
N origin schemas to the central one.
I guess how the data gets to being available for your central queries is
not solved by refusing to use a schema per origin server.
http://wiki.postgresql.org/wiki/Londiste_Tutorial#Federated_database
> Another additional constraint-- the master servers may not always have
> connectivity to the slave machine, so the chosen mechanism needs to be
> robust and not assume 100% uptime.
Londiste fits this need.
Regards,
--
dim
