Re: Enterprise readiness - mirroring / incremental backup solutions?

On Tuesday 19 Nov 2002 11:42 am, Kieran wrote:
> I'm currently starting to evaluate Open Source RDBMSs for use in a
> high-volume, high-availability environment.
>
> My main requirements are:
>
> 1. Ability to store approx 200Gb of data, with about 5Gb of data
> changing per day.

There are people with databases larger than this. Read up on VACUUM as regards
changing data.

> 2. Support for high number of concurrent short transactions under
> REPEATABLE READ transaction isolation with row-level locking (or
> equivalent optimistic concurrency control).

See the section: Multiversion Concurrency Control in the online manuals for
details of PG's transaction levels.

> 3. Fast (i.e. < 5 mins) failover time to a constantly mirrored secondary
> database server.
>
> 4. Ability to perform continous network backups such that in the event
> of both the primary database server and mirrored database server
> suffering total failure, no more than 1 hour of data is lost.

There are some replication projects and one commercial addon that I know of.
Search the mailing list archives for mention of the options, and perhaps
check the techdocs.postgresql.org site.

> Are there any third part solutions capable of making PostgreSQL meet
> requirements 3 & 4?
>
> I'd imagine it may be possible to satisfy 3. using file system level
> mirroring, but I'd appreciate it if someone could confirm this.
>
> My last question is somewhat pie-in-the sky, but assuming that
> PostgreSQL cannot currently meet requirements 3 & 4 even with 3rd party
> solutions, what are people's gut reactions to whether a small team (e.g.
> 5-6) of experienced, full-time paid developers could add mirroring and
> incremental backup support to PostgreSQL within 18 months?

Check out gborg.postgresql.org for a replication project that is I believe
intended to be merged into PostgreSQL at some point. The people on that
project would be able to tell you more about timescales and whether an offer
of help could accelerate this.

--
  Richard Huxton