The use of journaling in a clustered system also makes it possible to shadow a Caché cluster. In a cluster, each node manages its own journal files, which contain data involving private or cluster-mounted databases. The shadow mirrors the changes to the databases (assuming all changes are journaled) on a Caché system that is connected to the cluster via TCP. The fol-lowing diagram gives an overview of the cluster shadowing process:
Figure 5–1: Cluster Shadowing Overview
The destination shadow connects to the specified Caché superserver on the cluster, requesting a list of journal files at or after the specified start location (the combination of cluster start time and cluster journal sequence number), one starting file for each cluster member.
For each node (with a unique CSN) returned from the source cluster, the shadow starts a copier process that copies journal files, starting with the file returned, from the server to the shadow. Each copier acts as a semi-independent shadow itself, similar to a nonclustered block-mode shadow.
Once all copiers are up and running, the cluster shadow starts a dejournaling process that applies journal entries from the copied journal files to the databases on the shadow side respecting the cluster journal sequence numbers of each journal record. The cluster shadow maintains a list of current live members (including port numbers and IP addresses) of the cluster which it receives from the source cluster.
• Configuring a Cluster Shadow
• Cluster Shadowing Limitations
Note: The shadow does not have to be a clustered system. The word “ cluster ” in cluster shadowing refers to the source database server, not the shadow.
5.3.1 Configuring a Cluster Shadow
You must provide several types of information to properly configure a cluster shadow. An overview of the required data items is divided into the following categories:
Establishing a Connection
Although a cluster is identified by the PIJ directory that all its member nodes share, the uniqueness of the identifier does not go beyond the physical cluster that hosts the Caché cluster. The shadow needs a way to make a TCP connection to the source cluster; therefore, on the shadow you must specify the IP address or host name of one member of the Caché cluster and the port number of the superserver running on that member. Also provide the shadow with a unique identity to distinguish it from other shadows, if any, in the same Caché instance.
Identifying the Starting Location
Configure the shadow to identify the journal starting location— a cluster start time (CSI) and, optionally, a cluster journal sequence number— for dejournaling. If you do not specify a cluster journal sequence number, dejournaling starts at the beginning of the cluster session.
Copying Journal Files
Similar to noncluster shadowing, specify a directory to put the journal files copied over from the cluster. However, a single directory is not adequate; journal files from different members of the cluster must be kept separate. The directory you specify serves as the parent of the directories for the shadow copies of the journal files. In fact, the shadow creates directories on the fly to keep up with the dynamic nature of the cluster components.
At run time, for each journal directory on the server cluster, the shadow sets up a distinct subdirectory under the user-specified parent directory and copies journal files from a journal directory on the server to its corresponding directory on the shadow—this is called redirection of journal files. The subdirectories are named by sequential numbers, starting with 1. You cannot override a redirection by specifying a different directory on the shadow for a journal directory on the server.
Redirecting Dejournaled Transactions
As with nonclustered shadowing, specify database mapping, or redirections of dejournaled Set and Kill transactions.
There are two ways to provide the information to set up a cluster destination shadow:
• Using the Management Portal
• Using Caché Routines
5.3.1.1 Using the Management Portal
You can configure a shadow server using the Management Portal. Perform the following steps:
1. From the [System Administration] > [Configuration] > [Connectivity] > [Shadow Server Settings] page of the Management Portal, follow the procedure described in the Configuring the Destination Shadow section in the “ Shadowing ” chapter.
Use the following specifics particular to cluster shadowing:
a. Database Server — Enter the IP address or host name (DNS) of one member of the source cluster to which the shadow will connect.
b. Database Server Port # — Enter the port number of the source specified in the previous step.
2. After entering the location information for the source instance, click Select Source Event to choose where to begin shadowing. A page displays the available cluster events from the cluster journal file directory.
3. Click Advanced to fill in the Journal file directory field. Enter the full name, including the path, of the journal file directory on the destination shadow system, which serves as the parent directory of shadow journal file subdirectories, created automatically by the shadow for each journal directory on the source cluster. ClickBrowse for help in finding the proper directory.
4. After you successfully save the configuration settings, add database mapping from the cluster to the shadow.
5. Next to Database mapping for this shadow click Add to associate the database on the source system with the directory on the destination system using the Add Shadow Mapping dialog box.
6. In the Source database directory box, enter the physical pathname of the source database file—the CACHE.DAT file.
Enter the pathname of its corresponding destination shadow database file in the Shadow database directory box, and then click Save.
7. Verify any pre-filled mappings and click Delete next to any invalid or unwanted mappings. Shadowing requires at least one database mapping to start.
8. Start shadowing.
5.3.1.2 Using Caché Routines
You can also use the shadowing routines provided by Caché to configure the cluster shadow. Each of the examples in this section uses the technique of setting a return code as the result of executing the routine. After which you check the return code for an error or 1 for success.
To initially configure the cluster shadow:
Set rc=$$ConfigCluShdw^SHDWX(shadow_id,server,jrndir,begloc)
is ...
Where ...
A string that uniquely identifies the shadow shadow_id
Consists of the superserver port number and IP address or host name of one cluster node, delimited by a comma
server
Parent directory of shadow journal file subdirectories, where journal files fetched from the source cluster are stored on the destination shadow, one subdirectory for each journal directory on the source cluster
jrndir
Beginning location consisting of a cluster session ID (cluster startup time, in YYYYMMDD HH:MM:SS format) and a cluster sequence number, delimited by a comma
begloc
You can run the routine again to change the values of server, jrndir, or begloc. If you specify a new value for jrndir, only subsequent journal files fetched from the source are stored in the new location; journal files already in the old location remain there.
You can also direct the shadow to store journal files fetched from the journal directory, remdir, on the source in a local repository, locdir, instead of the default subdirectory of jrndir. Again, this change affects only journal files to be fetched, not the journal files that have been or are being fetched.
Set rc=$$ConfigJrndir^SHDWX(shadow_id,locdir,remdir)
This specifies that Set and Kill transactions from the source directory, remdir, be redirected to the shadow directory, locdir.
Unlike journal files, there is no default redirection for a source database—if it is not explicitly redirected, Set and Kill transactions from that database are ignored by the dejournaling process of the shadow.
Finally, to start and stop shadowing:
Set rc=$$START1^SHDWCLI("test") Set rc=$$STOP1^SHDWCLI("test")
See Shadow Information Global and Utilities for more information.
5.3.2 Cluster Shadowing Limitations
There are a few limitations in the cluster shadowing process.
Database updates that are journaled outside a cluster are not shadowed. Here are two examples:
• After a cluster shuts down, if a former member of the cluster starts up as a stand-alone system and issues updates to some (formerly clustered) databases, the updates do not appear on the shadow.
• After a formerly stand-alone system joins a cluster, the new updates made to its private databases appear on the shadow (if they are defined in the database mapping), but none of the updates made before the system joined the cluster appear.
For this reason, joining a cluster on the fly (by cluster-mounting a database) should be planned carefully in coordination with any shadow of the cluster.
In cluster shadowing, there is latency that affects the dejournaler. Journal files on the destination shadow side are not nec-essarily as up to date as what has been journaled on the source cluster. The shadow applies production journals asynchronously so as not to affect performance on the production server. This results in possible latency in data applied to the shadow.
Only one Caché cluster can be the target of a cluster shadow at any time, although there can be multiple shadows on one machine. There is no guarantee regarding the interactions between the multiple shadows, thus it is the user’s responsibility to ensure that they are mutually exclusive. If you have a single instance with multiple shadows pointing at different clusters, it is your responsibility to ensure that the shadow datasets are mutually exclusive. For example, assume you have two clusters (A and B) shadowed on a single machine: cluster A has datasets X, Y, and Z; cluster B has datasets L, M, and N.
Since Caché does not guarantee that datasets X (cluster A) and L (cluster B) are mutually exclusive during the dejournaling process (that is, that one shadow is dejournaling dataset X while the other is dejournaling dataset L), it is your responsibility to ensure that the datasets do not overlap.
Note: Exclude Caché databases from RTVScan when using Symantec Antivirus software to avoid the condition of the cluster shadow hanging on Windows XP. See the Release Notes for Symantec AntiVirus Corporate Edition 8.1.1 for detailed information.