MongoDB high-availability synchronization method, device and storage medium based on dual-host architecture

Abstract

The present invention relates to a MongoDB high-availability synchronization method, device and storage medium based on a dual-host architecture, wherein the method comprises: when the master node is available, the user terminal accesses the master node through a Keepalived virtual IP module, the master node processes the write operation and generates an operation log, and synchronizes the operation to the standby node in real time through a replica set; when the master node is available, the master node continuously detects the local service status, exchanges heartbeat packets with the standby node, and maintains the master node priority competition state; when the standby node detects that the master node has failed, the standby node takes over the Keepalived virtual IP module and enters a single-instance mode operation state; when the master node fails and recovers, the local service status is automatically detected; when the master node detects that the standby node has failed, the master node switches to a single-node mode and attempts to recover the standby node. The present invention achieves the technical effects of high availability and strong data consistency of the MongoDB cluster through dynamic role allocation and arbitration logic.

Description

Technical Field

[0001] The present invention relates to the field of distributed databases, and in particular to a MongoDB high-availability synchronization method and device based on a dual-host architecture. Background Art

[0002] Traditional MongoDB high availability relies on a three-node (2N+1) configuration of a primary node, a backup node, and an arbitration node. However, this is difficult to implement in resource-constrained scenarios. Additional servers are required as arbitration nodes, which results in high hardware costs. Multi-node configurations require complex network planning and maintenance, making them difficult to adapt to resource-constrained environments. The existing 1+1 architecture lacks an arbitration node, and network partitions may lead to data inconsistencies during master-slave switching, posing the risk of split-brain. Furthermore, it is impossible to dynamically allocate roles within a limited number of servers to balance the load. Summary of the Invention

[0003] The present invention provides a MongoDB high-availability synchronization method, device and storage medium based on a dual-host architecture, aiming to solve at least one of the technical problems existing in the prior art.

[0004] The technical solution of the present invention is a MongoDB high-availability synchronization method based on a dual-host architecture. The MongoDB high-availability synchronization method based on a dual-host architecture is applied to a MongoDB high-availability synchronization device based on a dual-host architecture. The MongoDB high-availability synchronization device based on a dual-host architecture includes a Keepalived virtual IP module, a first node, a second node, and a replica set. The first node and the second node can both work independently. When the first node and the second node are both available, the first node or the second node is set as the master node, and the other node is the standby node. The MongoDB high-availability synchronization method based on the dual-host architecture includes the following steps:

[0005] S100. When the primary node is available, the user terminal accesses the primary node through the Keepalived virtual IP module (VIP). The primary node processes the write operation and generates an operation log (oplog), and synchronizes the operation to the standby node in real time through the replica set.

[0006] S200: When the master node is available, it continuously monitors the local MongoDB service status, hardware health (IPMI), and network quality, and exchanges heartbeat packets with the standby node through the VRRP protocol to maintain the master node priority competition status.

[0007] S300: When the standby node detects that the master node has failed, it triggers the VRRP priority election mechanism to take over the Keepalived virtual IP module (VIP) and enters the single-instance mode.

[0008] S400: When the master node recovers from the fault, the local service status is automatically detected, the master-slave node is switched, and an attempt is made to rejoin the replica set to restore the cluster mode operation state;

[0009] S500: When the master node detects that the standby node fails, the master node switches to single-node mode and attempts to restore the standby node.

[0010] Further, in step S300,

[0011] If the standby node detects that the number of heartbeat losses of the master node exceeds the preset threshold, it determines that the master node has failed and starts the takeover operation.

[0012] Furthermore, step S300 includes:

[0013] S310: After the standby node switches, the dynamic arbitration logic is started to simulate the arbitration role to ensure the legitimacy of the election;

[0014] S320: The standby node reconfigures the replica set using the rs.reconfig command and updates the role status.

[0015] S330: The user terminal is redirected to the standby node through the Keepalived virtual IP module (VIP) to continue processing service requests.

[0016] Furthermore, step S400 includes:

[0017] S410: Based on the preset master-slave node switching setting, the standby node sends a repair cluster mode request to the master node after the failure is recovered, downgrading the original master node to a standby node and updating the original standby node to the master node;

