Sunday, May 29, 2005

Documents for OSS RDBMS evaluation

Interesting documents have been published from the Northeast Asia OSS Promotion Forum.

I hope these documents can be useful for the OSS RDBMS guys.

Interesting for you?

Monday, May 02, 2005

'IN PROGRESS' transactions at the end of recoverying.

If there are 'IN PROGRESS' transactions at the end of recoverying, what can the recoverying node do? If the 'IN PROGRESS' transaction is found, the recoverying RM can't determine it's going to be committed or aborted. The RM can't know even it is the end of transaction or not (it's still continuing).

So the recoverying RM must ask another node what to do for 'IN PROGRESS' transactions.

When asking, the recoverying RM must identify the transaction using the identifier of the originater node of the transaction and the transaction id on the originator node.

BTW, how does the recoverying RM know 'recoverying is completed'?

Transaction isolation on recovery

Recovery can be realized only replaying WS log sequencially? I'm not sure that.

If there is a WS log sequence as below.

(1) XID=101, INSERT INTO t1 VALUES ( 1, 'Name 1' );
(2) XID=102, INSERT INTO t1 VALUES ( 2, 'Name 2' );
(3) XID=102, ABORT;
(4) XID=101, COMMIT;

(2) and (3) must be ignored when the RM recover. But if the recovery session replays this sequence in a single transaction,

(1) XID=501, INSERT INTO t1 VALUES ( 1, 'Name 1' );
(2) XID=501, INSERT INTO t1 VALUES ( 2, 'Name 2' );
(3) XID=501, ABORT;
(4) XID=501, COMMIT;

above operations don't insert any records.

So (1),(4) and (2),(3) must be isolated.

But how? I don't think using many transaction sessions in recoverying is a smart way.

Sunday, May 01, 2005

Some thoughts on recovery

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.