TimesTen Database Replication learning: 7. Manage Active Standby Pair (no cache group)

The active Standby pair is a fixed mode of TimesTen replication, which is an active to 1 Standby, and then 0 or 127 subscriber, such as:

Configure Active Standby Pair (without cache group)

The approximate steps are as follows:
1. Create a database
2. Create a copy using the creation ACTIVE STANDBY pair
3. Call to Call ttRepStateSet(‘ACTIVE‘) set the active database role to Active
4. Invoke Call ttRepStart , start the replication agent
5. Create a user in the active database (user name is recommended as repadmin) and give admin permission
6. Cloning the active database to the standby database
7. Start the replication agent in the standby database
8. Wait for the standby role to automatically become standby. (call ttrepstateget)
9. Clone standby to subscriber database, if any
10. Start the replication agent on the Subscriber database

Recover from an error in the active database when standby is available when replication is return receipt or asynchronous replication

1. Stop the replication agent for the failed database
2. Set the standby database role to active. (Ttrepstateset (' ACTIVE '))
3. In the new active database, set the original active to invalid. (Ttrepstatesave (' FAILED ', ' failed_database ', ' host_name '))
   This step is necessary because, under normal circumstances, only standby can replicate to subscriber, and at this point we have to let active replicate to subscriber
4. Delete the defunct active database. (Ttdestroy failed_database)
5. Clone a new standby with new active
6. Start the replication agent on the new standby
7. When the new standby is synchronized with active, it takes over the replication task to Subscriber
8. The topology is back to normal only when active and standby have swapped roles

The experimental process is as follows:
First set up a active,standby and subscriber, the procedure can be see TimesTen database Copy Learning: 2. Configure the active Standby Pair to ensure that the status of the three libraries is active, Standby, and Idle.

Master1> call Ttrepstop; <-stops the replication agent on the active database, simulating its failure master2> call Ttrepstateset (' ACTIVE ');master2> call ttrepstateget;< ACTIVE, NO GRID >1Row found.master2> Call Ttrepstatesave (' FAILED ',' Master1 ',' Timesten-hol ');master2> @insert2INSERT intoEmployees VALUES (203,' Judy ',' Fox ',' Jfox ',' 603-123-7777 ', To_date (' 17-aug-1997 ',' dd-mon-yyyy '),' Mk_rep ',6000Null201, -);1Row inserted. <-this time, active temporarily took over the replication to subscriber subscriber1>Select* fromemployees;<203, Judy, Fox, Jfox,603-123-7777,1997- ,- - xx:xx:xx, Mk_rep,6000, <null>,201, ->1Rows found. [Email protected] ~]$ Ttdestroy master1[[email protected] ~]$ ttrepadmin-duplicate- fromMaster2-host $ (hostname)-uid repadmin-pwd timesten master1master1> call ttrepstart;master1> call ttrepstateget;& Lt STANDBY, NO GRID > <-previously defunct active database changed to STANDBY1Row found.master2> @insert2INSERT intoEmployees VALUES (203,' Judy ',' Fox ',' Jfox ',' 603-123-7777 ', To_date (' 17-aug-1997 ',' dd-mon-yyyy '),' Mk_rep ',6000Null201, -);1Row inserted. <-after inserting data into the new active, the new standby,subscriber can accept the data, at which point standby re-takes over the replication to subscriber master1>SelectCount(*) from employees where employee_id = 203;< 1 >1 row found.subscriber1> Select COUNT (*)  fromEmployeeswhereemployee_id =203;<1>1Row found.

When replication is return Twosafe

1. Set the standby database role to active. (Ttrepstateset (' ACTIVE '))
2. In the new active database, set the original active to invalid. (Ttrepstatesave (' FAILED ', ' failed_database ', ' host_name '))
3. Connect to the previously defunct active database, start the recovery automatically, or, if the recovery fails, the new active clone, followed by the same procedure as return receipt and async.
4. Set the standby database role to active. (Ttrepstateset (' ACTIVE '))
5. Start the replication agent on the new standby

When the new standby is synchronized, the task that takes over to replicate to Subscriber is rewritten.

The experimental process is as follows:
first set up a active,standby and subscriber, see TimesTen database Replication Learning: 2. Configure active Standby Pair to ensure that the state of three libraries is active, respectively, Standby and idle; and the replication transport policy is twosafe.

callcall ttRepStateSet(‘ACTIVE‘);call ttRepStateGet;< ACTIVE, NO GRID >1 row found.其实如果不停止，若强制把standby提升为ACTIVE，之前的active也会自动变为STANDBY。[[email protected] ~]$ ttRepAdmin -duplicate -fromcallcall ttrepstateget;< STANDBY, NO GRID > <-之前的active数据库自动变为standby1call ttrepstateget;< STANDBY, NO GRID >下略

Revert to the previous node

As described above when active fails, the standby takeover is called the new active, the process is called failover, and if failback is required, see the following section: Roles for the active and standby databases

Recovering from an error in the standby database

1. Standby fault Detected
2. In the case of Twosafe mode, the standby failure will affect the commit of the active database transaction, which can be set by using Ttrepsyncset (NULL, NULL, 2).
3. Call Ttrepstatesave (' FAILED ', ' standby_database ', ' host_name ') in the active database to mark standby as invalid. At this point, active takes over the replication task to Subscriber
4. Disable automatic startup of the standby database replication agent (if set)
5. Connect to the standby database to initiate an automatic recovery, if the recovery fails, from active cloning
6. Start the replication agent for the standby database

The experiment is as follows:

