Here’s a super-simple description of how Perforce replication works:
You replicate from a master p4 instance to one or more replica instances. Each replica instance is just a p4d process running a few “p4 pull” commands pointed at the master via some configs. Those configs are set on the master by saying “replica instances named ‘Replica1’ should run with these configs”. You can have several replica instances on several different hosts all using the same perforce user. They alll just needed to have replayed a checkpoint file and synced over all the versioned files from the master, and they all just needed to be started with a command line arg that said it is named “Replica1” (or whatever name you set up with configs on the master).
Some notes:
Perforce users used for replication need to have ‘super’ permissions (set in p4 protect on the master). They also need to have their ticket timeouts set to ‘unlimited’ or to something super-long, so you don’t have to log in with the user to renew the ticket.
You can do *something* to make a replica behave like a read-only replica that auto-forwards any write operations to the master and waits to respond to the client until after those changes have replicated through to it.
I *believe* you could replay a checkpoint and copy an incomplete set of the versioned files to the replica and things would still work; you would then run ‘p4 verify -t’ on the replica to kick off a giant comparison of every file and have the replica pull down replacement files from the master when it detected an inconsistency or in the case of missing files. So, if I understand it correctly, you could technically just set up a replica with only a checkpoint from the master, and then if you ran ‘p4 verify -t’ the replica would eventually sync up.