7. Replication of the AccuRev Repository : Using a Replica Server

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.
The Update Command
The update operation works as follows when you execute it on a client that uses a replica server:
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.
A stat operation is performed on the replica server, to determine the state of the workspace stream and its backing stream.
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:
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.
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:
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
Perform these steps on the replica server:
Replicate the depots with the command accurev mkreplica. Example:
accurev mkreplica -p oscar
accurev mkreplica -p felix
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
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
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:
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.

Micro Focus