[0018] S420: The new standby node pulls the operation log (oplog) from the new primary node and synchronizes the data to the latest state, periodically performing hash comparison operations to ensure zero data loss.

[0019] S430, after the primary node and the backup node have completed data synchronization, the replica set cluster mode is restored.

[0020] Further, in step S500,

[0021] If the master node detects through periodic heartbeats that the number of heartbeat losses of the master node exceeds a preset threshold, it determines that the master node has failed and initiates a takeover operation.

[0022] Furthermore, step S500 includes:

[0023] S510: The master node triggers a self-protection mechanism and runs a script to switch the replica set to single-node mode. This prevents the master node from being downgraded due to insufficient replica set members, ensuring continued read / write functionality of the master node.

[0024] S520: The master node continues to generate a local operation log (oplog), and the master node stops synchronizing data with the standby node.

[0025] Furthermore, step S500 further includes:

[0026] S530: The standby node automatically restarts the MongoDB service through the health check script, cleans up temporary files, and ensures that the standby node instance can start normally.

[0027] S540: After the standby node restarts, the master node continues to send heartbeat packets to the standby node. After detecting a response from the standby node, the master node sends a request to repair the cluster mode to the standby node.

[0028] S550: The primary node confirms that the local MongoDB is in single-node mode and then attempts to rejoin the standby node to the replica set using the rs.reconfig command.

[0029] S560: After receiving the repair request from the primary node, the standby node starts the MongoDB standby instance and joins it to the replica set.

[0030] S570: The standby node starts the oplog synchronization thread. Based on the lastAppliedOpTime, the standby node pulls the oplog accumulated during the failure from the primary node and applies each oplog entry to the standby node's local database.

[0031] S580: Periodically calculate the data hash values of the master node and the backup node, and compare the hash value results to ensure zero data loss.

[0032] Furthermore, the present invention also proposes a MongoDB high-availability synchronization device based on a dual-host architecture, which is used to implement the MongoDB high-availability synchronization method based on a dual-host architecture. The MongoDB high-availability synchronization device based on a dual-host architecture includes:

[0033] Keepalived virtual IP module (VIP), which is used for user access and coordination of switching between primary and standby nodes;

[0034] A first node, the first node is connected to the Keepalived virtual IP module;

[0035] A second node, wherein the second node is connected to the Keepalived virtual IP module and the first node respectively;

[0036] The first node and the second node can both work independently. When both the first node and the second node are available, the first node or the second node is set as the primary node, and the other node is set as the backup node.

[0037] A replica set, the first node and the second node are respectively connected to the replica set.

[0038] Furthermore, the first node includes a first management platform and a first database instance connected in sequence, the first management platform including a first heartbeat detection module, a first priority decision module and a first database cluster mode control module;

[0039] The second node includes a second management platform and a second database instance connected in sequence, and the second management platform includes a second heartbeat detection module, a second priority decision module and a second database cluster mode control module.

[0040] Furthermore, the present invention also proposes a computer-readable storage medium having program instructions stored thereon, and when the program instructions are executed by a processor, the MongoDB high-availability synchronization method based on a dual-host architecture is implemented.

[0041] The beneficial effects of the present invention are:

[0042] This invention uses innovative dynamic role allocation and arbitration logic to achieve high availability and strong data consistency in MongoDB clusters, even with the limited resources of only two physical servers (a 1+1 architecture). This method and system achieves high availability equivalent to a three-node cluster, significantly reducing hardware costs and operational complexity, and improving the stability and data consistency of the cloud PC management platform. This method is suitable for scenarios that are sensitive to hardware costs and require high reliability, such as cloud services for small and medium-sized enterprises and edge computing nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 This is a flowchart of the MongoDB high-availability synchronization method based on a dual-host architecture.

[0044] Figure 2 A schematic diagram of a MongoDB high-availability synchronization device based on a dual-host architecture.

[0045] Figure 3 A schematic diagram of one embodiment of a MongoDB high-availability synchronization device based on a dual-host architecture.

[0046] Figure 4 This is a flowchart for master node failure and automatic recovery in the MongoDB high-availability synchronization method based on a dual-host architecture.

[0047] Figure 5 This is a flowchart of standby node failure and automatic recovery in the MongoDB high-availability synchronization method based on a dual-host architecture.

[0048] Figure numerals: 100, Keepalived virtual IP module; 200, first node; 210, first management platform; 211, first heartbeat detection module; 212, first priority decision module; 213, first database cluster mode control module; 220, first database instance; 300, second node; 310, second management platform; 311, second heartbeat detection module; 312, second priority decision module; 313, second database cluster mode control module; 320, second database instance; 400, replica set. DETAILED DESCRIPTION

[0049] The following will be combined with the embodiments and drawings to clearly and completely describe the concept, specific structure and technical effects of the present invention so as to fully understand the purpose, scheme and effect of the present invention. It should be noted that the embodiments and features in the embodiments of this application can be combined with each other unless there is a conflict.

[0050] It should be noted that, unless otherwise specified, when a feature is referred to as being "fixed" or "connected" to another feature, it may be directly fixed or connected to the other feature or indirectly fixed or connected to the other feature. Furthermore, terms such as "upper," "lower," "left," "right," "top," and "bottom" used in this disclosure are intended solely to describe the relative positions of the components of the disclosure as shown in the accompanying drawings.

[0051] In addition, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art. The terms used in this specification are only for describing specific embodiments and are not intended to limit the present invention. The term "and / or" as used herein includes any combination of one or more of the related listed items.

[0052] It should be understood that although the terms first, second, third, etc. may be used to describe various elements in the present disclosure, these elements should not be limited to these terms. These terms are only used to distinguish elements of the same type from each other. For example, a first element may also be referred to as a second element, and similarly, a second element may also be referred to as a first element without departing from the scope of the present disclosure.

[0053] Reference Figures 1 to 5In some embodiments, the technical solution of the present invention is a MongoDB high-availability synchronization method based on a dual-host architecture. The MongoDB high-availability synchronization method based on a dual-host architecture is applied to a MongoDB high-availability synchronization device based on a dual-host architecture. The MongoDB high-availability synchronization device based on a dual-host architecture includes a Keepalived virtual IP module, a first node, a second node, and a replica set. The first node and the second node can both work independently. When the first node and the second node are both available, the first node or the second node is set as the primary node, and the other node is the backup node. Figure 1 The MongoDB high-availability synchronization method based on a dual-host architecture includes the following steps:

[0054] S100. When the primary node is available, the user terminal accesses the primary node through the Keepalived virtual IP module (VIP). The primary node processes the write operation and generates an operation log (oplog), and synchronizes the operation to the standby node in real time through the replica set.

[0055] S200: When the master node is available, it continuously monitors the local MongoDB service status, hardware health (IPMI), and network quality, and exchanges heartbeat packets with the standby node through the VRRP protocol to maintain the master node priority competition status.

[0056] S300: When the standby node detects that the master node has failed, it triggers the VRRP priority election mechanism to take over the Keepalived virtual IP module (VIP) and enters the single-instance mode.

[0057] S400: When the master node recovers from the fault, the local service status is automatically detected, the master-slave node is switched, and an attempt is made to rejoin the replica set to restore the cluster mode operation state;

[0058] S500: When the master node detects that the standby node fails, the master node switches to single-node mode and attempts to restore the standby node.

[0059] The beneficial effects of the present invention are:

[0060] This invention uses innovative dynamic role allocation and arbitration logic to achieve high availability and strong data consistency in MongoDB clusters, even with the limited resources of only two physical servers (a 1+1 architecture). This method and system achieves high availability equivalent to a three-node cluster, significantly reducing hardware costs and operational complexity, and improving the stability and data consistency of the cloud PC management platform. This method is suitable for scenarios that are sensitive to hardware costs and require high reliability, such as cloud services for small and medium-sized enterprises and edge computing nodes.

[0061] Specifically, the MongoDB high-availability synchronization method based on a dual-host architecture achieves an equivalent 2N+1 data synchronization effect on a 1+1 master-slave pair, avoiding the risk of split-brain through dynamic role allocation and intelligent arbitration logic; reduces hardware costs, eliminates the need for additional arbitration servers, and saves more than 50% of hardware resources; improves deployment flexibility, supports rapid switching and role migration, and adapts to resource-constrained scenarios such as edge computing; ensures strong data consistency and ensures RPO=0 during master-slave switching.

[0062] Compared with the prior art, the advantages of the present invention are:

[0063] 1) Dynamic arbitration mechanism: Intelligently allocates arbitration roles between two nodes, replacing the traditional third node function.

[0064] 2) Hybrid priority strategy: Dynamically adjust node priority based on load and network status to optimize election efficiency.

[0065] 3) Virtualized resource reuse: Run multiple instances on the same physical server to achieve a logical "2N+1" architecture.

[0066] 4) Fully automated switching: An integrated control module that integrates health detection, arbitration decision-making, and data synchronization.

[0067] Specifically, steps S100-S200 are the normal operation stage of the master node, which mainly includes the following operations:

[0068] 1) Client access: Users access the cloud PC management platform service through the Keepalived virtual IP (VIP), and the request is routed to the master node.

[0069] 2) Data read and write processing: The primary node handles all write operations, generates an operation log (oplog), and synchronizes it to the standby node in real time through the replica set mechanism (latency < 20ms).

[0070] 3) Heartbeat detection and health monitoring: The master node continuously monitors the local MongoDB service status, hardware health (IPMI), and network quality (packet loss rate <0.1%). The master and standby nodes exchange heartbeat packets through the VRRP protocol to maintain priority competition.

[0071] Further, refer to Figure 1 In step S300,

[0072] If the standby node detects that the number of heartbeat losses of the master node exceeds the preset threshold, it determines that the master node has failed and starts the takeover operation.

[0073] Further, refer to Figure 1 , step S300 includes:

[0074] S310: After the standby node switches, the dynamic arbitration logic is started to simulate the arbitration role to ensure the legitimacy of the election;

[0075] S320: The standby node reconfigures the replica set using the rs.reconfig command and updates the role status.

[0076] S330: The user terminal is redirected to the standby node through the Keepalived virtual IP module (VIP) to continue processing service requests.

[0077] Specifically, step S300 is the master node failover phase, which mainly includes the following operations:

[0078] 1) Fault detection: The standby node detects the loss of the master node's heartbeat (the continuous timeout threshold is configurable, such as 3 times of no response) and determines that the master node has failed.

[0079] 2) VIP Drift and Role Switching: The standby node triggers a VRRP priority election, takes over the virtual IP (VIP), and becomes the new master node. Simultaneously, the standby node initiates dynamic arbitration logic, simulating the arbitration role in a traditional three-node system to ensure the legitimacy of the election.

[0080] 3) Replica set reconfiguration: After the standby node is promoted to the primary node, reconfigure the MongoDB replica set using the rs.reconfig command to update the role status.

[0081] 4) Seamless client redirection: The client is automatically redirected to the new primary node through the VIP, and business requests are continuously processed (RTO < 5 seconds).

[0082] Further, refer to Figure 1 , step S400 includes:

[0083] S410: Based on the preset master-slave node switching setting, the standby node sends a repair cluster mode request to the master node after the failure is recovered, downgrading the original master node to a standby node and updating the original standby node to the master node;

[0084] S420: The new standby node pulls the operation log (oplog) from the new primary node and synchronizes the data to the latest state, periodically performing hash comparison operations to ensure zero data loss.

[0085] S430, after the primary node and the backup node have completed data synchronization, the replica set cluster mode is restored.

[0086] Specifically, step S400 is for master node recovery and data synchronization, which mainly includes the following operations:

[0087] 1) Master node self-healing: After the original master node recovers, it automatically detects the local service status and attempts to rejoin the replica set.

[0088] 2) Downgrade to a standby node: The new master node (the original standby node) sends a repair cluster mode request to the recovery node, downgrading it to a standby node.

[0089] 3) Data consistency repair: The recovery node pulls the latest operation log (oplog) from the new master node, synchronizes the data to the latest state, and periodically performs hash comparisons to ensure zero data loss (RPO = 0).

[0090] 4) Cluster mode reconstruction: After the master and slave nodes complete data synchronization, the replica set cluster mode is automatically restored.

[0091] Reference Figure 4 In another embodiment, for steps S300 to S400, the cloud PC management platform is the first management platform of the first node or the second management platform of the second node. The following is the process of automatic recovery of the primary node server failure:

