Skip Headers
Oracle® TimesTen In-Memory Database TimesTen to TimesTen Replication Guide
Release 11.2.1

Part Number E13072-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

4 Administering an Active Standby Pair Without Cache Groups

This chapter describes how to administer an active standby pair that does not replicate cache groups.

For information about administering active standby pairs that replicate cache groups, see Chapter 5, "Administering an Active Standby Pair with Cache Groups".

For information about managing failover and recovery automatically, see Chapter 6, "Using Oracle Clusterware to Manage Active Standby Pairs".

This chapter includes the following topics:

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:

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:

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 dsn2

Enter internal UID at the remote datastore with ADMIN privileges: ttuser 
Enter password of the internal Uid at the remote datastore:

Enter ttuser when prompted for the password of the internal user at the remote data store.

If you are duplicating an active 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 -keepCG "DSN=dsn2;UID=;PWD="

Enter internal UID at the remote datastore with ADMIN privileges: ttuser 
Enter password of the internal Uid at the remote datastore:

Enter ttuser when prompted for the password. ttRepAdmin then prompts for the cache administration user and password:

Enter cache administrator UID: orauser
Enter cache administrator password: 

Enter orapwd when prompted for the cache administration password.

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 data store with cache groups to a read-only subscriber, use the -nokeepCG option. In this example, dsn2 is the standby data store and sub1 is the read-only subscriber:

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

ttRepAdmin prompts for values for -uid and -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 "ttRepDuplicateEx" 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 Chapter 5, "Administering an Active Standby Pair with Cache Groups".

  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 data store.

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

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

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

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

  9. Duplicate all of the subscribers from the standby 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 data store

This section includes the following topics:

Recovering when the standby data store is ready

This section describes how to recover the active data store when the standby data store is available and synchronized with the active data store. It includes the following topics:

When replication is return receipt or asynchronous

Complete the following tasks:

  1. Stop the replication agent on the failed data store if it has not already been stopped.

  2. On the standby data store, execute ttRepStateSet('ACTIVE'). This changes the role of the data store from STANDBY to ACTIVE.

  3. On the new active data store, execute ttRepStateSave('FAILED', 'failed_store','host_name'), where failed_store is the former active data store that failed. This step is necessary for the new active data store to replicate directly to the subscriber data stores. During normal operation, only the standby data store replicates to the subscribers.

  4. Destroy the failed data store.

  5. Duplicate the new active data store to the new standby data store.

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

The standby data store contacts the active data store. The active data store stops sending updates to the subscribers. When the standby data store is fully synchronized with the active data store, then the standby data store enters the STANDBY state and starts sending updates to the subscribers. If you are replicating an AWT cache group, the new standby data store takes over processing of the cache group automatically when it enters the STANDBY state.

Note:

You can verify that the standby data has entered the STANDBY state by using the ttRepStateGet built-in procedure.

When replication is return twosafe

Complete the following tasks:

  1. On the standby data store, execute ttRepStateSet('ACTIVE'). This changes the role of the data store from STANDBY to ACTIVE.

  2. On the new active data store, execute ttRepStateSave('FAILED', 'failed_store','host_name'), where failed_store is the former active data store that failed. This step is necessary for the new active data store to replicate directly to the subscriber data stores. During normal operation, only the standby data store replicates to the subscribers.

  3. Connect to the failed data store. This triggers recovery from the local transaction logs. If data store recovery fails, you must continue from Step 5 of the procedure for recovering when replication is return receipt or asynchronous. See "When replication is return receipt or asynchronous".

  4. Verify that the replication agent for the failed data store has restarted. If it has not restarted, then start the replication agent. See "Starting and stopping the replication agents".

When the active data store determines that it is fully synchronized with the standby data store, then the standby store enters the STANDBY state and starts sending updates to the subscribers. If you are replicating an AWT cache group, the new standby data store takes over processing of the cache group automatically when it enters the STANDBY state.

Note:

You can verify that the standby data has entered the STANDBY state by using the ttRepStateSet built-in procedure.

Recovering when the standby data store is not ready

