On Mon, Mar 19, 2001 at 11:00:20AM -0000, Peter Galbavy wrote:
> 1. One "writer", many "reader" PostgreSQL servers. We will want to write
> provisioning / configuration information centrally and can tolerate a
> "writer" failuer for a time.
> 2. Consitency at the transaction level. All changes to the "writer" server
> will be wrapped in transactions, and there will be foreign key consistency
> checking in many tables.
> 3. Delays from "writer" through to consistent state on "readers" can be
> tolerated to within a few minutes or even more. All read-servers must be in
> the same state when answering requests.
>
> Our objective is to acheive performance and some fault tolerance as the data
> is going to be used for near-real time configuration of various other
> backend systems in an almost traditional 'net environment.
Your application sounds like a perfect fit for LDAP.
In other words, keep your database in Postgres, but export views of it
through for clients to query through LDAP. Rely on LDAP replication,
since it has the model you need and works today.
--
Christopher Masto Senior Network Monkey NetMonger Communications
chris@netmonger.net info@netmonger.net http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
