Warnings, notes, and limitations

The following warnings, notes, and limitations apply to all configurations unless otherwise noted.

  • On master servers, do not reconfigure these replica settings while the replica is running:

    • P4TARGET
    • dm.domain.accessupdate
    • dm.user.accessupdate
  • Be careful not to inadvertently write to the replica’s database. This might happen by using an -r option without specifying the full path (and mistakingly specifying the current path), by removing db files in P4ROOT, and so on. For example, when using the p4d -r . -jc command, make sure you are not currently in the root directory of the replica or standby in which p4 journalcopy is writing journal files.

  • Large numbers of Perforce password (P4PASSWD) invalid or unset errors in the replica log indicate that the service user has not been logged in or that the P4TICKETS file is not writable.

    In the case of a read-only directory or P4TICKETS file, p4 login appears to succeed, but p4 login -s generates the "invalid or unset" error. Ensure that the P4TICKETS file exists and is writable by the replica server.

  • Client workspaces on the master and replica servers cannot overlap. Users must be certain that their P4PORT, P4CLIENT, and other settings are configured to ensure that files from the replica server are not synced to client workspaces used with the master server, and vice versa.

  • Replica servers maintain a separate table of users for each replica; by default, the p4 users command shows only users who have used that particular replica server. (To see the master server’s list of users, use p4 users -c).

    The advantage of having a separate user table (stored on the replica in db.user.rp) is that after having logged in for the first time, users can continue to use the replica without having to repeatedly contact the master server.

  • All server IDs must be unique. Manually-assigned names might be easy to remember, but in very large environments, there might be more servers than is practical to administer or remember. Use the command p4 server -g to create a new server specification with a numeric Server ID. Such a Server ID is guaranteed to be unique.

    Whether manually-named or automatically-generated, it is the responsibility of the system administrator to ensure that the server ID associated with a server’s p4 server form corresponds exactly with the server.id file created (and/or read) by the p4 serverid command.

  • Users of P4V and forwarding replicas are urged to upgrade to P4V 2012.1 or higher. Helix Core Server applications older than 2012.1 that attempt to use a forwarding replica can, under certain circumstances, require the user to log in twice to obtain two tickets: one for the first read (from the forwarding replica), and a separate ticket for the first write attempt (forwarded to the master) requires a separate ticket. This confusing behavior is resolved if P4V 2012.1 or higher is used.
  • Although replicas can be chained together as of Release 2013.1, (that is, a replica’s P4TARGET can be another replica, as well as from a central server), it is the administrator’s responsibility to ensure that no loops are inadvertently created in this process. Certain multi-level replication scenarios are permissible, but pointless; for example, a forwarding replica of a read-only replica offers no advantage because the read-only replica will merely reject all writes forwarded to it. If you are considering a multi-level replica installation, contact Perforce Support for guidance.

  • The rpl.compress configurable controls whether compression is used on the master-replica connection(s). This configurable defaults to 0. Enabling compression can provide notable performance improvements, particularly when the master and replica servers are separated by significant geographic distances.

    Enable compression with: p4 configure set fwd-replica#rpl.compress=1