db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland <Jorgen.Lol...@Sun.COM>
Subject Re: Derby and replication
Date Wed, 19 Sep 2007 09:28:54 GMT
msegel@dbrack01.segel.com wrote:
> You can have asynch replication without having any data loss. Or rather the probability
of data loss is minimal.
> Sent via BlackBerry by AT&T

You are right, but you have to calculate with that risk. For database 
systems, asynchronous replication comes with the risk that the 
transactions committed the last x (milli)seconds before the master 
crashes will not be reflected at the slave. That is, there *may* be loss 
of information, but does not have to.

The reason is that in contrast to synchronous replication strategies, a 
transaction's updates are not force-sent to the slave when it commits. 
If the master is running for two years before crashing, and the slave 
lags 1 second behind, the data loss is minimal. Depending on your 
application, this may or may not be acceptable. For example, I doubt 
that even this small % of data loss will be acceptable for money 
transfers between banks. It may still be good enough for an email server...

I'd say that you are looking for...

... replication if you want one master DBMS to own the data [1], but 
with backup DBMSs ready to take over the responsibilities of the master 
role if the current master crashes. The clients will have to reconnect 
to a new node [2], but are otherwise not affected by the crash.

... synchronization if you don't want a backup system to be ready to 
become a master after a crash. What you need is a central database that 
you connect to every now and then to hear the latest news and possibly 
append updates (with the risk of dependency conflicts because the client 
did not know about updates made by another client).

[1] Systems where the data are distributed across multiple nodes are not 
taken into account.
[2] A middle tier, e.g. the JDBC driver, may mask this reconnect for the 

*Regarding the question from the thread starter:* Will it be ok for POS 
to have data that are not completely fresh? If an hour or so lag is ok, 
you may find what you are looking for in Derby's "Online Backup" 
feature. However, this solution will *not* allow updates of the POS 
database (nor will the replication feature I mentioned earlier).

Jørgen Løland

View raw message