Changing_Commit_ServerID.html #1

<h1>Changing the Commit Server ServerID - What to Expect</h1>

<p>This document describes the impact and considerations involved in changing the ServerID of a commit server in a P4 Server topology.</p>

<p>Changing the commit ServerID is generally motiviated by being in alignment with modern SDP conventions.  When done correctly, there is no impact on users other than a brief service restart.</p>

<h2>Relationship to auth.id</h2>

<p>The <code>auth.id</code> setting and the ServerID are related by convention, but they are technically independent.</p>

<p>Changing the commit ServerID is optional and is typically done to align with SDP naming conventions or enterprise-wide naming standards.</p>

<p>Changing <code>auth.id</code> is sufficient to resolve ticket collisions and inconsistent authentication behavior. See: <a href="Changing_auth.id.md">Changing auth.id</a> for more information.</p>

<h2>What the ServerID of the commit server represents</h2>

<p>The ServerID uniquely identifies a server within a P4 Server topology.</p>

<p>For a commit server, the ServerID is a core identity element that is referenced by:</p>

<ul>
<li>Replica and standby server specifications</li>
<li>Replication configuration and state</li>
<li>Service users and automation associated with the commit server</li>
</ul>

<p>Replica and standby servers identify their upstream server by ServerID, not by hostname or DNS name. Because of this, the commit ServerID is an important element of the replication topology.</p>

<h2>Impact of changing the commit ServerID</h2>

<p>Changing the commit ServerID, done right, has no impact on users except for a brief outage require for a service restart, requiring only seconds.</p>

<p>Planning considerations:</p>

<ul>
<li>The change of the <code>server.id</code> file in P4ROOT on the commit server must be performed with the p4d process stopped.</li>
<li>The commit server must be restarted for the new ServerID to take effect.</li>
<li>Any configurables associated with old ServerID of the commit server, such as <code>startup.N</code> settings for LDAP integration, must be duplicated to the chosen new ServerID.</li>
<li>All replicas and standby servers that reference the commit ServerID in the <code>RepflicatingFrom:</code> field of their server specs must be updated.</li>
<li>Replication will be briefly interrupted while servers are restarted and reconnect.</li>
<li>The duplicated configurables can have their corresponding configurables for the original ServerID removed once the services are back up.</li>
</ul>

<p>When the above are accounted for, this change has no impact on users.</p>

<h2>Required follow-on changes</h2>

<p>Changing the commit ServerID is not a single isolated action. The following follow-on steps are required.</p>

<h3>Update replica and standby server specifications</h3>

<p>For each replica or standby server that replicates from the commit server:</p>

<ul>
<li>Edit the server specification using <code>p4 server &lt;ServerID&gt;</code>.</li>
<li>Update the <code>ReplicatingFrom:</code> field to reference the new commit ServerID.</li>
</ul>

<h3>Restart replica and standby servers</h3>

<p>After updating the server specifications:</p>

<ul>
<li>Restart the p4d process on each replica and standby server.</li>
</ul>

<p>A restart is required for the replica to pick up the updated ServerID and ReplicatingFrom relationship and to resume replication cleanly.</p>

<h2>Operational considerations</h2>

<ul>
<li>Schedule a short maintenance window that includes the commit server and all replicas.</li>
<li>Expect a brief interruption to replication during the change.</li>
<li>Verify replication status after all servers have restarted.</li>
<li>Ensure monitoring or health checks confirm that replicas are connected to the new commit ServerID.</li>
</ul>

<h2>Related Information</h2>

<p>See: <a href="Changing_auth.id.md">Changing auth.id</a> for more information on changing <code>auth.id</code>.</p>