Using a Replica Server

When your client machine is set up to use a replica server, you can issue all AccuRev commands in the usual way. In general:

•	Configuration management commands that read data from the repository — such as files, diff, and cat — use the replica repository.

•

Configuration management commands that write data to the repository — such as keep, promote, and merge — use the master repository. After the master repository has been modified, the local replica repository is automatically brought up to date. For details, see Synchronizing a Replica Manually, which describes how you can bring the local replica repository up to date when you are not writing data to the repository.

•	All AccuWork issue management operations are handled by the master server. Thus, replication does not improve AccuWork performance.

The Update Command

The update operation works as follows when you execute it on a client that uses a replica server:

1.	An implicit replica sync command is performed, copying database transactions from the master repository to the replica repository. This brings the replica database completely up to date.

2.	A stat operation is performed on the replica server, to determine the state of the workspace stream and its backing stream.

3.	Data files representing new versions of elements are copied from the file storage area in the master repository to the file storage area in the replica repository.

4.	Data files are copied from the replica repository to your workspace tree. In addition to the files retrieved from the master repository in the preceding step, this can include files that have already been “downloaded” to the replica repository through other users’ commands.

5.	On both the replica server and the master server, the transaction level of the workspace is set to the most recent transaction (or to the transaction specified with update –t).

Command Interaction in a Replicated Environment

If a particular replica server is executing a mkreplica command, a request to perform a replica sync on that server might fail. Be careful to run mkreplica at a time when it is unlikely that any user or script is invoking replica sync.

If a replica sync command does fail for this reason, first make sure that no mkreplica command is executing, then invoke replica sync again.

Similarly, if a replica sync command is already in progress, in rare situations a client command sent to the same replica server might not complete correctly, causing an error message to be displayed. The change is made correctly on the master server in such situations. The user who issued the command can perform an update command to have the change reflected in the workspace.

Removing Storage Containers on a Replica Server

Use the replica archive command to remove unused container files from the depot’s storage directory on a replica server.

The replica archive command activates the server_preop_trig trigger with a replica_archive command. The command lists each element for which the storage container was removed. For example:

Removing storage for element /file1.txt (2/5)
Removing storage for element /file1.txt (2/6)

For more information on this command, see the replica command in the AccuRev CLI User’s Guide, or enter accurev help replica in the CLI.

Removing a Replica Server

Since the master repository is always complete and up-to-date, removing a replica server is very simple:

1.	Inform any users on the replica server of the change. Every user must log out and edit the acclient.cnf file (located in the AccuRev bin directory) to point to another server.

2.	On the replica server machine:

•	Stop the AccuRev Server and AccuRev Database Server.

•	Uninstall AccuRev by running the uninstall program.

•	Access the AccuRev installation directory and remove any remaining files.

Improving Replica Performance

The techniques described in this section can greatly improve the user experience with AccuRev replicas.

Performance of a Newly Created Replica

Use the following procedure to download version files to a replica when it is first created, instead of when the replica’s first user performs an Update.

Perform these steps on the master server:

1.	Stop the AccuRev Server and AccuRev Database Server.

2.	For each depot to be replicated, use a ZIP utility (or tar, or some other tool) to copy the data subdirectory of the depot’s slice. Example:

 

cd /opt/accurev/storage/depots
zip -r /tmp/oscar_data.zip oscar/data
zip -r /tmp/felix_data.zip felix/data

3.	Restart the AccuRev Server.

Perform these steps on the replica server:

4.	Replicate the depots with the command accurev mkreplica. Example:

accurev mkreplica -p oscar
accurev mkreplica -p felix

5.	Stop the AccuRev Server and AccuRev Database Server.

6.	For each replicated depot, move the slice’s data subdirectory aside. Example:

cd /var/applications/accurev/storage/depots
mv oscar/data  oscar/data.ORIG
mv felix/data  felix/data.ORIG

7.	For each replicated depot, recreate the slice’s data subdirectory, using the copy created in Step 2. Example:

unzip oscar_data.zip
unzip felix_data.zip

8.	Restart the AccuRev Server.

Performance of Heavily Used Replicas

In a distributed computing environment, many new versions might be created in a replica at Site A, while no one is working at Site B. The first person to update his workspace at Site B pays the penalty of waiting for all those new versions to be transferred from the master server to Site B.

To avoid this situation, create a “dummy” workspace at Site B for each heavily used stream, and create a script that updates all these workspaces. Then, set up a cron job (UNIX/Linux) or a Scheduled Task (Windows) to run the script on a regular basis. Ideally, the script would run at least once a day — before the start of Site B’s work day, but after the end of the work day of Site A (and any other sites). For example, this crontab line runs script update_replica_workspaces at 4:30AM every day:

30 4 * * * /usr/local/bin/update_replica_workspaces

Running the script at additional times during the work day can further improve replication performance from the users’ viewpoint — if there is sufficient file-transfer bandwidth.

Enabling Data Compression

AccuRev 5.5 supports data compression on connections between master and replica servers. Enabling data compression can improve performance on low-bandwidth networks, especially networks whose bandwidth is slower than 10Mbps.

To enable data compression, add the following line to the acserver.cnf file on each replica server:

COMPRESSION_ENABLED=TRUE

Note: If your installation makes use of hardware compression, enabling data compression on the AccuRev replica server might decrease performance.

Backing Up and Restoring Replica Servers

AccuRev recommends that you back up the replica servers in your environment on the same schedule you use for backing up your master. See Backing Up the Repository for more information.