4 Administering an Active Standby Pair Without Cache Groups

Overview of master data store states

This section summarizes the possible states of a master data store. These states are referenced in the tasks described in the rest of the chapter.

The master data stores can be in one of the following states:

• ACTIVE - A store in this state is the active master data store. Applications can update its replicated tables.

• STANDBY - A store in this state is the standby master data store. Applications can update only nonreplicated tables in the standby master data store. Nonreplicated tables are tables that have been excluded from the replication scheme by using the EXCLUDE TABLE or EXCLUDE CACHE GROUP clauses of the CREATE ACTIVE STANDBY PAIR statement.

• FAILED - A data store in this state is a failed master data store. No updates can be replicated to it.

• IDLE - A store in this state has not yet had its role in the active standby pair assigned. It cannot be updated. Every store comes up in the IDLE state.

• RECOVERING - When a previously failed master data store is synchronizing updates with the active master data store, it is in the RECOVERING state.

You can use the ttRepStateGet built-in procedure to discover the state of a master data store.

Duplicating a data store

When you set up an replication scheme or administer a recovery, a common task is duplicating a data store. You can use the ttRepAdmin -duplicate utility or the ttRepDuplicateEx C function to duplicate a data store.

To duplicate a data store, these conditions must be fulfilled:

• The instance administrator performs the duplicate operation.

• The instance administrator user name must be the same on both instances involved in the duplication.

• You must provide the user name and password for a user with the ADMIN privilege on the source data store.

On the source data store, create a user and grant the ADMIN privilege to the user:

CREATE USER ttuser IDENTIFIED BY ttuser;
User created.

GRANT admin TO ttuser;

Assume the user name of the instance administrator is timesten. Logged in as timesten, duplicate data store dsn1 on host1 to dsn2:

ttRepAdmin -duplicate -from dsn1 -host host1 -uid ttuser -pwd ttuser dsn2

If you are duplicating an active master data store that has cache groups, use the -keepCG option. You must also specify the cache administration user ID and password with the -cacheuid and -cachepwd options. If you do not provide the cache administration user password, ttRepAdmin prompts for a password. If the cache administration user ID is orauser and the password is orapwd, duplicate data store dsn1 on host1:

ttRepAdmin -duplicate -from dsn1 -host host1 -uid ttuser -pwd ttuser -keepCG -cacheuid orauser -cacheuid orapwd "DSN=dsn2;UID=;PWD="

The UID and PWD for dsn2 are specified as null values in the connection string so that the connection is made as the current OS user, which is the instance administrator. Only the instance administrator can run ttRepAdmin -duplicate. If dsn2 is configured with PWDCrypt instead of PWD, then the connection string should be "DSN=dsn2;UID=;PWDCrypt=".

When you duplicate a standby master data store with cache groups to a read-only subscriber, use the -nokeepCG option. In this example, dsn2 is the standby master data store and sub1 is the read-only subscriber:

ttRepAdmin -duplicate -from dsn2 -host host2 -uid ttuser -pwd ttuser -nokeepCG "DSN=sub1;UID=;PWD="

For more information about the ttRepAdmin utility, see "ttRepAdmin" in Oracle TimesTen In-Memory Database Reference. For more information about the ttRepDuplicateEx C function, see "TimesTen Utility API" in Oracle TimesTen In-Memory Database C Developer's Guide.

Setting up an active standby pair with no cache groups

To set up an active standby pair, complete the tasks in this section. See "Configuring an active standby pair with one subscriber" for an example.

If you intend to replicate read-only cache groups or asynchronous writethrough (AWT) cache groups, see "Replicating cache tables" in Oracle In-Memory Database Cache User's Guide.

1. Create a data store.

2. Create the replication scheme using the CREATE ACTIVE STANDBY PAIR statement. See Chapter 3, "Defining an Active Standby Pair Replication Scheme".

3. Start the replication agent. See "Starting and stopping the replication agents".

4. Call ttRepStateSet('ACTIVE') on the active master data store.

5. Create a user on the active master data store and grant the ADMIN privilege to the user.

6. Duplicate the active master data store to the standby master data store.

7. Start the replication agent on the standby master data store. See "Starting and stopping the replication agents".

8. Wait for the standby master data store to enter the STANDBY state. Use the ttRepStateGet procedure to check the state of the standby master data store.

9. Duplicate all of the subscribers from the standby master data store. See "Copying a master data store to a subscriber".

10. Set up the replication agent policy and start the replication agent on each of the subscriber stores. See "Starting and stopping the replication agents".

Recovering from a failure of the active master data store

This section includes the following topics:

• Recovering when the standby master data store is ready

• Recovering when the standby master data store is not ready

• Failing back to the original nodes

Recovering from a failure of the standby master data store

To recover from a failure of the standby master data store, complete the following tasks:

1. Detect the standby master data store failure.

2. If return twosafe service is enabled, the failure of the standby master data store may prevent a transaction in progress from being committed on the active master data store, resulting in error 8170, "Receipt or commit acknowledgement not returned in the specified timeout interval". If so, then call the ttRepStateSet procedure with a localAction parameter of 2 (COMMIT) and commit the transaction again. For example:

   call ttRepStateSet( null, null, 2);
   commit;
   

