3 messages in com.mysql.lists.clusterClarifications on how storage nodes c...| From | Sent On | Attachments |
|---|---|---|
| Alex Davies | 30 Aug 2005 11:40 | |
| Jonas Oreland | 30 Aug 2005 11:50 | |
| Mikael Ronström | 31 Aug 2005 06:26 |
| Subject: | Clarifications on how storage nodes commit data to disk and recover from failure![]() |
|---|---|
| From: | Alex Davies (davi...@gmail.com) |
| Date: | 08/30/2005 11:40:44 AM |
| List: | com.mysql.lists.cluster |
Dear All,
I am trying to get to grips with how storage nodes handle their commits to and recoveries from disk. I think I have worked it out, but I would greatly appreciate it if someone wiser than myself would read the following and point out any mistakes in it:
When a transaction is committed, it is committed to the RAM in all nodes on which the data is mirrored. It is also added to the REDO log, and the UNDO log keeps a copy of the record before the transaction changes it. These logs are stored in RAM on the storage nodes.
During a LCP (local checkpoint), all the storage node's data (from its RAM) is stored on the disk.
During a GCP (global checkpoints), each storage node flushes the REDO and UNDO logs to disk.
When it comes to total cluster recovery (i.e. recovery from all nodes dying at the same time), is the following correct?
Each storage node recovers the last complete local checkpoint back into RAM, then applies the UNDO log and finally applies the REDO log to minimise or completely eliminate any lost transactions. Under defaults, is the time between GCPs the maximum quantity of transactions that can be lost, so by default two seconds worth?
Many thanks,
Alex Davies
-- Alex Davies // http://www.davz.net
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately by e-mail and delete this e-mail permanently.
Contact me - MSN: a_d...@hotmail.com SKYPE: alex.davies




