Perforce Public Knowledge Base - Downtime during checkpoints and Alternatives
× PRODUCTS SOLUTIONS CUSTOMERS LEARN SUPPORT
Downloads Company Partners Careers Contact Free Trials
Menu Search
Perforce
Reset Search
 

 

Article

Downtime during checkpoints and Alternatives

« Go Back

Information

 
Problem

While taking a checkpoint, the Perforce Server is unusable and users can't log in. How do we stop this from happening? How can I detect when the downtime ends? Are there alternative backup methods?

Solution

The inability to use the Perforce Server during a checkpoint operation is expected behavior. The Perforce Server will lock down all database files to ensure that the metadata copied into the checkpoint file is consistent. Without this database table locking, you risk having only partially-completed processes (such as the submission of a changelist) recorded in the database and therefore in your checkpoint.

The checkpoint operation does not stop users from working on the files in their workspace. However, users will be unable to issue Perforce commands against the Perforce Servder during the checkpoint operation because processing commands would require database access. When the checkpoint process is complete the database becomes available, and users can resume working with the Perforce Server again.

Identifying Downtime

You can identify the amount of time a checkpoint takes by performing the checkpoint operation in a script that runs that 'date' or 'time' command (or similar) to identify how long it takes to complete.

Below are two examples of timing a checkpoint operation. The first method uses the UNIX 'time' utility to time the operation on the server (using p4d -jc); the second uses a script to call the client p4 admin checkpoint operation.

Example 1

$ time p4d -r. -jc Checkpointing to checkpoint.210...
MD5 (checkpoint.210) = 47A524C272961B4FE40905CEE71E9688
Rotating journal to journal.209...

real 0m1.682s
user 0m1.130s
sys 0m0.305s

Example 2

$ cat checkpoint.sh
echo \# starting checkpoint operation
date
p4 admin checkpoint
echo \# finished date $ ./checkpoint.sh
# starting checkpoint operation
Fri Jun 13 15:33:07 PDT 2014
Checkpointing to checkpoint.180...
MD5 (checkpoint.180) = 88AC74A8BFE5930AA50749270FD5F502
Rotating journal to journal.179...
# finished
Fri Jun 13 15:33:08 PDT 2014

In this examples above, checkpointing a 100MB database took just under 2 seconds. However, a checkpoint operation on a larger database can take hours. The time the checkpoint takes to complete is influenced by many hardware factors, including CPU, memory, and disk I/O, as well as size of the Perforce database files.

Reducing Downtime

To reduce the downtime required for checkpoints, you can consider an offline checkpoint operation, which is essentially taking a checkpoint on a backup or replica of your main Perforce Server. Offline checkpoints provide a good way to address server downtime during checkpoints for environment where high availability is essential. There is additional information on backup and recovery in the Perforce System Administrator's Guide.

Related Links

Feedback

 

Was this article helpful?


   

Feedback

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

Characters Remaining: 255