The reason for updating the secondary nodes first and the primary node last is as follows. The cluster cannot function as a cluster without the primary node, as it is the central node. The update process starts with stopping all server instances. During the update process, each instance will start the CompleteFTP Service once updated. By updating and starting the primary node last, we ensure that all nodes are running the same version when the cluster resumes operation. This approach guarantees version consistency across the cluster, preventing any potential issues from version mismatches.
If the primary were updated first, then it would attempt to communicate with secondary nodes that are either stopped or (if left running by mistake) are of an older version. Theoretically, this version mismatch could lead to synchronization issues, configuration errors, or other unexpected behavior. By ensuring that the secondary nodes are updated first, we guarantee that when the primary node is finally brought online, it can immediately interact with all secondaries without any version conflicts, ensuring smooth and reliable cluster operation.
In fact, the system is designed to cope with version mismatches, which is why I wrote earlier that it shouldn’t matter in reality. Therefore the advice is more of a safeguard in case there’s an unknown flaw.
