We do set journalPrefix explicitly for each instance but rely on the SDP to set P4ROOT and P4JOURNAL at startup time based on the initial configuration. I think we're safe there.

One final argument against this is that in the multisite deployment manual, it includes db.config in the 'level 1' checks for the integrity structured log. While it doesn't explicitly state it, it heavily insinuates that level 1 db files are not expected to be different between replicas:

Level 1 corresponds to the most important system and revision tables.
Level 2 includes all of level 1 as well as certain metadata that is not expected to differ between replicas.
...

Running 'p4d -cset' prior to startup of a replica guarantees in some cases that db.config checksum will fail 100% of the time, that is, the case where the SDP is used for one of its main purposes (or at least where it's most useful), that is, running more than one Perforce replica instance on a single host.

Bottom line, I don't feel like startup scripts should be injecting data into my databases, especially when that data guarantees failure of standard integrity checks.

In the case where you have multiple instances on one physical server, this will sort of act as a fallback if P4JOURNAL is not set for an instance (I guess?), but the value will change each time any instance is restarted.

Where it really starts to come into play is when you have a replica of an instance that is not running on the same instance number. The seven instances we have on our backup replicator correspond to various other servers (commit plus all edges) which are always on instance 1.

On the replicator, then, if the edge it's replicating corresponds to instance 6, then the any:P4JOURNAL setting will refer to instance 1 since it got that from the downstream server. At least until that instance is restarted. In any case, it's an opportunity for data on a downstream and upstream replica to diverge.

Overall my argument is that even though the data (and divergence) is likely innocuous, it's sorta creepy that the startup script would use something like '-cset' to directly alter the db, especially with something like P4JOURNAL which isn't really a global variable, it has to be different/explicit for each instance on a multi-instance server host, and in my opinion should at least include the server ID in the default, and not get put into the 'any' heading. (that would still lead to divergence, though, but at least the any:P4JOURNAL setting wouldn't incorrectly display an instance 1 path when you're running an instance >1.)

I'm also suspecting that this is why some of my newer server instances are reporting checksum mismatches in db.config, but I'm still digging into that one. A common troubleshooting technique for that is running 'p4 configure show allservers' on two replicas and diffing the output, which comes out with differences about half the time, depending on when the last restart of each host was.

I would agree with Robert's comment above, in that this is certainly 'unexpected' (that a startup script directly inserts data into my database.) I feel like the correct answer for the customer writing their own init scripts should have been "Set P4JOURNAL, dude..."

Hello!

I realize this is a crazy old review, but we recently started using a newer SDP. Our previous SDP predated this change.

Anyhoo, we run a backup server with multiple instances on it (1 through 6.) Since this change doesn't take into account the specific server.id, it creates an "any#P4JOURNAL" entry pointing at whatever instance was just started. Which isn't correct. But, it doesn't really get in the way, except aesthetically (I think.)

any: P4JOURNAL = /p4/n/logs/journal

... where 'n' is whatever instance I just started.

I think the $SERVERID needs to be incorporated in there:

$P4DBIN -r $P4ROOT "-cset $SDP_INSTANCE#P4JOURNAL=$P4JOURNAL"

Thanks!