Steve Wolfe wrote:
> They may want to put the data on a file server, so that it gets backed up,
> and has the advantage of a hardware fault-tolerant RAID array. Tht has it's
> merits, but I don't think it woul dbe that great for performance. We spent
> the money to put another RAID array in the database machine, both for
> reliability and speed. Once per night, the DB is dumped, and the dump is
> copied to the file server, so that we have a second copy somewhere, and it's
> included in the nightly tape backup.
The feeling I got from speaking with their administrator was that they
wanted what you mentioned: easy backups on the applicance with the automatic
tape robot. In my application, if the PostgreSQL host goes down, all
customers have no service. Assuming RAID on the database server host,
and plenty of RAM and CPU cycles, they CPUs could still explode, or a
meteorite could find its way into the power supply (supplies?).
It will probably be necessary to have a backup host on hand (assume
identical hardware). Database connections to other system components
do not need to be maintained (they are pooled by a local process running
on the database server which speaks stateless things to other components).
If this host could run PostgreSQL out of the production environment,
but obtain periodic updates (once or twice daily would probably be fine),
it could be configured to assume the first host's IP address in case of
failure, and the system will chug along nicely.
Besides dumping and COPY'ing the data into the second server, is there
another form of easy one-way replication available? My schema has just
a few simple tables (six tables, a few rows each). But these tables
may hold a few million records each. I've estimated the total data size
to be somewhere around 10 GB (with WAGs for index sizes) for 5 million
users. I guess COPY would work.
--
Shaw Terwilliger <sterwill@sourcegear.com>
SourceGear Corporation
217.356.0105 x 641