The journalPrefix server configurable is used to configure a Helix server to automatically use a prefix when checkpoint or journal rotation commands are run. For example, checkpoint or journal rotation commands that specify a prefix /logs/p4/1/commit on the command line:
p4 admin checkpoint /logs/p4/1/commit
p4d -r /p4/1/root -J /logs/p4/1/journal -jc /logs/p4/1/commit
p4 admin journal /logs/p4/1/commit
p4d -r /p4/1/root -J /logs/p4/1/journal -jj /logs/p4/1/commit
produce checkpoint and rotated journal files based on the directory path and prefix name used:
where N is a sequence number. When journalPrefix is not set and no prefix is specified on the command line to checkpoint or journal rotation commands, default behavior produces checkpoint and rotated journal files in P4ROOT using the default naming convention:
When journalPrefix is set, the configured prefix is automatically used as a prefix argument to checkpoint or journal rotations command even if prefix is omitted from the command line. Any prefix passed on the command line overrides the journalPrefix setting. Note, journalPrefix only applies to checkpoints and rotated journals; it doesn't have any impact on the current active journal.
Configuring journalPrefix in Distributed Environments
Setting journalPrefix is a recommended best practice for a number of reasons:
- Facilitates a consistent journal rotation scheme; journalPrefix used when prefix omitted from command line
- Enables edge/replica servers to specify an alternate directory structure and naming convention for checkpoints and rotated journals
- When set on a commit/master server allows edge/replica servers to easily locate rotated commit/master journals
To effectively set journalPrefix in distributed environments, all servers should be set up with unique serverID values so server configuration variables can be set for each server:
p4 configure set server_id#variable=value
p4 configure unset server_id#variable
The p4 server command is used to create a server specification:
p4 server server_id
defining the details and services for that server, and p4 serverid or p4d -xD to set the unique serverID of a particular server:
p4 serverid server_id
p4d -r /p4/1/root -xD server_id
The p4 serverid or p4d -xD command creates a small text file named server.id in the server's P4ROOT directory. The server.id file must be backed up as part of normal backup procedures. If one of your servers suffers a catastrophic data loss, the restored server will require the server.id file be present (or be re-created) in order to correctly configure itself upon restart.
Before configuring journalPrefix, ensure the commit/master and edge/replica are referring to the same journal number using p4 pull -lj:
p4 pull -lj
Current replica journal state is: Journal 40, Sequence 14525.
Current master journal state is: Journal 40, Sequence 35625.
If the edge/replica is slightly behind the master and referencing a journal that is not the current running journal, setting journalPrefix on the commit/master will stop replication; this is due to the newly configured commit/master journal location being used by the edge/replica to locate the rotated journal.
For an example configuration of a commit server, an edge server, and a forwarding replica, journalPrefix might be set as follows:
p4 configure set commit#journalPrefix=/logs/p4/1/commit
p4 configure set edge#journalPrefix=/logs/edge_ckps/edge
p4 configure set fRep#journalPrefix=/logs/backup/fRep
which results in checkpoints and rotated journals as follows on the different servers:
Note, the journalPrefix configurations take effect dynamically (no server restart required) and start being used immediately.