Helix Core Server Administrator Guide: Multi-Site Deployment (2019.2)

Migration scenarios

This section provides instructions for several migration scenarios. If you do not find the material you need, email [email protected].

Configuring a master server as a commit server

Scenario: You have a master server. You want to convert your master to a commit server, allowing it to work with edge servers as well as to continue to support clients.

Choose a ServerID for your master server, if it does not have one already, and use p4 serverid to save it.
Define a server spec for your master server or edit the existing one if it already has one, and set Services: commit-server.

Converting a forwarding replica to an edge server

Scenario: You currently have a master server and a forwarding replica. You want to convert your master server to a commit server and convert your forwarding replica to an edge server.

Depending on how your current master server and forwarding replica are set up, you may not have to do all of these steps.

Have all the users of the forwarding replica either submit, shelve, or revert all of their current work, and have them delete their current workspaces.
Stop your forwarding replica.
Choose a ServerID for your master server, if it does not have one already, and use p4 serverid to save it.
Define a server spec for your master server, or edit the existing one if it already has one, and set Services: commit-server.
Use p4 server to update the server spec for your forwarding replica, and set Services: edge-server.
Update the replica server with your central server data by doing one of the following:
- Use a checkpoint:
  1. Take a checkpoint of your central server, filtering out the db.have, db.working, db.resolve, db.locks, db.revsh, db.workingx, db.resolvex tables.
```
$ p4d -K "db.have,db.working,db.resolve,db.locks,db.revsh,db.workingx,db.resolvex"
      -jd my_filtered_checkpoint_file
```
    Tip
    If you want to produce a filtered journal dump file, go to Helix Core Server Administrator Guide: Fundamentals, and look in the "Helix Core server Reference" for the -k and -K options.
  2. Restore that checkpoint onto your replica.
  3. It is good practice, but it is not required that you remove the replica’s state file.
- Use replication:
  1. Start your replica on a separate port (so local users don’t try to use it yet).
  2. Wait for it to pull the updates from the master.
  3. Stop the replica and remove the db.have, db.working, db.resolve, db.locks, db.revsh, db.workingx, db.resolvex tables.
Start the replica; it is now an edge server.
Have the users of the old forwarding replica start to use the new edge server:
- Create their new client workspaces and sync them.

You are now up and running with your new edge server.

Converting a build server to an edge server

Scenario: You currently have a master server and a build server. You want to convert your master server to a commit server and convert your build server to an edge server.

Build servers have locally-bound clients already, and it seems very attractive to be able to continue to use those clients after the conversion from a build-server to an edge server. There is one small detail:

On a build server, locally-bound clients store their have and view data in db.have.rp and db.view.rp.
On an edge server, locally-bound clients store their have and view data in db.have and db.view.

Therefore the process for converting a build server to an edge server can be the following :

Define a ServerID and server spec for the master, setting Services: commit-server.
Edit the server spec for the build-server and change Services: build-server to Services: edge-server.

Shut down the build-server and do the following:

$ rm db.have db.view db.locks db.working db.resolve db.revsh db.workingx db.resolvex
$ mv db.have.rp db.have
$ mv db.view.rp db.view

Start the server; it is now an edge server and all of its locally-bound clients can continue to be used.

Note

Step 3 above discards the db.view table, but there are multiple possibilities:

Retain db.view, Discard db.view.rp.
This means the edge server will discard all pre-existing build clients and need to create them in the edge server.
Retain db.view.rp, Discard db.view.
This means the edge server will have access to pre-existing build clients, but the other clients that were previously accessible in the build server (or build farm) become inaccessible.
Retain both db.view and db.view.rp.
If you want to maintain the same access of all available clients, including the build clients, please contact Technical Support.

Migrating a workspace from a commit server or remote edge server to the local edge server

Scenario: You have a workspace on a commit or remote edge server that you want to move to the local edge server.

Current work may be unsubmitted and/or shelved.
Execute the following command against the local edge server, where the workspace is being migrated to. protocol:host:port refers to the commit or remote edge server the workspace is being migrated from.
```
$ p4 reload -c workspace -p protocol:host:port
```

Your search for returned result(s).