1.) Recovery Scenarios
I think there are two types of the recovery scenario.
- Adding a new node to the cluster.
- Adding a crashed node to the cluster.
The difference is, a crashed node is still having old snapshot when it crashed, so we can recovery with only WS log replaying.
However, if the older WS log has gone by reusing log files, and no one has enough older WS data required for recovering a crashed node, the crashed node must be recovered like a new node.
2.) Boundary between the snapshot and WS log
When we do recovering with WS log replaying, the boundary between the snapshot of the database, which is going to be recovered, and WS log is very important.
Because WS log is the logical log. It mustn't be applied twice.
3.) WS data
I think each WS data should have the originator (source) node identifier and the transaction id on the originator node.
BTW, according to my understanding, each WSS is generated and sent by issuing DML command. Right?
4.) Replaying WS data
I'm not sure all WS can be replayed in single recovery transaction.
At least, the RM needs to recognize the WS is belonging to a committed transaction or an aborted transaction.
I think WS mustn't be replay without isolation of the transactions, because WS is represented as DMLs. It's logical log records.
If the RM replays the WS log in single transaction, the DMLs belonging to the aborted transactions must be ignored.
Sunday, May 01, 2005
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment