Global Backup Lock Manager for Cluster Maintenance

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In a database cluster, the reconfiguration process following a server instance shutdown is time-intensive and resource-intensive due to the need to rebuild mastership information across surviving instances, which can exceed acceptable service-level agreement (SLA) limits, especially when multiple server instances are offline for maintenance.

Innovation Solution

Implementing a Global Backup Lock Manager (GBLM) that stores and manages lock information for unavailable server instances, allowing the cluster to remain operational and reducing the need for rebuilding mastership information by handling lock requests and maintaining concurrency control independently.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of repair

If a server instance is shut down for maintenance, then the instance can be updated or repaired, but the reconfiguration process requires significant time and resources to rebuild mastership information across surviving instances

Engineering Contradiction:

Improveserver instance maintenanceVSAvoidreconfiguration time

Core Design Contradiction:

Ease of repairVSLoss of time

Solution Approach 1:

The global backup lock manager is pre-populated with lock information from all server instances before any shutdown occurs. This preliminary action ensures that when a server instance is taken offline for maintenance, the backup lock manager already contains the necessary mastership information to immediately assume lock management responsibilities, eliminating the time-intensive rebuild process that would otherwise be required

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The global backup lock manager serves as an intermediary between server instances and the distributed lock management system. It maintains a comprehensive copy of lock information and can immediately assume the role of lock manager when a primary server instance goes offline, acting as a mediator that prevents the need for time-consuming information redistribution among surviving instances

Inventive Principle:

Principle #24Intermediary (Mediator)

2Ease of repair

If a server instance is shut down, then maintenance can be performed, but surviving instances must replay a significant portion of mastership information which is resource-intensive

Engineering Contradiction:

Improveserver instance maintenanceVSAvoidprocessing resources

Core Design Contradiction:

Ease of repairVSUse of energy by moving object

Solution Approach 1:

The global backup lock manager maintains a complete copy of lock information from all server instances in the cluster. This copying approach allows any surviving instance to immediately obtain the necessary mastership information from the backup lock manager without having to replay lock information from multiple other surviving instances, significantly reducing the processing resources required during reconfiguration

Inventive Principle:

Principle #26Copying

Solution Approach 2:

The global backup lock manager acts as an intermediary that centralizes lock information management. Instead of surviving instances exchanging information directly (which requires O(n) communication and processing), they all interact with the backup lock manager that already has the complete information, reducing the resource-intensive replay process to a simple information transfer

Inventive Principle:

Principle #24Intermediary (Mediator)

3Ease of repair

If multiple server instances are offline simultaneously, then maintenance can be performed on multiple instances, but the reconfiguration time and resource requirements increase significantly

Engineering Contradiction:

Improvemultiple server instance maintenanceVSAvoidcluster availability

Core Design Contradiction:

Ease of repairVSProductivity

Solution Approach 1:

The global backup lock manager serves as a central intermediary that maintains comprehensive lock information for the entire cluster. When multiple server instances are offline simultaneously, the remaining instances can all obtain necessary mastership information from the backup lock manager without needing to communicate with each other or replay information from multiple sources, maintaining cluster productivity and availability even during multi-instance maintenance

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The backup lock manager is pre-populated with complete lock information from all instances before any maintenance begins. This preliminary action ensures that regardless of how many instances go offline simultaneously, the backup lock manager already contains the necessary information to support immediate reconfiguration, preventing productivity loss and maintaining cluster availability

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS9489269B2Global backup lock manager

Publication Date: 2016.11.08 ORACLE INT CORP

AI summary

Techniques for mastering resources in a cluster of nodes are provided. A global backup lock manager (GBLM) is maintained for a cluster of nodes that implement distributed lock management. Before a server instance is taken down, for example, for maintenance purposes, such as installing a new version of the server instance code, the mastership information that the server instance stores is reflected in the mastership information maintained by the GBLM. Thus, shutting down the server instance does not involve remastering the resources mastered by the server instance. As a result, shutting down the server instance may take minimal time.