Migration scenarios

This section provides instructions for several migration scenarios. If you do not find the material you need, request Support.

Note

If you want a single login to the master server to be valid across all replicas and edges, see Authenticating users.

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 might 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. Use a dump of the database of your central server, filtering out the appropriate tables. See the <LIST OF TABLES> string for your server release in the Create and start the Edge Servers topic.
```
                                    p4d -K <LIST OF TABLES> -jd my_filtered_checkpoint_file
                                
```
    Tip
    If you want to produce a filtered journal dump file, look for the -k and -K options in the Helix Core Server (p4d) Reference.
  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 <LIST OF TABLES>.
Start the replica, which 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 you might want to use those clients after the conversion from a build-server to an Edge Server. However:

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 involves 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:
1. Remove the tables you do not need:
  
  See the <LIST OF TABLES> string for your server release in the Create and start the Edge Servers topic, and issue the command:
```
rm <LIST OF TABLES>
```
2. Rename the have table:
```
$ mv db.have.rp  db.have
```
3. Rename the view table:
```
                            mv db.view.rp  db.view
                        
```
Start the server, which is now an Edge Server. All of its locally-bound clients can 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, request Support.