Server Handshaking for Stable Software Upgrades
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
During a software upgrade, the incompatibility between a master node and a slave node can cause the slave node to become unstable and crash, leading to data loss as it attempts to access the master database.
Innovation Solution
Implementing a handshaking methodology and a redundant data channel between servers, where the slave node is denied access to the master database during the upgrade, and data is queued and transferred post-upgrade, ensuring compatibility and preventing crashes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the slave node is allowed to access the master database during software upgrade, then data synchronization is maintained, but the slave node becomes unstable and crashes due to version incompatibility
Solution Approach 1:
The system segments the data access path by introducing a handshaking mechanism that separates compatibility verification from data access. The slave node is divided into components that independently handle version checking and data operations, preventing direct access to incompatible database structures during upgrade transitions.
Solution Approach 2:
The handshaking mechanism performs preliminary version compatibility checks before allowing data access. The master node announces its version status in advance, and the slave node verifies compatibility beforehand, preventing crashes by blocking access to incompatible database structures before the upgrade completes.
2Reliability
If the slave node is denied access to the master database during upgrade, then version incompatibility crashes are prevented, but data synchronization is lost
Solution Approach 1:
The handshaking mechanism acts as an intermediary between the slave node and master database. It mediates access requests by verifying version compatibility, allowing data flow when compatible and blocking it when incompatible, thus maintaining synchronization only under safe conditions.
Solution Approach 2:
The system changes the access parameter (compatibility status) dynamically based on the master node's upgrade state. When the master node announces an incompatible version, the access parameter shifts from permitted to blocked, automatically restoring when compatibility is re-established.
3Reliability
If a manual upgrade process is implemented, then version compatibility can be controlled, but the upgrade process becomes time-consuming and complex
Solution Approach 1:
The handshaking mechanism enables self-service automated upgrade management. The master node automatically announces its version status, and slave nodes automatically adjust their access behavior based on this information, eliminating the need for manual intervention while maintaining compatibility control.
Solution Approach 2:
The system implements feedback through the handshaking mechanism where the master node's version status is continuously communicated to slave nodes. This feedback loop allows automatic adjustment of data access behavior, enabling seamless upgrades without manual timing or coordination.
Data Source
AI summary
A method for upgrading software having steps (A) to (D) is disclosed. Step (A) may deny a first server access to read from and write to a database controlled by a second server while second software in the second server is being upgraded. The second software as upgraded may be incompatible with first software running in the first server. Step (B) may generate data in the first server in response to a current operation of the first software while the second software is being upgraded. Step (C) may update the database by transferring the data from the first server to the database through the second server after the upgrade of the second software has finished. The first server generally remains denied to read from the database. Step (D) may upgrade the first software to be compatible with the second software in response to finishing the current operation.


