Table of Contents
Advertisement
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( )
application calls
any database records it uses, and that it will release these records after RTR
causes the
not be able to issue
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.
calls. RTR knows that at the time a correctly written server
rtr_accept_tx( )
rtr_accept_tx( )
call to complete. Any conflicting transaction would
rtr_accept_tx( )
Server Shadowing and Recovery
, it has already accessed (and hence locked)
concurrently. Hence a correct serialisation
Server Shadowing and Recovery B–5
B.6 Performance
Advertisement
Table of Contents
