Oracle® Communication and Mobility Server Administrator Guide Release 10.1.3 Part Number B31497-01 |
|
|
View PDF |
This chapter discuses configuring high availability in the following sections:
OCMS provides high availability through redundancy, application state replication, and clustering. Highly available OCMS topologies are active-active, meaning that any redundant nodes actively function in the context of the topology. This makes OCMS scalable as well.
A highly available OCMS topology provides the following:
Process death detection and automatic restart—Processes may die unexpectedly due to configuration or software problems. A proper process monitoring and restart system monitors all system processes constantly and restarts them if necessary. OPMN (Oracle Process Manager and Notification Server)
Clustering—Clustering components of a system together allows the components to be viewed functionally as a single entity from the perspective of a client for runtime processing and manageability. A cluster is a set of processes running on single or multiple computers that share the same workload. There is a close correlation between clustering and redundancy. A cluster provides redundancy for a system.
Configuration management—A clustered group of similar components often need to share common configuration. Proper configuration management ensures that components provide the same reply to the same incoming request, allows these components to synchronize their configurations, and provides highly available configuration management for less administration downtime.
State replication and routing—For stateful applications, client state can be replicated to enable stateful failover of requests in the event that processes servicing these requests fail.
Server load balancing and failover—When multiple instances of identical server components are available, client requests to these components can be load balanced to ensure that the instances have roughly the same workload. With a load balancing mechanism in place, the instances are redundant. If any of the instances fail, requests to the failed instance can be sent to the surviving instances.
Configuring a highly available OCMS environment involves the following main steps, depending on the OCMS topology you have chosen to deploy:
Setting Up a Highly Available Cluster of OCMS Nodes—This involves associating each OCMS node with OPMN to form a manageable cluster.
Configuring the OCMS SIP Containers for High Availability—Use the Application Server Control Console MBean browser to configure parameters affecting high availability in the SIP Servlet container.
Configuring the Edge Proxy Nodes for High Availability—Optional. Required only if using Edge Proxy nodes in the OCMS topology.
Configuring Highly Available SIP Servlet Applications—Edit the SIP Servlet application descriptor files to enable support for high availability. Configure state replication for each application.
Configuring the Proxy Registrar for High Availability—Optional. Required only if using the Proxy Registrar in the OCMS topology.
Table 8-1 Additional Information
For more information on... | See: |
---|---|
OCMS deployment topologies |
Chapter 3, "Deployment Topologies" in this guide |
OCMS installation |
Oracle Communication and Mobility Server Installation Guide |
Operating systems supported by highly available OCMS clusters |
Oracle Communication and Mobility Server Certification Guide |
Configuring a highly available clustered Oracle Application Server environment |
|
Each OCMS node—including the Edge Proxy nodes—must be configured to support high availability.
Following are the main steps in setting up a cluster of OCMS servers:
Associating Nodes with OPMN—Oracle Process Manager and Notification Server provides a command-line interface for process control and monitoring for single or multiple Oracle Application Server components and instances. Using OPMN, you can start and stop each OCMS node and its sub-components.
Starting the Cluster—Starting the cluster with OPMN indicates that all OCMS nodes have been correctly associated with OPMN and are recognized as a cluster.
Verifying the Status of the Cluster—Using OPMN or Enterprise Manager, you can verify that each node in the cluster is up and running.
Stopping the Cluster—Having set up and verified the cluster of OCMS nodes, be sure to stop the cluster before configuring each SIP container for high availability (see "Configuring the OCMS SIP Containers for High Availability").
Setting up a cluster of OCMS nodes requires associating the nodes with OPMN. There are three ways to do this:
Configuring the cluster during Oracle Application Server installation. For more information, refer to the Oracle Application Server Installation Guide.
Associating Nodes with OPMN Using the Dynamic Discovery Method
Associating Nodes with OPMN Using the Discovery Server Method
See also:
For more information regarding configuring and managing clusters using OPMN, see the Oracle Process Manager and Notification Server Administrator's Guide.In this method, you define the same multicast address and port for each Oracle Application Server instance in the cluster. An advantage in using this method is that you do not have to specify the name of each Oracle Application Server instance in the cluster. You can dynamically add or remove instances from the cluster by editing the multicast address and port.
For each Oracle Application Server instance that you want to group in the same cluster, run the following command:
opmnctl config topology update discover="*<multicastAddress>:<multicastPort>"
For example:
> ORACLE_HOME/opmn/bin/opmnctl config topology update discover="*225.0.0.20:6200"
where:
multicastAddress
specifies the multicast address that you want to use for the cluster. The multicast address must be within the valid address range, which is 224.0.1.0 to 239.255.255.255. Note that the multicast address is preceded by an asterisk (*).
multicastPort
can be any unused port number.
Use the same multicast IP and port for all the instances.
On each Oracle Application Server instance where you ran the command in step 1, run opmnctl reload
so that OPMN reads the updated opmn.xml
file.
> ORACLE_HOME/opmn/bin/opmnctl reload
You can define a cluster by specifying the names of the nodes running the Oracle Application Server instances in the opmn.xml
file of each instance. For example: to cluster four instances (node1.mycompany.com, node2.mycompany.com, node3.mycompany.com, node4.mycompany.com), you would perform the following steps.
To associate all nodes with OPMN using the discovery server method:
Run Oracle Application Server on all nodes.
Designate one instance as the discovery server. The discovery server maintains the topology for the cluster.
This example assumes that node1.mycompany.com is the discovery servers for the cluster.
In the opmn.xml
file for all instances in the cluster, specify the node that is running the discovery server, namely node1.mycompany.com in the example.
For example, the opmn.xml
file is changed to include the <discover>
element as follows:
<?xml version="1.0" encoding="UTF-8"?> <opmn xmlns="http://www.oracle.com/ias-instance"> ... <notification-server interface="ipv4"> <port local="6100" remote="6200" request="6003"/> .... <topology> <discover list="node1.mycompany.com:6200"/> </topology> ... </notification-server> <process-manager> ... </process-manager> </opmn>
The value 6200 specifies the port number at which the notification server is listening. Use the remote port number designated in the <port>
sub-element of the <notification-server>
element.
On all server instances, run opmnctl reload
so that OPMN loads the updated opmn.xml
file:
> ORACLE_HOME/opmn/bin/opmnctl reload
Start the cluster using OPMN, by running the following command on each instance in the cluster:
> cd ORACLE_HOME/opmn/bin/ > opmnctl startall
To verify the status of the OCMS nodes in the cluster:
In a web browser, enter the URI of Enterprise Manager running on any SIP container in the cluster:
http://<SIP container URI>:<port number>/em
Enter the administrator user name and password at the prompt.
Enterprise Manager displays the status of the cluster topology.
After verifying the status of the cluster, stop the nodes in the cluster using OPMN so that you can continue configuring the SIP containers (see "Configuring the OCMS SIP Containers for High Availability").
To stop OCMS, execute the following command on each node in the cluster:
> cd ORACLE_HOME/opmn/bin/ > opmnctl stopall
In the Application Server Control Console MBean browser, configure the following parameters under the SIP Servlet Container MBean for each SIP Application Server node:
Configure the Edge Proxy parameter to point to the SIP URI of the Edge Proxy or third-party load balancer if more than one Edge Proxy is used.
Use the following format:
SIP:<Edge Proxy or Load Balancer IP address>:<port>;lr
Configure the DistributableRecordRoute parameter in the following format:
SIP:<SIP Container IP address>:<port>
Remove any appended transport methods (such as transport=tcp) to enable any type of transport to be used between the Edge Proxy and OCMS.
Configure the RecordRoute parameter using the following format:
SIP:<SIP Container IP address>:<port>
Remove any appended transport methods (such as transport=tcp) to enable any type of transport to be used between the Edge Proxy and OCMS.
Configuring the Edge Proxy nodes for high availability involves the following main steps:
Configuring each OCMS node running an Edge Proxy for high availability, as described in "Setting Up a Highly Available Cluster of OCMS Nodes" and "Configuring the OCMS SIP Containers for High Availability".
Pointing the edgeproxy
Mbean to any one of the following:
the IP address of the Edge Proxy node
if using more than one Edge Proxy, use the virtual IP address or host name of the third-party load balancer or DNS server (if clients connect using DNS lookup)
Configuring the interval at which SIP Container nodes ping the Edge Proxy nodes, as well as the number of missed ping intervals before the Edge Proxy nodes remove the offending SIP Container from the routing table. These parameters enable the Edge Proxy node(s) to monitor the health of the SIP Container nodes.
For each Edge Proxy node in the topology, configure the following:
In the Application Server Control Console Mbean Browser, click the edgeproxy
Mbean.
Configure the RecordRoute
parameter to point to one of the following:
If using a single Edge Proxy without a load balancer—Point the parameter to the IP address of the Edge Proxy node
If using more than one Edge Proxy with a load balancer or DNS server—Point the parameter to the virtual IP address or host name of the third-party load balancer or DNS server (if clients connect using a DNS lookup)
Modify the sdp/edgeproxy/conf/edgeproxy.xml
file to include the following:
<oc4j-ping interval="1" allowed-miss-count="2"/>
Following is a sample edgeproxy.xml
file:
The oc4j-ping
element configures in seconds the interval at which the Oracle Application Servers in the cluster ping the Edge Proxy. The allowed-miss-count
attribute specifies the number of missed ping intervals allowed before the Edge Proxy removes the offending Oracle Application Server from the routing table.
<?xml version="1.0" encoding="UTF-8" ?>
<edge-proxy xmlns:xsi="http://www.oracle.com/sdp">
<record-route sip-uri="sip:%IPADDRESS%:%SIPPORT%"/>
<jmx-rmi-connector port="%EPRMIPORT%"/>
<oc4j-ping interval="1" allowed-miss-count="2"/>
<sip-stack ip="%IPADDRESS%">
<listening-point transport="tcp" port="%SIPPORT%" />
<listening-point transport="udp" port="%SIPPORT%" />
</sip-stack>
</edge-proxy>
Verify the status of the Edge Proxy node or nodes in the cluster by doing the following:
See also:
For more information, refer to the "Configuring OCMS in a Clustered Environment with Edge Proxy" chapter in the Oracle Communication and Mobility Server Installation Guide.This section describes how to configure high availability for SIP Servlet applications deployed to a cluster of OCMS nodes.
Enabling High Availability in SIP Servlet Applications—Prior to deployment, each application's descriptor files (web.xml
and sip.xml
) must be configured for high availability. The orion-application.xml
file for each application must also be configured for high availability.
Configuring Application Session Data Replication—The session data of each SIP Servlet application can be replicated to other nodes in the cluster, in the event of node failure.
Configuring High Availability for a Deployed SIP Servlet Application—You can also configure high availability for an application that you have already deployed.
Disabling High Availability at the Application Level—You can remove support for high availability from your SIP Servlet applications.
Upgrading SIP Servlet Applications in OCMS—This section explains how to perform a rolling upgrade on deployed SIP Servlet applications.
Note:
When configuring high availability for SIP Servlet applications that depend upon the Proxy Registrar, the Proxy Registrar must also be configured for high availability. See "Configuring the Proxy Registrar for High Availability" for details.Note:
High availability is not currently supported for converged applications (meaning applications comprising both SIP and HTTP servlets).To configure a highly available SIP Servlet application:
Modify the HOME/j2ee/home/ocms/applications/<application name>/<web module name>/WEB-INF/sip.xml
file to include the <distributable>
element.
For example:
<?xml version="1.0" encoding="UTF-8"?><sip-app> <display-name>proxyregistrarssr</display-name>
<distributable><distributable/>
<!--Servlets-->
<servlet>
<servlet-name>Registrar</servlet-name>
<servlet-class>oracle.sdp.registrar.VoipRegistrarServlet</servlet-class>
<init-param>
<param-name>LocationService</param-name>
<param-value>oracle.sdp.locationdbservice.LocationDbServiceBD
</param-value>
</init-param>
</sip-app>
Modify the HOME/j2ee/home/ocms/applications/<application name>/<web module name>/WEB-INF/web.xml
file to include the <distributable>
element.
For example:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
<display-name>proxyregistrarssr</display-name>
<distributable></distributable>
</web-app>
Modify the HOME/j2ee/home/ocms/application-deployments/<application name>/orion-application.xml file to include the <cluster>
element (see "Additional Information on the cluster Element"). The cluster element can include elements and attributes that control application data replication (see "Configuring Application Session Data Replication" for details).
For example:
<orion-application ... > ... <cluster allow-colocation="false"> <protocol> <peer start-port="7900" range="10" timeout="6000"> <node host="node2.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
Repeat these steps for each application deployed on each OCMS instance.
Important:
Deploy the application symmetrically to all SIP Application Server nodes.Note:
For information about developing highly available SIP Servlet applications, refer to the OCMS Developer's Guide.OCMS supports static peer-to-peer replication, in which you list the names of the OCMS node instances to which you want to replicate session data for the SIP Servlet application.
To set the replication policy:
Edit the ORACLE_HOME/j2ee/home/ocms/application-deployments/<application name>/orion-application.xml
file.
In the <node>
element, list the names of the hosts you want to include in the cluster.
For each node, specify another node in the topology such that all the nodes in the topology are connected in the chain. For example, if you have three Oracle Application Server instances in your topology, node 1 can specify node 2, node 2 can specify node 3, and node 3 can specify node 1.
For example:
On node 1, the <node>
tag specifies node 2:
<orion-application ... > ... <cluster allow-colocation="false"> <protocol> <peer start-port="7800" range="10" timeout="6000"> <node host="node2.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
On node 2, the <node> tag specifies node 3:
<orion-application ... > ... <cluster allow-colocation="false"> <protocol> <peer start-port="7800" range="10" timeout="6000"> <node host="node3.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
On node 3, the <node> tag specifies node 1:
<orion-application ... > ... <cluster allow-colocation="false"> <protocol> <peer start-port="7900" range="10" timeout="6000"> <node host="node1.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
Another way of configuring static replication is to point all the nodes to the same node. In a three-node example, you could point nodes 1 and 2 to node 3, and node 3 can point to node 1 or node 2.
The following elements and attributes are used in this example:
start-port
—This attribute of the <peer>
element specifies the initial port on the host to which the local OC4J process tries to bind to establish peer communication. If this port is not available, OC4J increments the port until it finds an available port. The default value is 7800.
node
—This element specifies the peer node. The host and port attributes of this element define the name of the node address and the port used for peer communication. The default port number is 7800.
range
—This attribute of the <peer>
element applies to the ports specified in each <node>
element, rather than the value of the start-port
attribute. The range
attribute defines how many times the port value should be incremented if the specified port is unavailable.
allow-colocation
—Specifies whether or not application state is replicated to other Oracle Application Server instances running on the same host. The default is true.
Following is a brief glossary of elements and attributes of the <cluster>
element used in the orion-application.xml
file. These elements may be useful when configuring a cluster of OCMS nodes.
Note:
For additional information regarding the<cluster>
element and its sub-elements, refer to the chapter "Configuring Application Clustering" in Containers for J2EE Configuration and Administration Guide.The following elements and attributes are useful for OCMS clustering:
<cluster>
—Used to configure clustering both for OAS nodes as well as specific SIP servlet applications. Used in the orion-application.xml
and application.xml
files.
enabled
—Specifies whether clustering is enabled. The default value is true
.
group-name
—The name to use when establishing replication group channels. If not supplied, the application name as defined in server.xml
—the OAS server configuration file—is used by default. New group channels are created for each enterprise application. If a value is specified, the application and all child applications use the channels associated with this group name.
allow-colocation
—Specifies whether to allow application state to be replicated to a node residing on the same host machine. The default value is true
. However, this attribute should be set to false
if multiple hosts are available. If multiple OAS instances are instantiated on the same machine, different listener ports must be specified for each instance in the default-web-site.xml
, jms.xml
, and rmi.xml
configuration files.
write-quota
—The number of other group members to which the application state should replicate to. This attribute enables reducing overhead by limiting the number of nodes to which state is written. The default value is 1
. This attribute is
<property-config>
—Contains data required to use the JavaGroups group communication protocol to replicate session state across nodes in the cluster.
url
—A link to a JavaGroups XML configuration file.
property-string
—A string containing the properties that define the creation of the JavaGroups JChannel.
<protocol>
—Defines the mechanism to be used for data replication (which, for OCMS, is <peer>
).
<peer>
—Includes the configuration required to use peer-to-peer (P2P) communication for replication.
start-port
—The first port which the node attempts to allocate for peer communication. OAS continues incrementing this value until it finds an available port. The default port is 7800
.
range
—The number of times OAS increments the port value specified by start-port
. The default value is 5
increments.
timeout
—The length of time, in milliseconds, to wait for a response from a peer while looking for a potential peer node. The default value is 3000
milliseconds.
bind_addr
—The Network Interface Card (NIC) to bind to. This is useful in topologies with OAS host computers that have multiple network cards, each with its own IP address.
<node>
—Includes the host name and port of the node to poll when using static peer-to-peer communication. One or more instances of this element can be supplied within a <peer>
element.
If the SIP Servlet application has already been developed and deployed but not configured for high availability, do the following:
Undeploy the SIP Servlet application.
Unpack the application EAR.
Modify the sip.xml
and web.xml
files to include the <distributable>
element, as described in "Enabling High Availability in SIP Servlet Applications". To edit the sip.xml
and web.xml
files, do the following:
Create a new folder and name it <Your SIP application>.
Unpack the EAR file to the new folder.
Unpack the WAR file inside the EAR file to the folder <Your SIP application>/<WAR module name>
.
Edit the following files:
<Your SIP application>/<WAR module name>/WEB-INF/sip.xml <Your SIP application>/<WAR module name>/WEB-INF/web.xml
Under <Your SIP application>/<WAR module name>
, re-package the contents of the WAR file using the original WAR file name.
Package the contents of the <Your SIP application>/<WAR module name>
into an EAR file. Use the file name of the original EAR file.
Delete the <Your SIP application>/<WAR module name>
folder.
Re-deploy the application EAR to the SIP Servlet Container.
To remove an application from the cluster:
In a text editor, open the application specific orion-application.xml
file.
Set the enabled
attribute of the <cluster>
element to false
. For more information, see "Configuring Application Session Data Replication" and "Additional Information on the cluster Element" for more information.
For example:
<orion-application ... >
...
<cluster enabled="false">
<protocol>
<peer start-port="7800" range="10" timeout="6000">
<node host="node2.mycompany.com" port="7900"/>
</peer>
</protocol>
</cluster>
</orion-application>
Save the orion-application.xml
file.
SIP Servlet applications can be upgraded using a rolling upgrade procedure that minimizes downtime.
To perform a rolling upgrade of a SIP servlet application in OCMS:
On the OCMS node where you want to upgrade the SIP Servlet application, execute the following command to stop running all OCMS processes on the node:
ORACLE_HOME/opmn/bin/opmnctl shutdown
Comment out the <topology>
element in the ORACLE_HOME/opmn/conf/opmn.xml
file in order to remove the SIP Application Server from the cluster.
Restart the SIP container by running the following command:
ORACLE_HOME/opmn/bin/opmnctl startall
Upgrade the SIP Servlet application on the SIP container you took out of the cluster.
Shut down the SIP container again so that you can put it back in the cluster:
ORACLE_HOME/opmn/bin/opmnctl shutdown
Uncomment the <topology>
element in the opmn.xml
file in order to place the SIP container back into the cluster.
Place the SIP container back into the cluster by executing the following command:
ORACLE_HOME/opmn/bin/opmnctl startall
The SIP Servlet application upgrades following the completion of all in-progress calls.
Repeat the process with the remaining SIP containers.
Configuring the Proxy Registrar for high availability involves the following main steps:
Configuring the orion-application.xml
file for the Proxy Registrar application, as described in "Configuring Application Session Data Replication"
Note:
For each OCMS node in the cluster, Oracle TimesTen and OCMS must be installed and run under the same non-root user name at the operating system level.Replicating an Oracle TimesTen In-Memory database in OCMS involves the following:
Creating and Seeding Replication Tables—In the TimesTen database, create replication-related tables. Then seed the database with a list of tables that require replication.
Configuring Replication in Oracle TimesTen In-Memory Database—Configure clusters and instances, including running a replication script followed by a database duplication script.
Configuring Failover and Recovery for Oracle TimesTen In-Memory Database—Configure recovery procedures in the event of a failed instance.
Note:
Oracle TimesTen database can be replicated synchronously or asynchronously. The current version of OCMS supports synchronous replication only.For each node in the cluster, do the following:
Run the following perl scripts:
$TT_HOME/bin/ttIsql -connStr "DSN=ocmsdb" -f $ORACLE_HOME/sdp/replication/sql/replication.drop.timesten.sql $TT_HOME/bin/ttIsql -connStr "DSN=ocmsdb" -f $ORACLE_HOME/sdp/replication/sql/replication.timesten.sql
The following tables are created in the TimesTen database:
clusters cluster_id INT NOT NULL, cluster_name VARCHAR(255) NOT NULL UNIQUE cluster_replication VARCHAR(64) NOT NULL, instances instance_id INT NOT NULL, instance_name VARCHAR(255) NOT NULL UNIQUE, hostname VARCHAR(255) INLINE NOT NULL, port INT NOT NULL cluster_instance_map cluster_map_id INT NOT NULL, cluster_id INT NOT NULL, instance_id INT NOT NULL replication_params replication_param_id INT NOT NULL, replication_param_name VARCHAR(255) NOT NULL UNIQUE, replication_param_value VARCHAR(255) NOT NULL, replication_tables table_id INT NOT NULL, table_name VARCHAR(255) NOT NULL UNIQUE replication_sequences account_seq role_seq credentials_seq realm_seq private_identity_seq property_seq public_identity_seq lsid
Modify the file $ORACLE_HOME/sdp/replication/bin/
seed_clusters_test_sync.sql
to suit your deployment. By default, this script configures one cluster of two OCMS nodes.
Execute the following command:
$TT_HOME/bin/ttIsql -connStr "DSN=ocmsdb" -f $ORACLE_HOME/sdp/replication/sql/seed_clusters_test_sync.sql
This command seeds the TimesTen database with all the cluster and instance information required for configuring replication.
Following are the tables that require replication:
Schema properties:
properties
Cluster and instance configurations:
clusters instances cluster_instance_map replication_params replication_tables
Location Service
locationservice
User Service
public_identity private_identity
Security Service
account role user_role credentials realm
Note:
Sequences are excluded from replication.Note:
It is only possible to configure replication between like operating systems, for example two Linux computers.This section describes how to configure replication in the Oracle TimesTen in-memory database instances:
Configuring Replication in the First Oracle TimesTen Database Instance in the Cluster
Configuring Replication in the Second Oracle TimesTen Database Instance in the Cluster
To configure replication for the first Oracle TimesTen In-Memory database in a cluster, do the following:
On each computer, add $TT_HOME/lib
to the environment variable LD_LIBRARY_PATH
.
On the first computer in the cluster, execute the following command:
$ORACLE_HOME/sdp/replication/bin/create_replication_sync.pl
When prompted for the hostname, enter the fully qualified domain name.
The following error message may display, however you can safely ignore it:
[TimesTen][TimesTen 6.0.7 ODBC Driver][TimesTen]TT12027: The agent is already stopped for the data store. Dropping Replication Scheme: ocms_rep.repscheme [TimesTen][TimesTen 6.0.7 ODBC Driver][TimesTen]TT8160: REPLICATION OCMS_REP.REPSCHEME not found -- file "repDDL.c", lineno 1436, procedure "sbRepCheckOrDrop()"
The replication scheme is now configured on the database.
Verify that the replication scheme has been configured in the data store by executing the following command at the TimesTen prompt:
$TT_HOME/bin/ttisql -connstr "dsn=ocmsdb" Command> repschemes;
Verify that replication scheme OCMS_REP.REPSCHEME
has been successfully created.
If you need to make any changes to the names of the TimesTen instances, for example, if you opt to replicate to a different instance altogether, do the following:
Drop and re-create the replication tables by executing the following commands:
$TT_HOME/bin/ttisql -connstr "dsn=ocmsdb" Command> drop replication ocms_rep.repscheme; Command> quit
Go back to "Creating and Seeding Replication Tables".
Configure TimesTen to automatically start replication—as well as the replication agent if it is not running—upon restarting TimesTen by executing the following command:
$TT_HOME/bin/ttAdmin -repPolicy always ocmsdb
Create an internal TimesTen user called ocmsuser
and assign a password to the user name by executing the following command in TimesTen:
Command> create user ocmsuser IDENTIFIED BY 'password';
Grant the user administrative privileges:
Command> grant admin to ocmsuser;
To configure replication for the second Oracle TimesTen Database in the cluster:
If OCMS is running, stop running OCMS by executing the following command:
opmnctl stopproc process-type=ocms
Stop running Oracle TimesTen by executing the following command:
opmnctl stopproc ias-component=TIMESTEN
Start the TimesTen daemon by executing the following command:
$TT_HOME/bin/ttdaemonadmin -start
Configure the ocmsdb data store to have the same PermSize as that of the first computer. For example, if the first computer has 512 MB PermSize allocated to ocmsdb, allocate 512 MB to the second ocmsdb data store.
On Linux, edit $TT_HOME/info/sys.odbc.ini
and change the PermSize corresponding to the ocmsdb entry.
Delete the ocmsdb datastore on this computer by executing the following command:
ttdestroy -connstr "dsn=ocmsdb"
The datastore will be replicated from the first OCMS computer.
Duplicate the ocmsdb datastore from the first computer as follows:
Execute the following command:
perl $ORACLE_HOME/sdp/replication/bin/duplicate_db_replication.pl
At the prompt, enter the fully qualified domain name of the first computer.
At the prompt, enter the fully qualified domain name of the second computer (the computer you are currently on which you are currently working).
At the prompt, enter the user name and password of the TimesTen user you created on the first computer, for example, ocmsuser.
The datastore may take a few moments to copy and replicate, depending on the size of the datastore.
Stop the TimesTen daemon as follows:
$TT_HOME/bin/ttdaemonadmin -stop
Run the following command to configure replication to start automatically when TimesTen restarts:
$TT_HOME/bin/ttAdmin -repPolicy always ocmsdb
Start TimesTen using opmnctl:
opmnctl startproc ias-component=TIMESTEN
Start OCMS:
opmnctl startproc process-type=ocms
This section describes the following topics:
TimesTen is managed by OPMN, such that OPMN immediately revives a failed instance. The replication policy is configured to auto-start when TimesTen starts up and no further action is required. If the replication agent fails, TimesTen immediately restarts it.
As any given application instance is tied to an in-memory instance of the TimesTen database, the application instance cannot fail over to another instance of the TimesTen database.
Typically, when an application instance fails, requests are no longer sent to the failed instance. No action is required on the other instances in the cluster. When the application instance comes back online, however, a recovery procedure must be followed.
If you have manually brought down an instance for a few minutes, you can simply restart it. The replication policy is configured to auto-start when TimesTen starts, such that no further action is required.
If an instance has failed for an extended period of time (over an hour, for example), it is recommended to delete the database on the failed instance and duplicate it from any another instance in the cluster.
To recover a failed instance, do the following:
Stop replication on the failed instance.
Reset the replication policy to manual, so that the replication agent can terminate properly.
$TT_HOME/bin/ttAdmin -repPolicy manual ocmsdb
Run the following perl script to recover replication:
perl $ORACLE_HOME/sdp/replication/bin/recover_replication_sync.pl
Change replication policy back to always by executing the following command:
$TT_HOME/bin/ttAdmin -repPolicy always ocmsdb
This section discusses the following replication troubleshooting issues:
When attempting to duplicate the database from the first instance to the second instance, the following error message might display:
Unable to connect to the replication agent on the first instance
This message indicates that the replication agent may not be running.
To resolve this error, do the following:
Make sure the replication agent is running on the first database instance by executing the following command:
$TT_HOME/bin/ttStatus
The output of this command should include entries for replication with corresponding process IDs.
The replication policy might not be configured as always
on. To configure the replication policy as always
on, execute the following command:
$TT_HOME/bin/ttAdmin -repPolicy always ocmsdb
When attempting to connect to the database on the first instance, the following error message may display:
Master Catchup Required. New Connections are not allowed.
To resolve this error, drop and re-create the replication scheme as follows:
On the first instance, edit $TT_HOME/info/sys.odbc.ini
and set ForceConnect=1
for the ocmsdb data store. This enables connections and modifications to the database.
Next, you must drop the existing replication scheme, create a new replication scheme, and re-create the replication sequences. To do this, execute the following commands:
$TT_HOME/bin/ttAdmin -repPolicy manual ocmsdb $TT_HOME/bin/ttAdmin -repStop -connstr "dsn=ocmsdb" perl $ORACLE_HOME/sdp/replication/bin/create_replication_sync.pl
Execute the following command to configure the replication policy as always
on:
$TT_HOME/bin/ttAdmin -repPolicy always ocmsdb
Repeat for the other database instance, then duplicate the database from the first instance to the second.