Testing the replica
Testing 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
18835 R service00:04:46 pull -i 1
18836 R service00:04:46 pull -u -i 1
18837 R service00:04:46 pull -u -i 1
18926 R super 00:00:00 monitor show -a
If you need to stop replication for any reason, use the p4
monitor terminate command:
$ p4 -u super -p replica:1667 monitor terminate 18837 process '18837' marked for termination
To restart replication, either restart the Helix Server process, or manually restart the replication command:
$ p4 -u super -p replica:1667 pull -u -i 1
If the p4 pull and/or p4 pull -u
processes are terminated, read-only commands will continue to work for
replica users as long as the replica server’s p4d is
running.
Testing file replication
Create a new file under your workspace view:
$ echo "hello world" > myfile
Mark the file for add:
$ p4 -p master:1666 add myfile
And submit the file:
$ p4 -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 -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.
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 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 original copy operation. (Run p4 verify on
a regular basis, because a failover server’s storage is just as
vulnerable to corruption as a production server.)