[0092] 1) The standby node server cloud PC management platform sends a MongoDB cluster replica set status detection request to the primary node server cloud PC management platform;

[0093] 2) When the Cloud PC Management Platform of the standby node server detects that the primary node server is disconnected, the standby node server will run for VIP and trigger the reconfiguration of the replica set, making the local instance the primary, completing the automatic switchover of the primary and backup services;

[0094] 3) The master node server automatically detects and runs the script to complete the master node service recovery;

[0095] 4) The backup node server cloud PC management platform continuously sends heartbeat detection packets to the primary node server cloud PC management platform;

[0096] 5) After the standby node server cloud PC management platform receives the heartbeat response packet from the primary node server cloud PC management platform, it sends a request to repair the MongoDB cluster mode to the primary node server cloud PC management platform;

[0097] 6) The master node server cloud PC management platform receives the request from the standby node server cloud PC management platform to repair the MongoDB cluster mode. The master node server cloud PC management platform will use the script to change the MongoDB single node mode to cluster mode, and respond to the standby node server cloud PC management platform that the MongoDB cluster mode repair was successful.

[0098] 7) The primary and standby node servers complete the MongoDB cluster mode repair and perform real-time synchronization of the MongoDB database replica set.

[0099] Further, refer to Figure 1 In step S500,

[0100] If the master node detects through periodic heartbeats that the number of heartbeat losses of the master node exceeds a preset threshold, it determines that the master node has failed and initiates a takeover operation.

[0101] Further, refer to Figure 1 , step S500 includes:

[0102] S510: The master node triggers a self-protection mechanism and runs a script to switch the replica set to single-node mode. This prevents the master node from being downgraded due to insufficient replica set members, ensuring continued read / write functionality of the master node.

[0103] S520: The master node continues to generate a local operation log (oplog), and the master node stops synchronizing data with the standby node.

[0104] Further, refer to Figure 1 , step S500 further includes:

[0105] S530: The standby node automatically restarts the MongoDB service through the health check script, cleans up temporary files, and ensures that the standby node instance can start normally.

[0106] S540: After the standby node restarts, the master node continues to send heartbeat packets to the standby node. After detecting a response from the standby node, the master node sends a request to repair the cluster mode to the standby node.

[0107] S550: The primary node confirms that the local MongoDB is in single-node mode and then attempts to rejoin the standby node to the replica set using the rs.reconfig command.

[0108] S560: After receiving the repair request from the primary node, the standby node starts the MongoDB standby instance and joins it to the replica set.

[0109] S570: The standby node starts the oplog synchronization thread. Based on the lastAppliedOpTime, the standby node pulls the oplog accumulated during the failure from the primary node and applies each oplog entry to the standby node's local database.

[0110] S580: Periodically calculate the data hash values of the master node and the backup node, and compare the hash value results to ensure zero data loss.

[0111] Specifically, step S500 is the standby node failure and recovery, which mainly includes the following operations:

[0112] 1) When the primary node detects that the standby node is unresponsive (timed out three times in a row) through periodic heartbeat detection, the primary node triggers a self-protection mechanism and automatically runs a script to switch the MongoDB replica set of this node to single-node mode. This prevents the primary node from being downgraded due to insufficient replica set members and ensures that the primary node remains readable and writable.

[0113] 2) In single-node mode, the primary node continues to generate the operation log (oplog), but suspends data synchronization with the standby node (because the standby node is offline); RPO = 0 guarantee: During single-node mode, all write operations are recorded in the local operation log (oplog) and resynchronized after the standby node recovers.

[0114] 3) The standby node automatically restarts the MongoDB service through the health check script, cleans up temporary files (such as mongod.lock), and ensures that the instance can start normally.

[0115] 4) The master node continues to send heartbeat packets to the standby node. After detecting that the standby node has recovered, it sends a request to repair the cluster mode.

[0116] 5) The primary node detects whether the local MongoDB is in single-node mode. If it is, it triggers the rs.reconfig command to rejoin the standby node to the replica set.

[0117] 6) After receiving the repair request from the primary node, the standby node starts the MongoDB standby instance, joins it to the replica set, and starts the oplog synchronization thread.

[0118] 7) The standby node pulls the operation log (oplog) accumulated during the failure from the primary node and applies it one by one to the local database based on lastAppliedOpTime.

