Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.2

# Test the replica

## Prerequisite

The steps on this page assume you have logged into the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. named london as the P4 user with the access level of `super`. See Permission levels and access rights in the `p4 protect` topic of P4 CLI 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 london:1666 add myfile

And submit the file:

    p4 -u super -p london: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

The output might be:

    //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 target server.

## On-demand replicas and performance

Replica servers in `-M readonly -D readonly` mode will retrieve versioned files from target 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 target 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 target server 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 target server and its replicas.

## Next step

Use the read-only replica

Your search for returned results