Creating and Initializing a Cluster

There are procedures to create and initialize a cluster.

If you plan to have more than one active standby pair in the cluster, see Include More Than One Active Standby Pair in a Cluster.

If you want to configure an Oracle database as a remote disaster recovery subscriber, see Configure an Oracle Database as a Disaster Recovery Subscriber.

If you want to set up a read-only subscriber that is not managed by Oracle Clusterware, see Configure a Read-Only Subscriber That Is Not Managed by Oracle Clusterware.

Start the TimesTen Cluster Agent

Start a TimesTen cluster agent (ttCRSAgent) and TimesTen cluster daemon monitor (ttCRSDaemon) on all hosts in the cluster by running the ttCWAdmin -init command.

You can run this command on any host in the cluster that is defined in the ttcrsagent.options file.

For example:

ttCWAdmin -init

The ttCWAdmin -init command performs the following:

  • Reads the ttcrsagent.options file and launches the TimesTen main daemon on each of the hosts defined in this file.

  • Starts and registers the TimesTen cluster agent (ttCRSAgent) and the TimesTen cluster daemon monitor (ttCRSDaemon) on the all hosts in the cluster. There is one TimesTen cluster agent and one TimesTen cluster daemon monitor for the TimesTen installation on each host. When the TimesTen cluster agent has started, Oracle Clusterware begins monitoring the TimesTen daemon on each host and restarts a TimesTen daemon if it fails.

To start and register the TimesTen cluster agent and the TimesTen cluster daemon monitor on specific hosts in the cluster, use the -hosts command to specify the desired hosts in the cluster to start.

ttCWAdmin -init -hosts "host1, host2"

Note:

You must stop the TimesTen cluster agent on the local host with the ttCWAdmin -shutdown before you run a ttDaemonAdmin -stop command; otherwise the cluster agent restarts the TimesTen daemon.

Create and Populate a TimesTen Database on One Host

Create a database on the host where you intend the active database to reside. The DSN must be the same as the database file name.

Create schema objects (such as tables, AWT cache groups, and read-only cache groups) and populate with data as appropriate. However, before you create cache groups, you must first decide when to load the cache groups.

  • For best performance, load the cache group tables from the Oracle database tables before the ttCWAdmin -create command. There is less performance overhead when cache groups are loaded with initial data before the duplicate is performed on the active database to create the standby database (and any subscriber databases).

    For this option, perform the following:

    1. Start the cache agent as follows:

      call ttCacheStart;

      Note:

      Since this is before the ttCWAdmin -start command, you can start the cache agent at this time. The ttCWAdmin -start command notes that the cache agent is already started and continues.

    2. Use the LOAD CACHE GROUP statement to load the cache group tables from the Oracle database tables.

    3. If using cache groups with autorefresh, set the autorefresh state to pause with the ALTER CACHE GROUP SET AUTOREFRESH STATE PAUSED statement. The autorefresh state will be set to ON as part of the ttCWAdmin -start command.

    The following example demonstrates how to create a read-only cache group with autorefresh, load the data, and then set the autorefresh state to pause:

    Command> call ttCacheStart;
    Command> CREATE READONLY CACHE GROUP my_cg
      AUTOREFRESH MODE INCREMENTAL INTERVAL 60 SECONDS
      FROM t1 (c1 NUMBER(22) NOT NULL PRIMARY KEY, c2 DATE, c3 VARCHAR(30));
    
    Command> LOAD CACHE GROUP my_cg COMMIT EVERY 100 ROWS PARALLEL 4;
    Command> ALTER CACHE GROUP my_cg SET AUTOREFRESH STATE PAUSED;
  • Alternatively, wait to load the cache group tables after the ttCWAdmin -start as described in Load Cache Groups. The data will be replicated to the standby database and any subscriber databases.

Create System DSN Files on Other Hosts

On all hosts that are to be included in the cluster, create the system DSN (sys.odbc.ini) files.

The DataStore attribute and the Data Source Name must be the same as the entry name for the cluster.oracle.ini file. See Configuring Oracle Clusterware Management With the cluster.oracle.ini File.

Create a cluster.oracle.ini File

Create a cluster.oracle.ini file as a text file.

See Configuring Oracle Clusterware Management With the cluster.oracle.ini File for details about its contents and acceptable locations for the file.

Create the Oracle Clusterware Resources to Manage Virtual IP Addresses

Advanced availability involves configuring spare master or subscriber hosts that are idle until needed to replace master or subscriber hosts (used in the active standby pair replication scheme) that either shut down unexpectedly or experience an unrecoverable error.

This is an optional step that is only necessary if you decide to configure advanced availability.