[0119] 8) Periodically calculate the data hash values of the primary and backup nodes (such as db.hash()) and compare the hash value results to ensure zero data loss (RPO = 0).

[0120] Reference Figure 5 In a specific embodiment, the cloud PC management platform is the first management platform of the first node or the second management platform of the second node. The following is the process of automatic recovery of the standby node server failure:

[0121] 1) The master node server cloud PC management platform sends a heartbeat detection packet to the standby node server cloud PC management platform;

[0122] 2) If the Cloud PC Management Platform of the primary node server does not respond to heartbeats during multiple heartbeat detections, the Cloud PC Management Platform of the primary node server will use a script to change the MongoDB cluster mode to single-node mode to ensure that the loss of connection with the backup server does not cause the MongoDB instance of the primary server to be downgraded, thereby affecting normal business use;

[0123] 3) The standby node server monitors the status of the standby node. When the standby node service is abnormal, the script is automatically run to complete the standby node service recovery;

[0124] 4) The cloud PC management platform of the master node server continuously sends heartbeat detection packets to the cloud PC management platform of the backup node server;

[0125] 5) When the master node server cloud PC management platform receives the heartbeat response packet from the standby node server cloud PC management platform, it detects whether the node is in single node mode;

[0126] 6) When the Cloud PC Management Platform of the master node server detects that the local mode is single node, it sends a request to restore the MongoDB cluster mode to the Cloud PC Management Platform of the backup node server;

[0127] 7) The standby node server Cloud PC Management Platform receives the request from the master node server Cloud PC Management Platform to repair the MongoDB cluster mode, executes the MongoDB cluster mode settings, and waits for data to be synchronized from the master node server MongoDB;

[0128] 8) After the active node server cloud PC management platform receives feedback that the standby node server cloud PC management platform has successfully repaired the MongoDB cluster mode, the active node server cloud PC management platform will use a script to change the MongoDB single node mode to cluster mode;

[0129] The active and standby node servers complete the MongoDB cluster mode repair and perform real-time synchronization of the MongoDB database replica set.

[0130] Further, refer to Figure 2 The present invention further proposes a MongoDB high-availability synchronization device based on a dual-host architecture, which is used to implement the MongoDB high-availability synchronization method based on a dual-host architecture. The MongoDB high-availability synchronization device based on a dual-host architecture includes:

[0131] Keepalived virtual IP module (VIP), which is used for user access and coordination of switching between primary and standby nodes;

[0132] A first node, the first node is connected to the Keepalived virtual IP module;

[0133] A second node, wherein the second node is connected to the Keepalived virtual IP module and the first node respectively;

[0134] The first node and the second node can both work independently. When both the first node and the second node are available, the first node or the second node is set as the primary node, and the other node is set as the backup node.

[0135] A replica set, the first node and the second node are respectively connected to the replica set.

[0136] Further, the first node includes a first management platform and a first database instance connected in sequence, the first management platform includes a first heartbeat detection module, a first priority decision module and a first database cluster mode control module;

[0137] The second node includes a second management platform and a second database instance connected in sequence, and the second management platform includes a second heartbeat detection module, a second priority decision module and a second database cluster mode control module.

[0138] Reference Figure 3 In a specific embodiment, a MongoDB high-availability synchronization device based on a dual-host architecture implements a high-availability synchronization method for a cloud PC management platform based on a MongoDB replica set and a Keepalived virtual IP (VIP).

[0139] The core goals of the MongoDB high-availability synchronization device based on a dual-host architecture are:

[0140] 1) High Availability (HA): Ensures service continuity (RTO < 5 seconds) through automatic fault detection and switching.

[0141] 2) Strong data consistency: Real-time synchronization mechanism based on MongoDB replica sets ensures RPO = 0.

[0142] 3) Decentralized decision-making: Each node has a built-in control module that supports dynamic priority decision-making and autonomous switching.

[0143] The core components and functions of the MongoDB high-availability synchronization device based on a dual-host architecture are:

[0144] 1. Client and data reading and writing:

[0145] 1) Client: Users access the cloud PC management platform service through a virtual IP.

[0146] 2) The data read and write process is as follows: When the primary node is active, all read and write requests are processed by the primary node;

