Edge server metadata recovery

If you have a valid checkpoint and journals for the edge server, use the procedure at Database corruption, versioned files unaffected instead of the procedure below.

If you are using the Server Deployment Package (SDP), use the procedure at Edge Reseed Scenario in the documentation of Perforce P4 Server Deployment Package (for UNIX/Linux).

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 P4 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 filtered out 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 for edge server metadata recovery

These steps assume familiarity with the P4 Server (p4d) reference for checkpoints and restoring. If you want guidance, contact Perforce Support.

Stop the edge server.
Move the database db.*.rp files and the file called state from the edge server root directory to a safe directory.

Dump the local edge server tables by using the
p4d -r edgeroot -k table-list -jd edgedump
command, and copy those tables to a safe directory.

Copy the List of filtered out tables string for your server release from the Create and start the edge servers topic.

Append that table list string with the suffix
,db.view,db.label,db.revsx,db.revux

Do not skip this step or the edge server's local database will be incomplete.

For example, using lowercase k to select only the tables enclosed in the double-quoted string:

Copy

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.upgrades.rp,db.upgrades,db.scandir,db.scanctl,db.revstg,db.refcntadjust,db.have.pt" -jd edgedump

and append ,db.view,db.label,db.revsx,db.revux so that you have:

Copy

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.upgrades.rp,db.upgrades,db.scandir,db.scanctl,db.revstg,db.refcntadjust,db.have.pt,db.view,db.label,db.revsx,db.revux" -jd edgedump

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
Move the edge database (db.*) files to a safe directory in case they might be required later.
Copy the globaledge.dump checkpoint file from the commit server to the edge server.
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.

With p4d -r edgeroot -R edge-server -jr master.ckp.256, a generic edge server database is created.
Any filtering defined in a specific edge server spec is ignored.
This might result in the edge server containing more metadata than the server spec definition.
If db.view exists in the edge server's P4ROOT directory, (edgeroot in this example), rename db.view to db.view-from-commit.
Restore the edge-specific data:
p4d -r edgeroot -jr edgedump
Make a backup of the local edge server tables by using
p4d -r edgeroot -k table-list -jd recovered-edgedump
and copy the recovered-edgedump file to a safe directory:
1. Copy the List of filtered out tables string for your server release from the Create and start the edge servers topic.
2. Append that table list string with the suffix
  ,db.view,db.label,db.revsx,db.revux
Do not skip this step or the edge server's local database will be incomplete.

For example, using lowercase k to select only the tables enclosed in the double-quoted string:
Copy
```
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.upgrades.rp,db.upgrades,db.scandir,db.scanctl,db.revstg,db.refcntadjust,db.have.pt,db.view,db.label,db.revsx,db.revux" -jd recovered-edgedump
```
Copy those db.*.rp files you put in the safe directory during Step 2, and put them into the edge server's P4ROOT directory. This will overwrite any db.*.rp files that are already in the edge server's P4ROOT directory.
Start the edge server.

Allow the edge server to catch up with the commit server and check this with the
p4 pull -l -j
command issued against the edge server. The output might be similar to:


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

Enable access to edge server users.

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.

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.