Consider the following scenarios:

  • The standby data store fails. The active data store fails before the standby comes back up or before the standby has been synchronized with the active data store.

  • The active data store fails. The standby data store becomes ACTIVE, and the rest of the recovery process begins. (See "Recovering from a failure of the active data store".) The new active data store fails before the new standby data store is fully synchronized with it.

In both scenarios, the subscribers may have had more changes applied than the standby data store.

When the active data store fails and the standby data store has not applied all of the changes that were last sent from the active data store, there are two choices for recovery:

  • Recover the active master data store from the local transaction logs.

  • Recover the standby master data store from the local transaction logs.

The choice depends on which data store is available and which is more up to date.

Recover the active data store

  1. Connect to the failed active data store. This triggers recovery from the local transaction logs.

  2. Verify that the replication agent for the failed active data store has restarted. If it has not restarted, then start the replication agent. See "Starting and stopping the replication agents".

  3. Execute ttRepStateSet('ACTIVE') on the newly recovered store.

  4. Continue with Step 6 in "Setting up an active standby pair with no cache groups".

Recover the standby data store

  1. Connect to the failed standby data store. This triggers recovery from the local transaction logs.

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

  3. Drop the replication configuration using the DROP ACTIVE STANDBY PAIR statement.

  4. Re-create the replication configuration using the CREATE ACTIVE STANDBY PAIR statement.

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

  6. Execute ttRepStateSet('ACTIVE') on the master data store, giving it the ACTIVE role.

  7. Continue from Step 6 in "Setting up an active standby pair with no cache groups".

Failing back to the original nodes

After a successful failover, you may wish to fail back so that the active data store and the standby data store are on their original nodes. See "Reversing the roles of the active and standby data stores" for instructions.

Recovering from a failure of the standby data store

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

  1. Detect the standby data store failure.

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

    call ttRepSyncSet( null, null, 2);
    commit;
    
  3. Execute ttRepStateSave('FAILED','standby_store','host_name') on the active 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.

  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 data store in one of the following ways:

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

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

    The amount of time that the standby data store has been down and the amount of transaction logs that need to be applied from the active 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 data store enters the STANDBY state after the active data store determines that the two master data stores have been synchronized.

Note:

You can verify that the standby data has entered the STANDBY state by using the ttRepStateGet procedure

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:

If the standby data store is down or in recovery, then duplicate the subscriber from the active 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 data stores

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

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

  2. Execute ttRepSubscriberWait on the active 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 data store.

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

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

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

  6. Set up the replication agent policy and start the replication agent on the old active 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 data store in the active standby pair.

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

Detection of dual active data stores

Ordinarily, the designation of the active and standby 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 data stores when changing the role of the standby data store to active.

For example, if network communication to the site of an active data store is interrupted, the user may need the standby data store at a different site to take over the role of the active, but cannot stop replication on the current active or change its role manually. Changing the standby data store to active without first stopping replication on the active 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:

Changing the configuration of an active standby pair

You can change an active standby pair by:

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 data store. After you have changed the replication scheme on the active data store, it no longer replicates updates to the standby data store or to the subscribers. You must re-create the standby 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 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 data store. See "Starting and stopping the replication agents".

  4. Destroy the standby data store and the subscribers.

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

Example 4-1 Adding a subscriber to an active standby pair

Add a subscriber data store to the active standby pair.

ALTER ACTIVE STANDBY PAIR
ADD SUBSCRIBER sub1;

Example 4-2 Dropping subscribers from an active standby pair

Drop subscriber data stores from the active standby pair.

ALTER ACTIVE STANDBY PAIR
DROP SUBSCRIBER sub1
DROP SUBSCRIBER sub2;

Example 4-3 Changing the PORT and TIMEOUT settings for subscribers

Alter the PORT and TIMEOUT settings for subscribers rep3 and rep4.

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

Example 4-4 Adding tables to an active standby pair

Add two tables and a cache group to the active standby pair.

ALTER ACTIVE STANDBY PAIR
INCLUDE TABLE tab1, tab2;