Dynamic Version Dependency Management for Parallel Workloads
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Rolling upgrades in multi-node clustered databases can lead to version discrepancies between subtasks, causing backward and forward compatibility issues and metadata corruption due to the risk of interrupting parent or child tasks during code version changes.
Innovation Solution
Implementing dynamic management of version dependencies by structuring workloads as a single parent job with multiple child jobs, where the parent job enforces policies to ensure all child jobs run on the same node version, preventing upgrades until all child tasks are completed, and migrating tasks to maintain consistent code versions across nodes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Duration of action of stationary object
If rolling upgrades are performed on multi-node clustered databases, then system availability is maintained during code version changes, but version discrepancies between subtasks cause compatibility issues and metadata corruption
Solution Approach 1:
The patent implements dynamic version dependency management where the system adaptively adjusts job scheduling based on real-time node version states. The workload scheduler dynamically determines which nodes can execute which jobs based on their code versions, and dynamically migrates jobs between nodes as upgrades progress. This dynamic adaptation allows the system to maintain availability while preventing version mismatch errors.
Solution Approach 2:
The patent segments the upgrade process into controlled phases by introducing version dependency tracking. Jobs are segmented into parent jobs and child jobs with explicit version requirements. The system segments nodes into different version groups (upgraded vs. non-upgraded) and schedules jobs appropriately within each segment, preventing cross-version execution issues while maintaining overall system operation.
2Productivity
If parallel workloads are executed across multiple nodes, then processing throughput is improved, but version mismatches between nodes cause compatibility failures
Solution Approach 1:
The patent introduces version dependency information as an intermediary layer between the workload scheduler and the computing nodes. This intermediary tracks which job versions are compatible with which node versions, and uses this information to make intelligent scheduling decisions. The version dependency mechanism acts as a mediator that enables parallel execution while preventing incompatible job-node pairings.
Solution Approach 2:
The system implements feedback loops where the workload scheduler continuously monitors node version states and job execution status. Based on this feedback, the scheduler dynamically adjusts job allocation to maintain version compatibility. When nodes complete upgrades, the system receives feedback and re-balances the workload distribution to utilize the newly upgraded nodes appropriately.
3Stability of the object's composition
If nodes are upgraded sequentially to maintain stability, then version consistency is improved, but upgrade time and system downtime increase
Solution Approach 1:
The patent allows partial parallelization of upgrades by permitting some nodes to be upgraded while others remain on older versions, as long as version compatibility constraints are satisfied. Rather than requiring complete sequential upgrades, the system performs partial upgrades across multiple nodes simultaneously, reducing total upgrade time while maintaining stability through version dependency enforcement.
Data Source
AI summary
A database management system may schedule, according to a first job allocation configuration, a first job allocation for a first computing node, where the first computing node is scheduled to perform a parent job. In some examples, the first job allocation configuration prevents scheduling the parent job on a computing node running a newer code version than a set of computing nodes running the set of child jobs until the set of child jobs terminates. The database management system may further schedule, according to a second job allocation configuration, a second job allocation for a second computing node, where the second computing node is scheduled to perform a child job of the set of child jobs. In some examples, the second job allocation configuration prevents scheduling the child job on computing nodes having a newer code version than the first computing node performing the parent job.