The global node ^SYS("shdwcli”) is where shadow client information is maintained. Most of the values are available through the utilities ShowState^SHDWX, ShowError^SHDWX, and
ShowWhere^SHDWX.
Running ShowState^SHDWX displays most of the data contained in the global:
%SYS>d ShowState^SHDWX("clutest",1) Redirection of Global Sets and Kills:
^^_$1$DKB300:[TEST.CLU.5X] -> ^^_$1$DKA0:[TEST.CLU.5X]
Redirection of Master Journal Files:
Base directory for auto-redirection: _$1$DKA0:[TEST.5X.SHADOW]
_$1$DRA2:[TEST.5X.JOURNAL] -> _$1$DKA0:[TEST.5X.SHADOW.1]
When to purge a shadow journal file: after it's dejournaled
The output displayed from the ^SYS("shdwcli”) global has the following components:
• Shadow ID — the ID of a copier shadow is partially inherited from the parent shadow. The clu subnode of a copier contains the ID of the parent, and the sys subnode of the parent contains a list of the IDs of the copiers.
• PrimaryServerIP and Port — for a copier, these specify the system from which it gets journal files; for the dejournaler, the system from which it gets journal information (JRNINFO server).
The values are stored in the ip and port0 subnodes.
• R — has the value 1 if the shadow is running; from the stat subnode.
• S — has the value 1 if the shadow is requested to stop (due to latency, it is possible that both R and S have the value 1 if the shadow has yet to check for the stop request); from the stop subnode.
• Err — number of errors encountered. See details through ShowError^SHDWX, which displays the information from the err subnode.
• Redirection of Global Sets and Kills — referred to as database mapping in the System Management Portal; from the dbmap subnode of the cluster shadow.
• Redirection of Master Journal Files — discussed in the Using Caché Routines section; stored in the jrndir subnode of the cluster shadow. The value of the jrndir subnode is the number of journal directories that have been automatically redirected (in the preceding example output, the next new journal directory is redirected to a subdirectory [.4]). (jrndir,0) is the base shadow directory and everything else indicates a redirection of journal directories with the server journal directory being the key and the shadow journal directory being the value.
• Primary Server Cluster ID — used to prevent the shadow from following a node to a different cluster; from the DBServerClusterID subnode.
• Primary Server Candidates (for failover) — the list of current live members of the cluster. If one member dies, a shadow (either the dejournaler or a copier) that gets information from the member tries other members on the list until it succeeds. A new member is added to the list as soon as the shadow knows its presence; from the servers subnode.
• When to purge a shadow journal file — works in the same way as purging of local journal files.
The age threshold is set by the lifespan subnode of the cluster shadow. Unlike purging of local journal files, however, if the value of lifespan is 0, the shadow journal files are purged as soon as they have been dejournaled completely. The purged journal files are listed in the jrndel subnode of the copiers.
The chkpnt subnode stores a list of checkpoints. A checkpoint is a snapshot of the work queue of the dejournaler—the current progress of dejournaling. The value of the chkpnt subnode indicates which checkpoint to use when the dejournaler resumes. This is the checkpoint displayed by
ShowWhere^SHDWX. Updating the value of the chkpnt subnode after having completely updated the corresponding checkpoint, avoids having a partial checkpoint in the case of system failover in the middle of an update (in that case, dejournaler would use previous checkpoint).
The copiers keep the names of the copied (or being copied) journal files in the jrnfil subnode. This makes it possible to change the redirection of journal files by allowing the dejournaler to find the shadow journal files in the old directory while the copiers copy new journal files to the new location.
Once a shadow journal file is purged, it is moved from the jrnfil list to the jrndel list.
Here is a sample of the ^SYS("shdwcli") contents for the nodes for the cluster shadow, clutest, and two of its copier shadows:
^SYS("shdwcli","clutest")=0
^SYS("shdwcli","clutest","DBServerClusterID")=_$1$DKB400:[TEST.5X]CACHE.PIJ "at")=0
"chkpnt")=212
^SYS("shdwcli","clutest","chkpnt",1)=1,1012488866,-128
reading ans from |TCP|42009timed out,Remote server is not responding
^SYS("shdwcli","clutest","err",1,"begin")=20020519 14:09:09
"_$1$DRA2:[TEST.5X.JOURNAL]")=_$1$DKA0:[TEST.5X.SHADOW.1]
"_$1$DRA2:[TEST.5Y.JOURNAL]")=_$1$DKA0:[TEST.5X.SHADOW.2]
"_$1$DRA2:[TEST.5Z.JOURNAL]")=_$1$DKA0:[TEST.5X.SHADOW.3]
^SYS("shdwcli","clutest","jrntran")=0
"_$1$DKA0:[TEST.5X.SHADOW.1]20020131.002")=
8
Caché Clusters on Tru64 UNIX
Alpha Tru64 UNIX version 5 introduced cluster-mounted file systems and a UNIX distributed lock manager. Thus, two or more servers with their own memory, CPU, and I/O channels can simultaneously access data stored on a common set of file systems.
There are three methods available for running Caché on one of these clusters. The first method is to simply run your Caché instances on single servers as stand-alone installations. While this is the simplest case, it fails to utilize the performance and high availability advantages of the cluster. The second method is to utilize Tru64 UNIX Cluster Available Application (CAA) functionality. This is described in the System Failover Strategies chapter as a cold failover.
The third method, the topic for this chapter, is to utilize two or more of the servers in a Tru64 UNIX cluster as a unit in a warm failover or a hot failover configuration. With this version of Caché, you may run Caché across a Tru64 UNIX cluster where processes running on any member of the cluster have controlled simultaneous access to the same Caché database files. With this configuration you gain performance and high availability benefits. This functionality is the same as for Caché on OpenVMS clusters.
The following topics are discussed:
• Tru64 UNIX Caché Cluster Overview
• TruCluster File System Architecture
• Planning a Tru64 Caché Cluster Installation
• Tuning a Tru64 Caché Cluster Member