hi Robert,
thanks for your quick response!
as i believe to now understand your design, i have the following problem:
if all controllers fail (whatever reason) i'm unable to tell which
database to trust (which is the one with consistent data) because i can
not trust the recovery log and therefor i'm not able to tell which
database survived
maybe i will give you an example with the requirement:
1. Client commits an transaction
2. controller sends OK to client (request failed on all but one backend)
3. client receives OK
4. all controller fail, recovery log not written!
now, how can i recover from this error, with consistent data? (with the
data from the commited transaction of the client)
the problem is: as unlikely as this might be, its vital for our
application because we have to ensure that all successful committed data
are "never" lost.
this goes further as we have to ensure that the data has been written on
at least 2 different nodes (out of 3) before success is reported back to
the client, but this is another story.
thanks for your time
regards
markus
Robert Hodges wrote:
Hi Markus,
The asynchronous update to the recovery log is by design. The Sequoia
"recovery log" is in a sense really a replication log rather than a
roll-forward/roll-back log of the sort you find in civilized databases. Our
log does not have an impact on data consistency unless you need to
initialize a database or restore one that has become unsynchronized. The
design works according to the following principles:
1.) Updates go directly to backends and are effectively applied
synchronously. If you receive a successful commit, there are two possible
states for each backend. Either the commit succeeded in which case you are
consistent or it failed and the database is now off-line. This takes care
of backends.
2.) There is a copy of the recovery log in each controller. Assuming you
have more than one controller running, you would need to lose all
controllers simultaneously to lose the logs. This takes care of log
redundancy. Sooner or later the log messages do hit the database. This is
a common design in distributed systems.
Finally, as far as the question on failed writes to the log. It's pretty
bad when that happens. Look for the following message in the logs where {0}
and {1} can be ignored.
Failed to log {0} for transaction {1}
This should rarely happen if you keep the database happy by purging logs
regularly.
Cheers, Robert
Robert Hodges, CTO, Continuent, Inc.
Email: [EMAIL PROTECTED]
Cell: +1-510-501-3728 +49-(0)177-6137817 Skype: hodgesrm
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Markus
Woschank
Sent: Thursday, July 05, 2007 11:24 AM
To: [email protected]
Subject: [Sequoia] synchronous recovery log
hi,
i noticed that the recovery log is written asynchronous (in the
LoggerThread). But as a requirement we need to ensure the consistency of
the data and therefor the recovery log is vital for our application.Is
there an "easy" way of forcing the recovery log to be written
synchronous, and to ensure that a request fails if the recovery log
could not be written?
thanks in advance
best regards
markus
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
!DSPAM:288,468cded1262211009077471!
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
