Compaq AA-Q88CE-TE manual Shadows in Action, Application Considerations

Server Shadowing and Recovery

B.6 Performance

Note that RTR does not have to wait for the secondary shadow server to complete its processing. It only needs to know that the primary has committed the transaction and that the journal file of the secondary shadow server contains the final vote status.

The two partners in a shadow pair should be connected with sufficient bandwidth to cater for the possibly large amounts of data which may need to be transferred during a shadow catchup operation.

B.7 Shadows in Action

The first node on which a shadow server for a particular key-range starts is arbitrarily designated by RTR to be the primary site for that key-range.

Initially RTR searches the journals of other backend sites to find any recoverable transactions left over from a previous invocation of the server. Once these have been processed (or RTR is able to determine that no such transactions exist), the server becomes active and available to handle new transactions sent by clients.

While no other server site for this key-range is available the server runs in REMEMBER mode, and RTR saves transactions processed on this site in the RTR journal (together with the order in which they should be committed), so that when the other site server(s) start they can be sent to this site.

When a server starts on a second site it begins processing the transactions saved in the primary site's journal. These are deleted from the journal as they are processed. When the second site server(s) have caught up, the second site enters SECONDARY state and the original site servers enter ACTIVE state. In this mode, new transactions are sent to both sites in parallel. They are executed first on the primary site, and shortly afterwards on the secondary site in equivalent order. The primary site commits transactions as soon as it knows that the secondary has hardened (i.e. written to the journal) the order in which the transaction is to be committed.

In the event of a failure at this point the remaining site executes a short tidy-up operation, and as soon as it has done this and determined that the other site is really down, it reverts to the REMEMBER state and carries on processing new transactions autonomously, saving the transaction information in its journal for when the other site restarts.

The execution order is determined for transactions issued to concurrent servers on a particular node by recording the order in which the individual servers issue rtr_accept_tx( ) calls. RTR knows that at the time a correctly written server application calls rtr_accept_tx( ), it has already accessed (and hence locked) any database records it uses, and that it will release these records after RTR causes the rtr_accept_tx( ) call to complete. Any conflicting transaction would not be able to issue rtr_accept_tx( ) concurrently. Hence a correct serialisation order for issuing the transactions on the shadow site can be determined.

B.8 Application Considerations

Although applications need not be directly concerned about Shadowing matters, certain points must be taken into consideration when implementing performance boosting optimizations:

•Anything specific to the executing node should not be stored in the database, since this would lead to diverging copies.

Server Shadowing and Recovery B–5