From 2013.3 - 2018.2 to latest (multi-server environment)
The steps for upgrading P4 Server 2013.3 - 2018.2 to latest in a multi-server environment are not the same as those for upgrading other P4 Server versions or for a single-server environment.
When upgrading:
- A proxy or broker only needs to get the latest binary.
- You must run p4d -xu against all servers and replicas.
- You don't need to run p4d -xu against offline db.* files (a set of db.* files periodically brought current by replaying the journal files from the production server).
In P4 Server 2019.1 and later, the db.storage table replaces db.archmap to provide a link count for archive files on the server. This allows +Sn type files to be lazy copied, which saves disk space. The upgrade also improves the performance of p4 obliterate, especially on servers with significant integration history.
Prerequisites
- To upgrade P4 Server to a newer version, your P4 Server license file must be current.
- Time:
- Phase 1 of the upgrade requires that the servers be down for several minutes.
- Phase 2 of the upgrade runs in the background so users can work. This phase might take several hours. Performance might be slower while the db.storage table is being built and its contents are being replicated to the outer servers.
Environments with a db.rev table larger than 200 GB might take a couple of hours to complete.
- Smaller environments might only take several minutes.
- Available disk space should be at least equal to the size of the db.rev table. (The journal file can grow to the size of the new db.storage table. Typically, the journal is on a separate partition.)
- Ensure that journaling is enabled. Journal replication is how the new upgrades are copied to other servers.
- Be prepared to upgrade all the servers in a single upgrade session.
- You should take a checkpoint so that you can recover if something goes wrong during the upgrade. (See Checkpoint files.) It is best to take the checkpoint at a time when the end-users are not active.
Let the users know that all the servers will be down several minutes for maintenance, followed by several hours in which performance might be slower and the following commands are blocked:
Upgrade steps
In the following steps, replace:
- [P4ROOT] with the path to the P4ROOT directory.
- [P4JOURNAL] with the directory path and name of the journal file.
In the case of commit edge, the "innermost server" is the commit server, and the outer servers are edge servers. In the case of a standard server and replicas of that standard server, the "innermost server" is a standard server.
- The upgrade proceeds from the outermost server toward the innermost server.
- Restarting proceeds from innermost server towards the outermost server.
On the outermost server
- Shut down the server by running p4 admin stop
- Install the new version of the p4d binary on the system.
- As the OS account owner of the P4 Server, run p4d -r [P4ROOT] -J [P4JOURNAL] -xu
- Wait until the following sequence of messages completes. Expect a pause after the first message:
- Leave this server down.
2019.1: building db.storage from db.rev, db.revsh and db.revtx
[pause]
2019.1: Adding default namespace to Extension configurations
Additional upgrades will be applied from '-xu' at upstream server.
The upgrade steps for the new version are replicated outward from the innermost server.
On the servers between the outermost and innermost servers
-
Shut down by running p4 admin stop.
- Install the new version of the p4d binary on the system.
- As the OS account owner of the P4 Server, run p4d -r [P4ROOT] -J [P4JOURNAL] -xu
- Wait until the following sequence of messages completes. Expect a pause after the first message:
- Leave this server down.
2019.1: building db.storage from db.rev, db.revsh and db.revtx
[pause]
2019.1: Adding default namespace to Extension configurations
Additional upgrades will be applied from '-xu' at upstream server.
The upgrade steps for the new version are replicated outward from the innermost server.
On the innermost server
Phase 1
-
Shut down by running p4 admin stop.
- Install the new version of the p4d binary on the system.
- As the OS account owner of the P4 Server, run p4d -r [P4ROOT] -J [P4JOURNAL] -xu
- Wait until the following sequence of messages completes. Expect a pause after the first message:
-
As the OS account owner of the P4 Server, start the innermost server. This starts a background process to build the db.storage table, a new table in the P4 Server schema.
- As the OS account owner of the P4 Server, start the servers between the innermost server and the outermost server.
- As the OS account owner of the P4 Server, start the outermost server.
- Inform your users that they can resume work.
2019.1: building db.storage from db.rev, db.revsh and db.revtx
[pause]
2019.1: Adding default namespace to Extension configurations
Additional upgrades will be applied at server startup.
Phase 2
- To know when the background upgrade process is complete, run p4 storage -w on the innermost server.
- Wait for p4 storage -w to return the following message: "The storage upgrade process is complete".
- To monitor progress, in a separate command-line terminal, run the following command from time to time to verify that the time stamp or file size is increasing:
- ls -l db.storage for Linux
dir /ta /odfor Windows-
P4 Server 2002.2 and later: After you have determined that the time stamp or file size is no longer increasing, run the
p4 storage -U -q //...command to update the digests of your ktext file revisions. This might reduce performance for some time, so consider doing it overnight or at the weekend. (See File types in the P4 CLI Reference.) -
(Optional:) To verify the operation in the background, run the
p4 storage -vcommand.