[0147] After a failover, clients are automatically redirected to the new primary node (achieved through VIP drift).

[0148] 2. Keepalived virtual IP (VIP):

[0149] 1) Provide a unified access portal.

[0150] 2) Manage the priority competition between the master and backup nodes through the VRRP protocol.

[0151] 3. Primary Node:

[0152] 1) Cloud PC management platform: runs core business logic (such as virtual desktop scheduling and resource allocation).

[0153] Heartbeat detection: monitors the local MongoDB service status, hardware health (IPMI), and network quality (packet loss rate <0.1%).

[0154] Priority decision: Dynamically calculate the node health score and proactively downgrade the priority (triggering VIP release) if abnormal.

[0155] MongoDB cluster mode control: When the number of active MongoDB instances reaches 2N+1, the system automatically restores the MongoDB cluster mode. If the number of active instances is less than 2N+1, to prevent arbitration split-brain, the system adjusts the local MongoDB instance to single-instance mode to ensure data consistency and system stability.

[0156] 2) MongoDB master instance: Processes all write operations, generates operation logs (oplogs), and synchronizes data to the standby node in real time (through the replica set mechanism).

[0157] 4. Standby:

[0158] 1) Cloud PC Management Platform: In hot standby state, ready to take over services at any time.

[0159] Heartbeat detection: monitors the VRRP broadcast of the master node and the status of the replica set.

[0160] Priority decision: Elect for VIP and trigger replica set reconfiguration, promoting the local instance to the primary.

[0161] 2) MongoDB standby instance: Continuously synchronizes the primary node's operation log (oplog) to maintain data consistency.

[0162] 3) MongoDB arbitration instance: does not store data, only participates in elections and voting to prevent replica set split-brain.

[0163] 5. MongoDB replica set synchronization:

[0164] The data synchronization mechanism is real-time operation log (oplog) stream replication. The primary node records the write operation as an operation log (oplog), and the standby node continuously pulls and applies it (delay < 20ms).

[0165] Furthermore, the present invention also proposes a computer-readable storage medium having program instructions stored thereon, and when the program instructions are executed by a processor, the MongoDB high-availability synchronization method based on a dual-host architecture is implemented.

[0166] The innovative features of the present invention are:

[0167] 1) Dynamic arbitration role allocation: Intelligently switches between the master and backup roles between two nodes, simulating a 2N+1 cluster effect;

[0168] 2) Virtualized majority agreement: A logical arbitration mechanism is used to avoid split-brain and ensure the legitimacy of the election.

[0169] 3) Hybrid load-aware strategy: Dynamically adjusts role priorities based on real-time load to optimize resource utilization;

[0170] 4) Lightweight consistency check: Periodic hash comparison combined with real-time oplog synchronization ensures zero data loss.

[0171] The above description is merely a preferred embodiment of the present invention. The present invention is not limited to the above-described embodiments. As long as the technical effects of the present invention are achieved by the same means, any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this disclosure shall be included within the scope of protection of this disclosure. Various modifications and variations of the technical solutions and / or implementation methods may be made within the scope of protection of the present invention.

Claims

1. A MongoDB high-availability synchronization method based on a dual-host architecture, wherein the MongoDB high-availability synchronization method based on a dual-host architecture is applied to a MongoDB high-availability synchronization device based on a dual-host architecture, wherein the MongoDB high-availability synchronization device based on a dual-host architecture comprises a Keepalived virtual IP module, a first node, a second node, and a replica set, wherein the first node and the second node can both work independently, and when both the first node and the second node are available, the first node or the second node is set as the primary node, and the other node is set as the backup node, wherein: The MongoDB high-availability synchronization method based on a dual-host architecture includes the following steps: S100. When the master node is available, the user terminal accesses the master node through the Keepalived virtual IP module. The master node processes the write operation and generates an operation log, and synchronizes the operation to the standby node in real time through the replica set. S200: When the master node is available, the master node continuously detects the service status, hardware health, and network quality of the local MongoDB, exchanges heartbeat packets with the standby node through the VRRP protocol, and maintains the master node priority competition status; S300: When the standby node detects that the master node has failed, it triggers the VRRP priority election mechanism to take over the Keepalived virtual IP module and enters the single-instance mode. Step S300 includes: S310: After the standby node switches, the dynamic arbitration logic is started to simulate the arbitration role to ensure the legitimacy of the election; S320: The standby node reconfigures the replica set using the rs.reconfig command and updates the role status. S330: The user terminal is redirected to the standby node through the Keepalived virtual IP module to continue processing service requests. S400: When the master node recovers from the fault, the local service status is automatically detected, the master-slave node is switched, and an attempt is made to rejoin the replica set to restore the cluster mode operation state; S500: When the master node detects that the standby node fails, the master node switches to single-node mode and attempts to restore the standby node.