If you are planning on providing additional master or subscriber hosts for advanced availability, then you need to configure virtual IP addresses (one for each master host and subscriber actively used in the active standby pair). See Configuring Advanced Availability for more details on how many virtual IP addresses should be created.

In this case, perform the following:

  1. Designate (or create) new virtual IP addresses on the network that are to be used solely for managing multiple hosts in a TimesTen replication environment managed by Oracle Clusterware.

  2. Configure these VIP addresses for use to manage multiple hosts for advanced availability in the cluster.oracle.ini file, as described in Configuring Advanced Availability.

  3. Create the Oracle Clusterware resources that manage these VIP addresses by running the ttCWAdmin -createVIPs command as the root user on any host in the cluster.

    For example:

    ttCWAdmin -createVIPs -dsn myDSN

    The VIP address names created by this command start with network_ followed by the TimesTen instance name, TimesTen instance administrator, and the DSN. Whereas, the VIP addresses created for use by Oracle Clusterware are prefixed with ora.

    Note:

    You must run the ttCWAdmin -createVIPs command before the ttCWAdmin -create command. If you decide that you want to use VIP addresses for advanced availability after you run the ttCWAdmin -create command, you must perform the following:

    1. Run ttCWadmin -drop to drop the active standby pair replication scheme.

    2. Add VIP addresses into cluster.oracle.ini file.

    3. Run ttCWadmin -createVIPs to create the resources to manage the VIP addresses.

    4. Run ttCWAdmin -create to create the active standby pair replication scheme managed by Oracle Clusterware.

Once created, the only way to drop the Oracle Clusterware resources that manage the VIP addresses is to run the ttCWAdmin -dropVIPs command. Before you can drop the virtual IP addresses, you must first run the ttCWAdmin -drop command.

The following is an example of how to drop the virtual IP addresses:

ttCWAdmin -dropVIPs -dsn myDSN 

For an example of when to use the ttCWAdmin -dropVIPs command, see Removing an Active Standby Pair From a Cluster.

Create an Active Standby Pair Replication Scheme

Create an active standby pair replication scheme by running the ttCWAdmin -create command on any host in the cluster.

Note:

The cluster.oracle.ini file contains the configuration needed to perform the ttCWAdmin -create command and so must reachable by the ttCWAdmin executable. See Configuring Oracle Clusterware Management With the cluster.oracle.ini File.

For example:

ttCWAdmin -create -dsn myDSN

The ttCWAdmin -create command prompts for the following:

  • Prompts for the name of a TimesTen user with ADMIN privileges. If cache groups are being managed by Oracle Clusterware, enter the TimesTen cache administration user name.

  • Prompts for the TimesTen password for the previously entered user name.

  • If cache groups are being used, prompts for the password for the Oracle cache administration user. This password is provided in the OraclePWD connection attribute when the cache administration user connects.

  • Prompts for a random string used to encrypt the above information.

If you want to specify the path and name of a file to be used as the cluster.oracle.ini file, use the -ttclusterini option of the ttCWAdmin -create command.

ttCWAdmin -create -dsn myDSN -ttclusterini path/to/cluster/mycluster.ini

To drop the active standby pair, use the ttCWAdmin -drop command, as follows:

ttCWAdmin -drop -dsn myDSN

Note:

If your application connects to the TimesTen database using the virtual IP address, then this connection drops with the ttCWAdmin -drop command, since the virtual IP address is managed by Oracle Clusterware. However, if your application connects to the TimesTen database using the host name, the connection is not dropped.

For examples showing the sequence in which to use the ttCWAdmin -create and ttCWAdmin -drop commands, see Managing Active Standby Pairs in a Cluster and Managing Read-Only Subscribers in the Active Standby Pair.

Start the Active Standby Pair and the Applications

Start the cluster with the active standby pair replication scheme by running the ttCWAdmin -start command on any host.

This starts the cache agent (if not already started) and replication agent on the active database, performs the duplicate to create the standby database (and any subscriber databases), and starts the cache agent and replication agent on the standby (and any subscribers).

If you do not specify -noApp option, the applications are also started. If you do specify -noApp option, then you can start and stop the applications with the -startApps and -stopApps options respectively.

For example:

ttCWAdmin -start -dsn myDSN

This command starts the following processes for the active standby pair:

  • TimesTen daemon monitorttCRSMaster

  • Active service ttCRSActiveService

  • Standby service ttCRSsubservice

  • Monitor for application AppName

The following example starts the cache and replication agents, but does not start the applications because of the inclusion of the -noapp option:

ttCWAdmin -start -noapp -dsn myDSN

To start and stop applications, use the ttCWAdmin -startApps and -stopApps commands as shown below:

ttCWAdmin -startapps -dsn myDSN
ttCWAdmin -stopapps -dsn myDSN

