Perforce Public Knowledge Base - Upgrading to 2013.3 and beyond
Reset Search
 

 

Article

Upgrading to 2013.3 and beyond

« Go Back

Information

 
Problem

How do I upgrade from a 2013.2 or prior release of the Perforce Server to 2013.3 and later versions ?

Solution

The 2013.3 release of the Perforce Server contains major changes to the Perforce database implementation.
Because the database format has changed the historical upgrade method of dropping in a new P4D binary and running  'p4d -r root -J journal -xu' to upgrade the existing database can not be employed.
To upgrade from a release prior to 2013.3 to 2013.3 and beyond you must create a checkpoint with your previous version of the server and use this checkpoint to recreate the database with the 2013.3 or later version of P4D.

Upgrade a Unix server

  1. Stop the Perforce service:

    p4 admin stop
  2. Make a checkpoint and back up your old installation. (see “Backup procedures” in the System Administrator's Guide for how to do this).

  3. If a file called tiny.db exists in your old server root, you must back it up separately by running the following command with the old p4d:

    p4d -r . -xf 857 > tiny.ckp
  4. Remove the old db.* files, or preferably, move them to a safe location in the event that the upgrade fails.

    mv <Perforce root>/db.* /tmp

    There must be no db.* files in the P4ROOT directory when you rebuild a database from a checkpoint. Although the old db.* files will not be used again, it's good practice not to delete them until you're certain your upgrade was successful.  Optionally, move the log and journal, and *.lbr files, and move the server.locks directory if any of these files exist.

  5. Replace the old (2013.2 or earlier) p4d executable with the new (2013.3 or later) p4d executable.

    Note: Windows servers should use the Windows installer. The service will fail to start after the installation process completes; This is expected.

  6. Use the upgraded p4d to replay the checkpoint and rebuild the new database tables.
    Note that you will be warned that you are replaying an older checkpoint.

    p4d -r <Perforce root> -jr checkpoint_file
  7. If your site uses localized server messages from a message file obtained through Perforce technical support, retrieve the original message.txt file and re-create db.message in the new database format by running the following command with the new p4d:

    p4d -r <Perforce root> -jr /fullpath/message.txt

    See “Localizing server error messages” in the System Administrator's Guide for more information.

  8. If you created a tiny.ckp file as part of your backup process, restore tiny.db by running the following command with the new p4d:

    p4d -xf 857 tiny.ckp
  9. Upgrade any tables that might require it:

    p4d -r <Perforce root> -J pathto/<JournalFile> -xu
  1. Restart the Perforce service, run sanity checks, and resume operations.

Upgrade a Windows server

  1. Stop the Perforce service:

    p4 admin stop
    

    Or stop the Perforce service.

  2. Make a checkpoint and back up your old installation. (see “Backup procedures” in the System Administrator's Guide for how to do this).
    Open a command prompt as "Run as administrator", then run

    cd Perforce root
    p4d.exe -r . -jc

  3. If a file called tiny.db exists in your old server root, you must back it up separately by running the following command with the old p4d:

    p4d -r . -xf 857 > tiny.ckp
    
  1. Remove the old db.* files, or preferably, move them to a safe location in the event that the upgrade fails.
    Optionally, move the log and journal, and *.lbr files, and move the server.locks directory if any of these files exist.

    mkdir backup
    move db.* backup
    move log backup
    move journal backup
    move *.lbr backup
    move server.locks backup
    

    There must be no db.* files in the P4ROOT directory when you rebuild a database from a checkpoint. Although the old db.* files will not be used again, it's good practice not to delete them until you're certain your upgrade was successful.

  2. Replace the old (2013.2 or earlier) p4d executable with the new (2013.3 or later) p4d executable.

    First rename the current p4d.exe and p4s.exe
    For example

    rename p4d.exe p4d.20122.exe
    rename p4s.exe p4s.20122.exe
    

    Retrieve the desired p4d.exe executable from our ftp.perforce.com website.  For example, run from a browser

    ftp://ftp.perforce.com/perforce/r14.2/bin.ntx64/p4d.exe

    where r14.2 is an abbreviation for Perforce 2014.2 and bin.ntx64 retrieves the 64-bit binary.   Replace the current p4d.exe and make a copy of p4d.exe as p4s.exe

    cd Perforce root
    copy pathto\p4d.exe
    copy p4d.exe p4s.exe
  3. Use the upgraded p4d to replay the checkpoint and rebuild the new database tables.
    Note that you will be warned that you are replaying an older checkpoint.
    For example

    cd Perforce root
    E:\Program Files\Perforce\Server>p4d -r . -jr checkpoint.1579
    Perforce db files in '.' will be created if missing...
    Recovering from checkpoint.1579...
    Perforce server info:
            Server version 38 is replaying a version 33 journal/checkpoint.
    
  4. If your site uses localized server messages from a message file obtained through Perforce technical support, retrieve the original message.txt file and re-create db.message in the new database format by running the following command with the new p4d:

    p4d -r . -jr /fullpath/message.txt

    See “Localizing server error messages” in the System Administrator's Guide for more information.

  5. If you created a tiny.ckp file as part of your backup process, restore tiny.db by running the following command with the new p4d:

    p4d -r . -xf 857 tiny.ckp
  6. Upgrade any tables that might require it:

    cd Perforce root
    p4d -r . -J pathto\journal -xu
    
    
  7. Restart the Perforce service, run sanity checks, and resume operations.


Replica server upgrades

Normally replica servers should be upgraded prior to the master server; however in this particular instance it is best to upgrade the master and then rebuild the replica by reseeding it from the checkpoint that was used to upgrade the master.  See How to reseed a replica server.
Note that the replica will be unavailable for the duration of the master/replica upgrade.

Note: when upgrading a replica to 2013.3 or later from 2013.2 or earlier, you must delete the rdb.lbr file before restarting the replica server. It is recommended to wait for all archive transfers to end before stopping the replica and deleting the rdb.lbr file.

Upgrading Replicas and P4AUTH Servers 2016.1 and beyond with no license in P4ROOT

With the 2016.1 Helix Versioning Engine, the number of free users allowed was changed to 5 from 20.  To prevent accidentally upgrading the Server a check is done for the current number of users.  If this is above 5, the upgrade fails with the following error:

Perforce server error:
Warning! You have exceeded the usage limits of Perforce Helix. Version 16.1 allows up to five users without commercial licenses. You may continue your current usage with previous versions of our software.

Try deleting old users with 'user -d'.
License count: 200 users used of 5 licensed.

For additional licenses, contact Perforce Sales at sales@perforce.com.

Replicas or Servers using P4AUTH where a license is not required, may run into this above issue.  To upgrade a Replica, you will need to include a -t flag as part of the upgrade and -a for P4AUTH servers.  

For Replica Server: 
 
    p4d -r <Perforce root> -J pathto/<JournalFile> -t <Master Server IP:port> -xu

    
For Servers that use P4Auth:
    p4d -r <Perforce root> -J pathto/<JournalFile> -a <P4AUTH Server IP:port> -xu
   

The "-t" or "-a" flag will check that the Master Server or P4AUTH Server has a valid license allowing you to upgrade.
Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255