2. The MongoDB high-availability synchronization method based on a dual-host architecture according to claim 1, characterized in that: In step S300, If the standby node detects that the number of heartbeat losses of the master node exceeds the preset threshold, it determines that the master node has failed and starts the takeover operation.

3. The MongoDB high-availability synchronization method based on dual-host architecture according to claim 1 is characterized in that: Step S400 includes: S410: Based on the preset master-slave node switching setting, the standby node sends a repair cluster mode request to the master node after the failure is recovered, downgrading the original master node to a standby node and updating the original standby node to the master node; S420: The new standby node pulls the operation log from the new master node and synchronizes the data to the latest state, periodically performing hash comparison operations to ensure zero data loss. S430, after the primary node and the backup node have completed data synchronization, the replica set cluster mode is restored.

4. The MongoDB high-availability synchronization method based on a dual-host architecture according to claim 1, characterized in that: In step S500, If the master node detects through periodic heartbeats that the number of heartbeat losses of the master node exceeds a preset threshold, it determines that the master node has failed and initiates a takeover operation.

5. The MongoDB high-availability synchronization method based on dual-host architecture according to claim 1, characterized in that: Step S500 includes: S510: The master node triggers a self-protection mechanism and runs a script to switch the replica set to single-node mode. This prevents the master node from being downgraded due to insufficient replica set members and ensures the master node's continued read and write capabilities. S520: The master node continues to generate local operation logs, and the master node suspends data synchronization with the standby node.

6. The MongoDB high-availability synchronization method based on dual-host architecture according to claim 5, characterized in that: Step S500 further includes: S530: The standby node automatically restarts the MongoDB service through the health check script, cleans up temporary files, and ensures that the standby node instance can start normally. S540: After the standby node restarts, the master node continues to send heartbeat packets to the standby node. After detecting a response from the standby node, the master node sends a request to repair the cluster mode to the standby node. S550: The primary node confirms that the local MongoDB is in single-node mode and then attempts to rejoin the standby node to the replica set using the rs.reconfig command. S560: After receiving the repair request from the primary node, the standby node starts the MongoDB standby instance and joins it to the replica set. S570: The standby node starts an operation log synchronization thread. Based on lastAppliedOpTime, the standby node pulls the operation logs accumulated during the failure period from the master node and applies them one by one to the standby node's local database. S580: Periodically calculate the data hash values of the master node and the backup node, and compare the hash value results to ensure zero data loss.

7. A MongoDB high-availability synchronization device based on a dual-host architecture, used to implement the MongoDB high-availability synchronization method based on a dual-host architecture as described in any one of claims 1 to 6, characterized in that: The MongoDB high-availability synchronization device based on the dual-host architecture includes: Keepalived virtual IP module, which is used for user access and coordination of switching between primary and standby nodes; A first node, the first node is connected to the Keepalived virtual IP module; A second node, wherein the second node is connected to the Keepalived virtual IP module and the first node respectively; The first node and the second node can both work independently. When both the first node and the second node are available, the first node or the second node is set as the primary node, and the other node is set as the backup node. A replica set, the first node and the second node are respectively connected to the replica set.

8. The MongoDB high-availability synchronization device based on dual-host architecture according to claim 7, characterized in that: The first node includes a first management platform and a first database instance connected in sequence, the first management platform including a first heartbeat detection module, a first priority decision module and a first database cluster mode control module; The second node includes a second management platform and a second database instance connected in sequence, and the second management platform includes a second heartbeat detection module, a second priority decision module and a second database cluster mode control module.

9. A computer-readable storage medium having program instructions stored thereon, characterized in that: When the program instructions are executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images