Edge Server metadata recovery

The scenario for this procedure is that an edge server needs to be re-created and the metadata local to the edge server is preserved. This scenario assumes that the archive files on the edge server are intact or have been restored from a backup. If the archive files have been restored from a backup, they might or might not be up to date with the recovered metadata.

1. Move the database table, db.user.rp, from the server root directory to a safe place because it maintains details about the users logged in to the edge server.

2. Stop the edge server.

3. Dump the local edge server tables and copy them to a safe place.

4. Copy the <LIST OF TABLES> string for your server release from the Create and start the edge servers topic.

5. Append that string with the suffix
   ,db.view,db.label,db.revsx,db.revux.
   For example, a 2020.2 version of the command would be:
   p4d -r edgeroot -k db.have,db.working,db.locks,db.resolve,db.revsh,db.workingx,db.resolvex,db.stash,db.haveg,db.workingg,db.locksg,db.resolveg,db.storagesh,db.storagesx,db.view,db.label,db.revsx,db.revux -jd edgedump
   with a lowercase letter "k" to select only those tables.
   

6. Create a checkpoint of the commit server (see Checkpointing options), and make a note of the journal number so you have a specific point in time to use for the edge server:
   p4d -r commitroot -jc [prefix]

7. Move the edge database to a safe place.

8. Copy the checkpoint from the commit server to the edge server.

9. Re-create the edge database from the most recent checkpoint on the commit server.

   1. Copy the <LIST OF TABLES> string for your server release from the Create and start the edge servers topic. (The following step, 9.b., uses this list to exclude restoring those tables from a commit server checkpoint.)

   2. Append that string with ,db.view,db.label,db.revsx,db.revux. For example, a 2020.2 version of the command would be:
      p4d -r edgeroot -K db.have,db.working,db.locks,db.resolve,db.revsh,db.workingx,db.resolvex,db.stash,db.haveg,db.workingg,db.locksg,db.resolveg,db.storagesh,db.storagesx,db.view,db.label,db.revsx,db.revux -jr master.ckp.256
      where:

      • -K excludes those tables

      • 256, in this example, represents the commit server's most recent checkpoint number
        

10. Restore the edge specific data:
    p4d -r edgeroot -jr edgedump

11. Set the edge server's statefile to the correct journal number. For example:
    echo 256 > state

    Note: The offset into the journal is 0 so only the journal number is required.

12. Start the edge server.

13. Allow the edge server to catch up with the commit server and check this with the following command issued against the edge server:
    

    p4 pull -l -j
    Current replica journal state is: Journal 256, Sequence 1251.
    Current master journal state is: Journal 256, Sequence 1251.
    The statefile was last modified at: 2015/03/25 14:48:41.
    The replica server time is currently: 2015/03/25 14:48:50 +0000 GMT

14. Enable access to edge server users.

15. Check that archive files are up to date on the edge server:
    p4 verify -q -t //...

If a new checkpoint cannot be taken

Regarding Step 11 above ("Set the edge server's statefile to the correct journal number"), if a new checkpoint cannot be taken of the commit server (or read-only replica of the commit server), use the last good checkpoint. This could require one or more numbered journal files as well as the current journal file. Filter the re-play of the remaining journal files using the same -K flag value and tables.

For example, to restore numbered journals and a running journal for a 2020.2 where the last good checkpoint was master.ckp.254:

p4d -r edgeroot -K db.have,db.working,db.locks,db.resolve,db.revsh,db.workingx,db.resolvex,db.stash,db.haveg,db.workingg,db.locksg,db.resolveg,db.storagesh,db.storagesx,db.view,db.label,db.revsx,db.revux -jr master.ckp.254 journal.254 journal.255 journal

Failing to filter the journals correctly might cause consistency issues with workspaces, failed operations, or data loss.