[EMAIL PROTECTED] 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
clients.
*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
