auto-backup across the net

Austin Schutz tex at
Fri Jun 21 20:48:50 CDT 2002

On Fri, Jun 21, 2002 at 06:34:15PM -0700, Jason White wrote:
> If we are talking about an internet, web-based setup, where client systems
> are accessing your databse, you have more immediate concerns on your hands
> than redundancy.
> If we are talking about a secure website, then the webserver should be the
> only system accessing the database, clients talk to the webserver and the
> webserver dishes out data.  The webserver is the only one(s) who need to be
> updated.  This can be done directly in your cgi(not the best solution) by
> testing for the presence of the required server/files before access,

	Ok, this was my point, but it still doesn't answer the question of
how you tell the client. You test, find that something is broken, and then

> by a
> content-smart switch/router (hardware or software) which can re-route
> traffic to a different destination IP when/if the original fails, or by a
> round-robin DNS set up, where is the defualt hostname fails, the DNS table
> switches to the second.  If clustering is setup, then it is entirly the
> responsability of the cluster and is transparent to the developer.

	These are true, but may be overkill or overly expensive. Also, I'm not
sure if the DNS solution works if a connection is made. If a connection is
made but the webserver or cgi returns an error, will the client be smart
enough to use the other machines indicated by DNS?

> If we are talking about a an intranet application where many clients are
> accessing your database, try switching to a more server based model which
> can more closly model the options above.
	Intranet applications I've programmed have known ahead of time
about the location of redundant database servers. This works pretty well
in my experience, and there's no reason it couldn't be done here. I still
think the question of how you tell a client to go somewhere else is valid.
What happens when e.g. the cgi can't access _any_ database server? Maybe
the answer is just fail - but then again, maybe access would work from the
same cgi on a different host depending on the particulars of the problem.


More information about the Pdx-pm-list mailing list