3. Execute ttRepStateSave('FAILED','standby_store','host_name') on the active master data store. After this, as long as the standby data store is unavailable, updates to the active data store are replicated directly to the subscriber data stores. Subscriber stores may also be duplicated directly from the active master.

4. If the replication agent for the standby data store has automatically restarted, stop the replication agent. See "Starting and stopping the replication agents".

5. Recover the standby master data store in one of the following ways:

   • Connect to the standby master data store. This triggers recovery from the local transaction logs.

   • Duplicate the standby master data store from the active master data store.

   The amount of time that the standby master data store has been down and the amount of transaction logs that need to be applied from the active master data store determine the method of recovery that you should use.

6. Set up the replication agent policy and start the replication agent. See "Starting and stopping the replication agents".

The standby master data store enters the STANDBY state after the active master data store determines that the two master data stores have been synchronized.

Recovering from the failure of a subscriber data store

If a subscriber data store fails, then you can recover it by one of the following methods:

• Connect to the failed subscriber. This triggers recovery from the local transaction logs. Start the replication agent and let the subscriber catch up.

• Duplicate the subscriber from the standby master data store.

If the standby master data store is down or in recovery, then duplicate the subscriber from the active master data store.

After the subscriber data store has been recovered, then set up the replication agent policy and start the replication agent. See "Starting and stopping the replication agents".

Reversing the roles of the active and standby master data stores

To change the active master data store's role to that of a standby master data store and vice versa:

1. Pause any applications that are generating updates on the current active master data store.

2. Execute ttRepSubscriberWait on the active master data store, with the DSN and host of the current standby data store as input parameters. This ensures that all updates have been transmitted to the current standby master data store.

3. Stop the replication agent on the current active master data store. See "Starting and stopping the replication agents".

4. Execute ttRepDeactivate on the current active master data store. This puts the store in the IDLE state.

5. Execute ttRepStateSet('ACTIVE') on the current standby master data store. This store now acts as the active master data store in the active standby pair.

6. Set up the replication agent policy and start the replication agent on the old active master data store. Use the ttRepStateGet procedure to determine when the data store's state has changed from IDLE to STANDBY. The data store now acts as the standby master data store in the active standby pair.

7. Resume any applications that were paused in Step 1.

Detection of dual active master data stores

Ordinarily, the designation of the active master and standby master data stores in an active standby pair is explicitly controlled by the user. However, in some circumstances the user may not have the ability to modify both the active and standby master data stores when changing the role of the standby master data store to active.

For example, if network communication to the site of an active master data store is interrupted, the user may need the standby master data store at a different site to take over the role of the active, but cannot stop replication on the current active master or change its role manually. Changing the standby master data store to active without first stopping replication on the active master leads to a situation where both masters are in the ACTIVE state and accepting transactions. In such a scenario, TimesTen can automatically negotiate the active/standby role of the master data stores when network communication between the stores is restored.

If, during the initial handshake between the data stores, TimesTen determines that the master data stores in an active standby pair replication scheme are both in the ACTIVE state, TimesTen performs the following operations automatically:

• The data store which was set to the ACTIVE state most recently is left in the ACTIVE state and may continue to be connected to and updated by applications.

• The data store which was set to the ACTIVE state least recently is invalidated. All applications are disconnected.

• When the invalidated data store comes back up, TimesTen determines whether any transactions have occurred on the data store that have not yet been replicated to the other master data store. If such transactions have occurred, they are now trapped, and the data store is left in the IDLE state. The data store needs to be duplicated from the active master in order to become a standby master. If there are no trapped transactions, the data store is safe to use as a standby master data store and is automatically set to the STANDBY state.

Changing the configuration of an active standby pair

You can change an active standby pair by:

• Adding or dropping a read-only subscriber data store

• Altering store attributes - Only the PORT and TIMEOUT attributes can be set for subscribers. The RELEASE clause cannot be set for any data store in an active standby pair.

• Including tables or cache groups in the active standby pair

• Excluding tables or cache groups from the active standby pair

If you are adding cache groups to the replication scheme, see Chapter 5, "Administering an Active Standby Pair with Cache Groups". The steps in this section apply to active standby pairs with no cache groups.

Make these changes on the active master data store. After you have changed the replication scheme on the active master data store, it no longer replicates updates to the standby master data store or to the subscribers. You must re-create the standby master data store and the subscribers and restart the replication agents.

Use the ALTER ACTIVE STANDBY PAIR statement to change the active standby pair.

To change an active standby pair, complete the following tasks:

1. Stop the replication agent on the active master data store. See "Starting and stopping the replication agents".

2. Use the ALTER ACTIVE STANDBY PAIR statement to make changes to the replication scheme.

3. Start the replication agent on the active master data store. See "Starting and stopping the replication agents".

4. Destroy the standby master data store and the subscribers.

5. Continue from Step 5 of "Setting up an active standby pair with no cache groups".

ALTER ACTIVE STANDBY PAIR
ADD SUBSCRIBER sub1;

ALTER ACTIVE STANDBY PAIR
DROP SUBSCRIBER sub1
DROP SUBSCRIBER sub2;

ALTER ACTIVE STANDBY PAIR
ALTER STORE sub1 SET PORT 23000 TIMEOUT 180
ALTER STORE sub2 SET PORT 23000 TIMEOUT 180;

ALTER ACTIVE STANDBY PAIR
INCLUDE TABLE tab1, tab2;