Master2> call Ttrepstop; <-analog Standby fault master1> call Ttrepstatesave (' FAILED ',' Master2 ',' Timesten-hol ');master1>@insert1INSERT into Employees VALUES (202,' Pat ',' Fay ',' Pfay ',' 603-123-7777 ', To_date (' 17-aug-1997 ',' dd-mon-yyyy '),' Mk_rep ',6000Null201, -);1Row inserted. Standby fails at this time, and active takes over the tasks copied to subscriber subscriber1>@sSELECT * fromemployees;<202, Pat, Fay, Pfay,603-123-7777,1997- ,- - xx:xx:xx, Mk_rep,6000, <null>,201, ->1Row found. Restore standbymaster2> call ttrepstart;master2> call ttrepstateget;< STANDBY, NO GRID >1Row found.master1>@insert2Confirm that both Master2 and subscriber have received the data.

Recovery of both active and standby databases at the same time of error

Called dual failure or double failure. As in the following cases:
* Standby failure, active is not valid until standby is restored or standby is fully synchronized with active
* Active fails, standby becomes active, and new active fails before the recovery process is complete

In both cases, Subscriber has newer data than standby.

You can choose to recover from active, or recover from standby, depending on which library's data is up-to-date.

Recovering from an active database

1. Connect to deactivated active, triggering automatic recovery
2. To confirm that the replication agent is started
3. Set the role to active. (Ttrepstateset (' ACTIVE '))
4. Next, we'll introduce the cloning operation.

Recover from standby database (not read here)

1. Connect to the failed standby, triggering automatic recovery
2. Make sure the replication agent is not started
3. Delete Replication configuration (drop ACTIVE STANDBY PAIR)
4. Recreate the replication configuration (create ACTIVE STANDBY PAIR)
5. Ttrepstateset (' active ') sets the master database role to ACTIVE
6. Start the replication agent on the new standby

Recovering from an error in the Subscriber database

Simple, there are two ways to do this:
1. Connect the Subscriber database to automatically recover from the log and then automatically synchronize with its source database
2. Clone from standby to Subscriber if standby is not available, then clone from active

Swapping roles for active and standby databases

Typically used for failback after failover, the steps are as follows:
1. Stop applying updates to the database
2. Call ttrepsubscriberwait to ensure that all active database updates are synchronized to standby. That is, two databases are fully synchronized (the return value is 0x00)
3. Stop the replication agent for the active database
4. Call Ttrepdeactivate in the active database to set the database state to idle
5. Call ttRepStateSet(‘ACTIVE‘) to elevate the standby role to active
6. Start the replication agent in the previous active database
7. The ttRepStateGet status of the active database before the call acknowledgement becomes standby
8. Restore your App

The test is as follows:

Master2>PagerTtrepsubscriberwait (null, NULL,' Master1 ', ' Timesten-hol ', ten);<xx>1Row found. <-replication from Master2 to Master1 full synchronization Description: For ASP replication, the first two parameters are set to NULL, because ASP replication has only one Datastore level of replication schema, that is, _activestandby, Owner is ttrep. Command>SELECTReplication_name, Replication_owner fromTtrep. replications;< _activestandby, Ttrep >1Row found.master2>PagerTtrepstop;master2>PagerTtrepdeactivate;master2>Pagerttrepstateget;< IDLE, NO GRID >1Row found.master1>PagerTtrepstateset (' ACTIVE ');Master1>Pagerttrepstateget;< ACTIVE, NO GRID >1Row found.master2>PagerTtrepstart;master2>Pagerttrepstateget;< IDLE, NO GRID >1Row found.master2>Pagerttrepstateget;< STANDBY, NO GRID >1Row found.master1> @insert1master1 >SelectCOUNT (*) fromemployees;<2>1Row found. Verify that the number of data bars on the Master2 and Subscriber1 is also1

Check for dual active databases

Dual active and network interrupts cause split brain to be similar, resulting in inconsistent data.
Below we simulate the following dual active scenarios, assuming that a functioning ASP was previously:

Master2>PagerTtrepstop;master2>PagerTtrepstateset (' active ');Master2>Pagerttrepstateget;< ACTIVE, NO GRID >1Row found.master1>Pagerttrepstateget;< ACTIVE, NO GRID >1Row found. At this point, the state of the two libraries is active and, more dangerously, two libraries can also be updated master1> @insert1INSERT intoEmployees VALUES (202,' Pat ',    ' Fay ',    ' Pfay ',    ' 603-123-7777 ',To_date (' 17-aug-1997 ', ' dd-mon-yyyy '),    ' Mk_rep ',    6000Null201, -);1Row inserted.master1> @sSelect* fromemployees;<202, Pat, Fay, Pfay,603-123-7777,1997- ,- - xx:xx:xx, Mk_rep,6000, <null>,201, ->1Row found.master2> @insert2INSERT intoEmployees VALUES (203,' Judy ',    ' Fox ',    ' Jfox ',    ' 603-123-7777 ',To_date (' 17-aug-1997 ', ' dd-mon-yyyy '),    ' Mk_rep ',    6000Null201, -);1Row inserted.master2> @sSelect* fromemployees;<203, Judy, Fox, Jfox,603-123-7777,1997- ,- - xx:xx:xx, Mk_rep,6000, <null>,201, ->1Row found.

When the network is restored, TimesTen automatically determines which database is newer, and because of our example, standby that is Master2 is the last to insert the data, so it retains the active state.
Not the most recent database is set to be invalid, and all connections are port. When reconnecting to this standby, it automatically becomes standby if there is no transaction on it, and if there is a non-duplicated transaction, such as our example below, its status is set to idle. Or you can discard this data, clone from the active database, or manually finish the data before cloning from the active database.

callcall ttrepstateget;< ACTIVE, NO GRID >1call ttrepstateget;  994call ttrepstateget;< IDLE, NO GRID >1 row found.

TimesTen Database Replication learning: 7. Managing active Standby Pair (no cache group)