Edge Server metadata recovery

Prerequisites

The procedure below for edge server metadata recovery applies if all of the following are true:

• You are running the 2022.1 version (or later) of the Helix Server.
  Otherwise, use the 2021.2 version of Edge Server metadata recovery.

• One or more database tables are corrupt on the edge server, and no checkpoint is available to recover those database tables

• None of the corrupted edge server tables belong to the <LIST OF TABLES> at Create and start the edge servers

• Archive files on the edge server are intact or have been restored from a backup. If restored from a backup, they might not be up to date with the recovered metadata.

Steps

1. Move the database tables, db.user.rp, and the file called state from the edge server root directory to a safe directory.

2. Stop the edge server.

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

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

   2. Append that string with the suffix
      ,db.view,db.label,db.revsx,db.revux
      
      For example:
      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.
      

4. Ensure you have a recent checkpoint of the commit server, or create a checkpoint on the commit server (see Checkpoint and journal options) that contains data specific to the edge server and takes account of any filters defined in the edge server spec:
   
   p4d -r commitroot -P edge-serverid -jd globaledge.dump

5. Move the edge database to a safe directory.

6. Copy the globaledge.dump checkpoint file from the commit server to the edge server.

7. Re-create the edge database from the checkpoint you created on the commit server.

   p4d -r edgeroot -jr globaledge.dump

   or

   If using a full checkpoint of the commit server:
   p4d -r edgeroot -R edge-server -jr master.ckp.256

   where 256 represents the commit server's most recent checkpoint number.

   Note

   With p4d -r edgeroot -R edge-server -jr master.ckp.256, any filtering defined in the edge server spec is ignored. This might result in the edge server containing more metadata than the server spec definition.

8. If db.view exists in the edge server's P4ROOT directory, (edgeroot in this example), rename db.view to db.view-from-commit

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

10. Move the db.*.rp files from the safe directory to the edge server's P4Root directory, overwriting those files if they already already exist.

11. Start the edge server.

12. 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: 2022/03/25 14:48:41.
    The replica server time is currently: 2022/03/25 14:48:50 +0000 GMT

13. Enable access to edge server users.

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

If a new checkpoint cannot be taken

If a new checkpoint cannot be taken of the commit server or read-only replica of the commit server (see Step 4 above), use the last good checkpoint. This could require one or more numbered journal files as well as the current journal file. For example, to restore numbered journals and a running journal where the last good checkpoint was master.ckp.254:

p4d -r edgeroot -R edge-server -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.