To stop the TimesTen database monitor (ttCRSMaster), cache agent and replication agent and disconnect the application from both databases, run the ttCWAdmin -stop command.

ttCWAdmin -stop -dsn myDSN

Note:

If your application connects to the TimesTen database using a virtual IP address, then this connection drops with the ttCWAdmin -stop command, since the virtual IP address is managed by Oracle Clusterware. However, if your application connects to the TimesTen database using the host name, the connection is not dropped; however, replication to the standby does not occur.

See Managing Active Standby Pairs in a Cluster and Managing Read-Only Subscribers in the Active Standby Pair for examples showing the sequence in which to use the ttCWAdmin -start and -stop commands.

Load Cache Groups

If the active standby pair includes cache groups and you have not already loaded the cache group use the LOAD CACHE GROUP statement to load the cache group tables from the Oracle database tables.

See Create and Populate a TimesTen Database on One Host.

For more information on when to load cache groups, see Create and Populate a TimesTen Database on One Host.

Include More Than One Active Standby Pair in a Cluster

If you want to use Oracle Clusterware to manage more than one active standby pair in a cluster, include additional configuration in the cluster.oracle.ini file.

Oracle Clusterware can only manage more than one active standby pair in a cluster if all TimesTen databases are a part of the same TimesTen instance on a single host.

For example, the following cluster.oracle.ini file contains configuration information for two active standby pair replication schemes on the same host:

[advancedSubscriberDSN]
MasterHosts=host1,host2,host3
SubscriberHosts=host4, host5
MasterVIP=192.168.1.1, 192.168.1.2
SubscriberVIP=192.168.1.3
VIPInterface=eth0
VIPNetMask=255.255.255.0

[advSub2DSN]
MasterHosts=host1,host2,host3
SubscriberHosts=host4, host5
MasterVIP=192.168.1.4, 192.168.1.5
SubscriberVIP=192.168.1.6
VIPInterface=eth0
VIPNetMask=255.255.255.0

Perform these tasks for additional replication schemes:

  1. Create and populate the databases.

  2. Create the virtual IP addresses. Use the ttCWAdmin -createVIPs command.

  3. Create the active standby pair replication scheme. Use the ttCWAdmin -create command.

  4. Start the active standby pair. Use the ttCWAdmin -start command.

Configure an Oracle Database as a Disaster Recovery Subscriber

You can create an active standby pair on the primary site with an Oracle database as a remote disaster recovery subscriber.

See Using a Disaster Recovery Subscriber in an Active Standby Pair.

Oracle Clusterware manages the active standby pair, but does not manage the disaster recovery subscriber. The user must explicitly switch to use the remote site if the primary site fails.

To use Oracle Clusterware to manage an active standby pair that has a remote disaster recovery subscriber, perform these tasks:

  1. Use the RepDDL or RemoteSubscriberHosts Clusterware attribute to provide information about the remote disaster recovery subscriber. For example:
    [advancedDRsubDSN]
    MasterHosts=host1,host2,host3
    SubscriberHosts=host4, host5
    RemoteSubscriberHosts=host6
    MasterVIP=192.168.1.1, 192.168.1.2
    SubscriberVIP=192.168.1.3
    VIPInterface=eth0
    VIPNetMask=255.255.255.0
    CacheConnect=y
  2. Use ttCWAdmin -create to create the active standby pair replication scheme on the primary site. This does not create the disaster recovery subscriber.
  3. Use ttCWAdmin -start to start the active standby pair replication scheme.
  4. Load the cache groups that are replicated by the active standby pair.
  5. Set up the disaster recovery subscriber using the procedure in Rolling Out a Disaster Recovery Subscriber.

Configure a Read-Only Subscriber That Is Not Managed by Oracle Clusterware

You can include a read-only TimesTen subscriber database that is not managed by Oracle Clusterware.

Perform these tasks:

  1. Include the RemoteSubscriberHosts Clusterware attribute in the cluster.oracle.ini file. For example:
    [advancedROsubDSN]
    MasterHosts=host1,host2,host3
    RemoteSubscriberHosts=host6
    MasterVIP=192.168.1.1, 192.168.1.2
    SubscriberVIP=192.168.1.3
    VIPInterface=eth0
    VIPNetMask=255.255.255.0
  2. Use ttCWAdmin -create to create the active standby pair replication scheme on the primary site.
  3. Use ttCWAdmin -start to start the active standby pair replication scheme. This does not create the read-only subscriber.
  4. Use the ttRepStateGet built-in procedure to verify that the state of the standby database is STANDBY.
  5. On the subscriber host, use ttRepAdmin -duplicate option to duplicate the standby database to the read-only subscriber. See Duplicating a Database.
  6. Start the replication agent on the subscriber host.