Re: replication/redundancy

On Tue, Jul 01, 2003 at 08:22:37AM -0700, Jonathan Gardner wrote:

<snip>
> So you are using "lazy" rather than "eager" replication.
correct.

<snip>
>   1) The data is not consistent. This means if you run the same select query
> at the same time on the two databases, you may get different results. For
> some situations, that is okay (like Usenet). For others, it is not. (like
> registrations -- you'll sign up on one database, but you won't appear on the
> other.)
Yes. For those cases, an explicit syncout should be triggered as fast
as possible.
What you of course cannot is to store session data into the clustered DB.
All requests to same session must go to the same host. In web applications
this can be done by redirecting the client to an per-server-vhost before
creating the session. (i.e. from www.metux.de to s[1..n].metux.de).
So the session data is always available for the application. In the case
of failure only those sessions are lost, which run on the failing server.

Another solution could be an NFS-shared session directory or an rpc-based
update notification system. Perhaps we could implement some remote locking
features direct into the postmaster.

<snip>
>   3) These two factors above make using the second database as a hot-swappable
> backup risky at best. You will lose some data when you switch to the backup,
> unless changes to the database are so rare that the backup is usually up to
> date. If that were the case, you probably don't need the backup in the first
> place, because databases that don't do much tend not to be very important.
For my current applications it seems ok that some DBs are one or two
minutes behind.

<snip>
> The most obvious problem with this comes from incrementing a column.
I had such an case. If i want to count objects, i normally put them
into an table and count the rows (i.e. from an view).

If both servers add an new object, there will be no conflict.

<snip>
> This would be bad for things like paypal, where your account would only
> increase by one or the other account transfers, rather than both, if two
> occured at the same time.
Well, for such applications, the actual account value must be calculated
from an checkpoint and the lasted transactions. Checkpoints may be made
only by an master (which may change from time to time)

cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux ITS
 Webhosting ab 5 EUR/Monat.          UUCP, rawIP und vieles mehr.

 phone:     +49 36207 519931         www:       http://www.metux.de/
 fax:       +49 36207 519932         email:     contact@metux.de
 cellphone: +49 174 7066481         smsgate:   sms.weigelt@metux.de
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/