Test the replica
Prerequisite
The steps on this page assume you have logged into the master server as the Helix Core user with the access level of super. See Permission levels and access rights in the p4 protect topic of Helix Core Command-Line (P4) Reference. That user can have any name, but for convenience the examples use super:
p4 -u super login
Test p4 pull
To confirm that the p4 pull commands (specified in
Replica1's startup.n configurations) are
running, issue the following command:
$ p4 -u super -p replica:1667 monitor show -a
The output should be similar to this:
2976020 B service 00:00:36 pull sleeping 1000 ms 2976021 B service 00:00:36 pull sleeping 1000 ms 2976022 B service 00:00:36 pull sleeping 1000 ms 2976041 R super 00:00:00 monitor show -a
Test file replication
Create a new file under your workspace view:
$ echo "hello world" > myfile
Mark the file for add:
$ p4 -u super -p master:1666 add myfile
And submit the file:
$ p4 -u super -p master:1666 submit -d "testing replication"
Wait a few seconds for the pull commands on the replica to run, then check the replica for the replicated file:
$ p4 -u super -p replica:1667 print //depot/myfile
//depot/myfile#1 - add change 1 (text)
hello world
If a file transfer is interrupted for any reason, and a versioned file is not present when requested by a user, the replica server silently retrieves the file from the master.
On-demand replicas and performance
Replica servers in -M readonly -D readonly mode will
retrieve versioned files from master servers even if started without a
p4 pull -u command to replicate versioned files to
the replica. Such servers act as "on-demand" replicas, as do servers
running in -M readonly -D ondemand mode or with their
lbr.replication configurable set to
ondemand.
Administrators: be aware that creating an on-demand replica of
this sort can still affect server performance or resource consumption,
for example, if a user enters a command such as p4 print
//..., which reads every file in the depot.
Verifying the replica
When you copied the versioned files from the master server to the
replica server, you relied on the operating system to transfer the files.
To determine whether data was corrupted in the process, run p4 verify on the replica server:
$ p4 -u super verify //...
Any errors that are present on the replica but not on the master indicate corruption of the data in transit or while being written to disk during the copy operation.
Run p4 verify on
a regular basis, and consider using the -t option once the initial seeding of the replica has been completed. It is important to verify file revisions both on the master and its replicas.
