Requirements for replication systems

Replica servers must match the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. in the following:

• Release version - see Upgrade the server
• Release level - at the same level or later as the target server. A given feature only works if both the target server and the replica are at a release level that supports the feature.
• Unicode setting and encoding, such as UTF-8
• File system case-sensitivity.

• Permitted characters. For example:

  • macOS file names cannot contain a colon (:)
  • Windows NTFS excludes / ? < > \ : * | " and a full path is limited to 260 characters

• Time zone. Note that:

  • On Windows, the time zone setting is system-wide.
  • On UNIX, the time zone setting is controlled by the TZ environment variable at the time the replica server is started.

 Additional requirements:

• A current checkpoint and versioned files from the target server are required for the initial seeding of the replica server.
• Because p4 pull when replicating metadata does not read compressed journals,
  • The target server must not compress journals until the replica server has fetched all journal records from older journals.
  • Only one metadata-updating p4 pull thread can be active at one time.
• If you plan to use the Failover feature, a duplicate license file will be required for any replica server that takes over for the former target server. To learn more, see the Failover topic and fill out the form at Helix Core Duplicate Server Request.

• Decide how you want to define the behavior for the replication of versioned files Source files stored in the depot, including one or more revisions to each file. Also known as archive files, archives, and depot files. Versioned files typically use the naming convention 'filename,v' or '1.changelist.gz'.. To learn more, see the lbr.replication configurable.

Enabling SSL/TLS support

To encrypt the connection between a replica server and its end users, the replica must have its own valid private key and certificate pair in the directory specified by its P4SSLDIR environment variable. Certificate and key generation and management for replica servers works the same as it does for the target server. To learn more, see Enable SSL support. The users' P4 Server applications must be configured to trust the fingerprint of the replica server.

To encrypt the connection between a replica server and its target server, the replica must be configured so as to trust the fingerprint of the target server. That is, the user that runs the replica p4d must create a P4TRUST file (using p4 trust) that recognizes the fingerprint of the target P4 Server. This user is typically typically a service user. To learn more, see Service users.

The P4TRUST environment variable specifies the path to the SSL/TLS trust file. You must set this environment variable if:

• A replica needs to connect to an SSL/TLS-enabled target server.
• An edge server needs to connect to an SSL/TLS-enabled commit server.