Managing Enhanced Clusters (Sun Java System Message Queue 4.3 Administration Guide)

Sun Java System Message Queue 4.3 Administration Guide

Managing Enhanced Clusters

This section presents step-by-step procedures for performing a variety of administrative tasks for an enhanced cluster:

Connecting Brokers into an Enhanced Cluster

Because enhanced clusters are self-configuring, there is no need to explicitly specify the list of brokers to be included in the cluster. Instead, all that is needed is to set each broker’s configuration properties appropriately and then start the broker; as long as its properties are set properly, it will automatically be incorporated into the cluster. Enhanced Broker Cluster Properties describes the required properties, which include vendor-specific JDBC database properties.

Note –

In addition to creating an enhanced cluster as described in this section, you must also configure clients to successfully reconnect to a failover broker in the event of broker or connection failure. You do this by setting the imqReconnectAttempts connection factory attribute to a value of -1.

The property values needed for brokers in an enhanced cluster can be set separately in each broker’s instance configuration file, or they can be specified in a cluster configuration file that all the brokers reference. The procedures are as follows:

To Connect Brokers Using a Cluster Configuration File

The method best suited for production systems is to use a cluster configuration file to specify the configuration of the cluster.

Create a cluster configuration file specifying the cluster’s high-availability-related configuration properties.

Enhanced Broker Cluster Properties shows the required property values. However, do not include the imq.brokerid property in the cluster configuration file; this must be specified separately for each individual broker in the cluster.

Specify any additional, vendor-specific JDBC configuration properties that might be needed.

The vendor-specific properties required for MySQL and HADB are shown in Example 8–1 and Example 8–2, respectively.

For each broker in the cluster:
1. Start the broker at least once, using the imqbrokerd command.
  
  The first time a broker instance is run, an instance configuration file (config.properties) is automatically created.
2. Shut down the broker.
  
  Use the imqcmd shutdown bkr command.
3. Edit the instance configuration file to specify the location of the cluster configuration file.
  
  In the broker’s instance configuration file, set the imq.cluster.url property to point to the location of the cluster configuration file you created in step 1.
4. Specify the broker identifier.
  
  Set the imq.brokerid property in the instance configuration file to the broker’s unique broker identifier. This value must be different for each broker.

Place a copy of, or a symbolic link to, your JDBC driver’s .jar file in the Message Queue external resource files directory, depending on your platform (see Appendix A, Platform-Specific Locations of Message Queue Data):

Create the database schema needed for Message Queue persistence.

Use the imqdbmgr create tbl command; see Database Manager Utility.

Restart each broker with the imqbrokerd command.

The brokers will automatically register themselves into the cluster on startup.

To Connect Brokers Using Instance Configuration Files

For each broker in the cluster:
1. Start the broker at least once, using the imqbrokerd command.
  
  The first time a broker instance is run, an instance configuration file (config.properties) is automatically created.
2. Shut down the broker.
  
  Use the imqcmd shutdown bkr command.
3. Edit the instance configuration file to specify the broker’s high-availability-related configuration properties.
  
  Enhanced Broker Cluster Properties shows the required property values. Be sure to set the brokerid property uniquely for each broker.
4. Specify any additional, vendor-specific JDBC configuration properties that might be needed.
  
  The vendor-specific properties required for MySQL and HADB are shown in Example 8–1 and Example 8–2, respectively.

Place a copy of, or a symbolic link to, your JDBC driver’s .jar file in the Message Queue external resource files directory, depending on your platform (see Appendix A, Platform-Specific Locations of Message Queue Data):

Create the database schema needed for Message Queue persistence.

Use the imqdbmgr create tbl command; see Database Manager Utility.

Restart each broker with the imqbrokerd command.

The brokers will automatically register themselves into the cluster on startup.

Adding and Removing Brokers in an Enhanced Cluster

Because enhanced clusters are self-configuring, the procedures for adding and removing brokers are simpler than for a conventional cluster.

To Add a New Broker to an Enhanced Cluster

Set the new broker’s high-availability-related properties, as described in the preceding section.

You can do this either by specifying the individual properties in the broker’s instance configuration file (config.properties) or, if there is a cluster configuration file, by setting the broker’s imq.cluster.url property to point to it.

Start the new broker with the imqbrokerd command.

The broker will automatically register itself into the cluster on startup.

To Remove a Broker from an Enhanced Cluster

Make sure the broker is not running.

If necessary, use the command
```
   imqcmd shutdown bkr
```
to shut down the broker.

Remove the broker from the cluster with the command
```
   imqdbmgr remove bkr
```
This command deletes all database tables for the corresponding broker.

Preventing or Forcing Broker Failover

Although the takeover of a failed broker’s persistent data by a failover broker in an enhanced cluster is normally automatic, there may be times when you want to prevent such failover from occurring. To suppress automatic failover when shutting down a broker, use the -nofailover option to the imqcmd shutdown bkr subcommand:

   imqcmd shutdown bkr  -nofailover  -b hostName:portNumber

where hostName and portNumber are the host name and port number of the broker to be shut down.

Conversely, you may sometimes need to force a broker failover to occur manually. (This might be necessary, for instance, if a failover broker were to itself fail before completing the takeover process.) In such cases, you can initiate a failover manually from the command line: first shut down the broker to be taken over with the -nofailover option, as shown above, then issue the command

   imqcmd takeover bkr  -n brokerID

where brokerID is the broker identifier of the broker to be taken over. If the specified broker appears to be running, the Command utility will display a confirmation message:

   The broker associated with brokerID last accessed the database # seconds ago. 
   Do you want to take over for this broker?

You can suppress this message, and force the takeover to occur unconditionally, by using the -f option to the imqcmd takeover bkr command:

   imqcmd takeover bkr  -f  -n brokerID

Note –

The imqcmd takeover bkr subcommand is intended only for use in failed-takeover situations. You should use it only as a last resort, and not as a general way of forcibly taking over a running broker.

Backing up a Shared Data Store

For durability and reliability, it is a good idea to back up an enhanced cluster’s shared data store periodically to backup files. This creates a snapshot of the data store that you can then use to restore the data in case of catastrophic failure. The command for backing up the data store is

   imqdbmgr backup  -dir backupDir

where backupDir is the path to the directory in which to place the backup files. To restore the data store from these files, use the command

   imqdbmgr restore  -restore backupDir