Negotiated Takeovers
When a takeover operation is initiated from the primary database, a negotiated takeover of the specified secondary database is performed. In a negotiated takeover, the primary database first relinquishes its role as the primary database and then requests the specified secondary database to assume the primary database role.
Before a primary database relinquishes its role, it must achieve a database quietpoint (a point in time when there are no active transactions). If a quietpoint is not achieved within the configured maximum interval to wait for a quietpoint interval (in the
When the primary database is ready to relinquish its role, it audits a 'change to primary' record in the current journal, closes the journal, and ships this to the specified secondary server. It is then up to the secondary database to assume the role of a primary database.
When the secondary database has replayed all transactions up to and including the 'change primary' audit record, the secondary database is then synchronized with the primary database at the takeover quietpoint. If there are no reader processes running on the secondary database at this point, it can assume the primary role immediately.
However, if reader processes are executing, the readers may hold locks that are causing the effects of one or more replayed transactions to be isolated (that is, the effects are hidden from all readers).
When initiating a negotiated takeover, you must decide between a conditional and a forced takeover. Base your decision on what is more important at the time: allowing long-running processes to complete, or the takeover because maintenance on the primary host cannot wait.
-
In a conditional takeover, the reader processes are given precedence.
The primary database does not relinquish its role until it has received notification to do so by the secondary database. If reader or replay conflicts exist on the secondary database, the takeover operation is abandoned.
-
In a forced takeover, the takeover operation is given precedence. The primary database relinquishes its primary role, assuming a secondary database role after it has shipped the journal containing the 'change to primary' audit record to the specified secondary database.
When the secondary database processes the 'change to primary' record with the force parameter, it attempts to force through the visibility of currently isolated transactions if conflicts with reader processes exist. This is achieved by terminating user processes with locks that conflict with isolated transactions.
In this mode, transactions are forced through one at a time until none remain. When all isolated transactions have been committed, the secondary database assumes the primary database role.
Processes running on a secondary server node can be forcibly terminated when a forced takeover takes place if they have objects locked that are blocking replaying transactions.
Server applications specified in the
