The following sections describe the different aspects of your MultiSite use model.
In a ClearQuest user database, all of the data that you enter must be from the same code page. In a MultiSite environment, enforcement of a single code page can be difficult because not all languages use the same code page. For example, English and many European languages use the 1252 code page, but Japanese uses the 932 code page. Before you configure MultiSite, you must decide on the language used by the majority of users and set the data code page value of the database set to the code page for that language.
For more information about code pages and about setting the data code page value, see the Administrator’s Guide for Rational ClearQuest.
By default, only one machine per site is configured to administer schema repositories and user databases and use the multiutil commands. This machine is designated in two ways:
If you want to run multiutil from a machine other than those at which activate and mkreplica –import were run, you must configure the machine to access the schema repository (database set) at your site.
To configure a UNIX machine, use the cqreg add_dbset subcommand. For more information about this command, type man cqreg at a UNIX prompt.
To configure a Windows machine, use the installutil adddbset command:
installutil adddbset dbset-name db-vendor server-hostname
{ db-pathlename.suffix | database-name }
ro-login-name ro-login-password connection-options
dbset-name is the name of the schema repository and is always specified in the following format:
CQMS.clan-name.site-name
Connection options:
Oracle database
|
HOST=host;SID=sid; server_ver=server-version-number; client_ver=client-version-number
|
All others
|
""
|
The following example shows how to use the installutil adddbset command to connect to the schema repository in the boston site of the telecomm clan. Notice that the dbset-name is CQMS.TELECOMM.BOSTON.
E:\Program Files\Rational\ClearQuest> installutil adddbset CQMS.TELECOMM.BOSTON ORACLE bar_host cquser cquser password client_ver=7.0
For more information about installutil and connecting to schema repositories, see the Administrator’s Guide for Rational ClearQuest.
Your plan should state which replicas will master records and other objects. After you create the replicas in the family, you can change mastership of objects. For more information, see Enabling Independent Development: Mastership and Changing Mastership of Database Objects.
Mastership changes are communicated among replicas by the standard synchronization mechanism. Depending on your workflow, mastership changes for some objects may need to occur more often. For example, the mastership of a record may need to be transferred among replicas several times during its lifecycle.
To facilitate these mastership changes, use one of the following methods to streamline the request for mastership process for records:
There are several methods for transporting update and replica-creation packets. The method you choose depends on how your sites are connected, how quickly you must transfer packets, and how important security is. For more information, see Choosing a Transport Method.
The synchronization pattern for a family defines which replicas exchange update packets and the direction of exchange. Figure 2 shows a simple synchronization pattern, involving one point-to-point update. All updates need not be point to point, however, because they are cumulative. Suppose that the following updates take place among three replicas:
Update 1: Replica 1 sends changes to Replica 2
Update 2: Replica 2 sends changes to Replica 3
There is no need for Replica 1 to update Replica 3 directly, because the changes from Update 1 are included in Update 2. This feature gives you flexibility in devising update strategies and patterns. For efficiency, a single update can be targeted at multiple replicas, for example, all other replicas in a family.
In general, you can implement any update topology, as dictated by organizational structures, communications/transportation costs, and so on. Figure 7 shows a simple peer-to-peer synchronization pattern, and Figure 8 shows a double-hub hierarchical pattern.
Your choice of pattern depends on the following factors:
The following sections describe unidirectional and bidirectional exchanges and the most common synchronization patterns.
Synchronization can be unidirectional or bidirectional, as shown in Figure 9.
In most cases, you will use bidirectional synchronization. Unidirectional synchronization is suitable in situations like these:
Unidirectional updates carry some risk. For example, an accidental change of mastership cannot be fixed, and restoring from a replica that does not exchange updates directly with the broken replica involves extra work. Also, you must ensure that no work is done accidentally in a read-only replica; you can do this by creating hooks.
The one-to-one and ring (or round-robin) patterns in Figure 10 and Figure 11 are simple patterns that are most suitable for small numbers of replicas. As the number of replicas increases, so does the amount of time for changes originating at one replica to be received at a replica at the other side of the ring.
In the hub patterns (Figure 12 and Figure 13), the hub replicas exchange packets with all spoke replicas. In the tree pattern (Figure 14), the root replicas exchange packets with branch replicas.
Advantages:
Disadvantages:
In the many-to-many synchronization pattern (Figure 15), each replica exchanges packets with all other replicas
Advantages:
Disadvantages:
The synchronization schedule for a family defines when replicas in the family send and receive updates. The schedule is affected by many factors, including the rate of development at different sites, the connections among sites, and whether you use MultiSite as a backup strategy.
Consider the following issues when planning your synchronization strategy:
If you schedule synchronizations frequently, you lose less work if a replica is deleted accidentally and you must restore it from backup. Also, merging is simpler because fewer changes have been made.
Make sure that synchronizations do not overlap with backups.
Take different time zones into account when you send an update or set up automated updates. Figure 16 illustrates synchronization among replicas in multiple time zones.
Many changes are recorded in the schema repository and the user database, and oplog entries are created in both operation logs. We recommend that you synchronize your schema repositories first, and then synchronize the user databases.
For example, the administrators for the family in Figure 8 make the following decisions:
Figure 16 shows the synchronization timeline for the hub-spoke updates (but not the hourly hub-to-hub updates). This timeline accounts for time zone differences and includes extra time to make sure that each synchronization phase completes before another begins.
We recommend that you perform regular backups of your vendor databases at all sites. If the database server machine crashes or you lose the database storage area, you can restore the database from the backup copy and use the replica restoration procedure to replace any missing operations. (See Restoring Database Replicas.)
When a command makes a change to a replica, an entry is recorded in the replica’s operation log. For more information about this mechanism, see The Operation Log. Also, when you export an update packet, an export_sync record is created for each target replica. These records are used by the recoverpacket command to reset a replica’s epoch number matrix.
You can scrub oplog entries and export_sync records to reclaim disk space and database records, but you must keep them long enough to ensure that you can recover from replica failures and packet losses. The following sections give guidelines for configuring scrubbing frequency.
Oplog entries must be kept for a significant period of time. They are required when the replica generates update packets. Oplog entries also may be required to help other replicas recover from catastrophic failures. If no replica can supply these entries, the replica being restored must be re-created. (See Restoring a Replica from Backup.) Because of the need to use oplog entries during synchronization, your synchronization strategy determines how often oplogs can be scrubbed.
By default, an oplog entry is never scrubbed. Do not change this setting until you establish the synchronization pattern in the family and verify that packets are being exported and imported successfully.
When it is safe to delete oplog entries for a replica:
Each replica must keep entries for as long as necessary to allow restorereplica operations to complete successfully. The frequency with which you scrub oplog entries depends on the following factors:
Frequency of synchronization refers to both how often updates are exported and how often they are imported at other replicas. Also, consider setting up a verification scheme to ensure that packets are processed successfully at other replicas before any oplog entries are scrubbed.
For example, if a replica is backed up weekly at all sites and you want to be able to restore to the backup from two weeks ago, each replica must keep three weeks of oplog entries. If replicas synchronize weekly, you must assume that the weekly packet hasn’t been sent to the other replica, and add another week. Finally, for extra security, add another month. The result is a scrubbing time of two months.
multiutil scruboplog -clan telecommunications -site sanfran_hub -family PRODA -user sfadmin -password secret -before 31-Oct-2001
Caution: If a replica’s oplog entries are scrubbed before they are included in an update packet, you cannot export update packets from the replica. This is a serious error and compromises the integrity of the entire family.
export_sync records are not necessary for normal synchronization operation. They are different from export event records, which also record synchronization exports.
export_sync records are date-based records used by the recoverpacket command to reset a replica’s epoch number matrix. If you do not use this packet recovery method (because you use lsepoch/chepoch), you can scrub these records aggressively. If you use the recoverpacket command, you must keep export_sync records for the number of days that elapse between backups. (See Recovering from Lost Packets.)
export_sync records are scrubbed with the same frequency as oplog entries.
On Windows, if the pathname of a receipt handler or a shipping order contains spaces, DOS “short name” resolution must be enabled for the file system on which the receipt handler or shipping order is located. This property is enabled by default. If this property is not enabled, the shipping server cannot invoke the receipt handler or process the shipping order.