Mpp parallel database instance level replica balancing method

Abstract

The application relates to a MPP parallel database instance-level copy balancing method, and has the technical features that the balancing strategy of storage IO is that a single storage hard disk is configured for each WAL log, and a shared large-capacity storage hard disk is configured for business data; the balancing strategy of physical memory adopts a dynamic data page buffer allocation mode; the balancing strategy of computing resources adopts a self-adaptive working mode; and the strategy of switching back to the original main instance includes a smooth mode rebalance and a speed mode rebalance to meet different scene requirements. The application fully considers the characteristics of parallel computing, batch data loading and one-time writing and multiple-time querying in the MPP parallel database, balances the instance-level copy from the four aspects of storage IO, physical memory, computing resources and switching back to the original main instance, and finally realizes the maximum computing service capability of the main instance on the basis of not compromising the redundancy capability of the slave instance.

Description

Technical Field

[0001] This invention belongs to the field of database technology, and in particular to a method for instance-level replica balancing in MPP parallel databases. Background Technology

[0002] MPP Parallel Database adopts a share-nothing architecture and is a high-performance distributed parallel database product for data warehousing and business intelligence. MPP Parallel Database consists of a management and coordination node and multiple fully symmetrical computing and storage nodes. By splitting complex queries into multiple child nodes for parallel execution, it can quickly complete statistical analysis queries for data warehousing or intelligent business applications.

[0003] The failure rate of a distributed system is directly proportional to the number of nodes. To improve data reliability and continuous system availability, MPP parallel databases need to provide redundancy and fault tolerance capabilities, i.e., replication technology. Research on replication technology mainly focuses on replication methods, distribution methods, and service capabilities. Specifically, this includes: table-level replication and instance-level replication, dedicated servers and shared servers, hot standby mode and read / write separation mode. MPP parallel databases typically employ instance-level replication, shared servers, and hot standby replication technologies. The instance storing the original data is called the master instance, and the instance storing redundant copies is called the slave instance. Master-slave instance deployment is as follows: Figure 1 As shown. For example, Greenplum and ShenTong MPP Parallel Database 5.0 both use this replication technology implementation.

[0004] The specific working principle of MPP parallel database instance-level replicas is as follows: First, according to a certain strategy, the replica instance is deployed to a server outside the corresponding primary instance within the cluster. The simplest strategy is to sequentially select the next numbered server. Then, the primary instance runs in full mode, providing query and computation services, while the replica instance runs in recovery mode, receiving and replaying the WAL logs sent from the primary instance, but not providing any services. When the primary instance fails and goes offline, the MPP parallel database identifies and notifies the replica instance to switch from recovery mode to full mode and provide query and computation services. This is called promoting the replica instance to the primary instance. Similarly, the primary instance can be demoted to a replica instance when needed.

[0005] MPP parallel databases are typically used for complex statistical analysis queries on large datasets, characterized by periodic batch data loading and one-time write-multiple-queries. Furthermore, unlike transactional database systems that prioritize high throughput, MPP parallel databases emphasize parallel computing capabilities for single tasks. Therefore, during task execution, server resources, including processors, physical memory, and storage I / O, are often under high load or even full load. While replication technology can improve system reliability and availability, it inevitably impacts system service capabilities by consuming system resources.

[0006] Furthermore, after the primary instance fails and goes offline, the secondary instance is promoted to primary to continue providing computation. Although the MPP parallel database can still provide services, the overall service capacity decreases due to the loss of a node. Assuming the MPP parallel database has N nodes, the loss of one node will ideally reduce the overall service capacity by 1 / N. Since the single node server must bear the dual load of its own operation and the newly promoted primary, it becomes the performance bottleneck, potentially reducing the MPP parallel database's service capacity by up to 50%. Therefore, the MPP parallel database needs the ability to switch back to the original primary instance while minimizing the impact on applications, achieving a balance between recovery and service. Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of the prior art and provide an MPP parallel database instance-level replica balancing method, which maximizes the computing service capacity of the master instance without compromising the redundancy of the slave instance.

[0008] The present invention solves the existing technical problems by adopting the following technical solution:

[0009] An MPP parallel database instance-level replica balancing method includes storage I / O balancing strategies, physical memory balancing strategies, computing resource balancing strategies, and original master instance switching strategies.

[0010] The storage I / O balancing strategy is as follows: configure a separate storage hard drive for each WAL log and a shared large-capacity storage hard drive for business data.

[0011] The physical memory balancing strategy employs a dynamic data page buffer allocation method.

[0012] The computing resource balancing strategy adopts an adaptive working mode, which adds a log replay thread pool, a coordination manager, and an RTO threshold to the instance. In the initial stage, the instance only starts one log replay thread. The coordination manager is responsible for calculating the WAL log replay progress in real time. If the replay progress exceeds the set RTO threshold, more threads will be woken up to replay in parallel until all replays are completed. Then, one replay thread is released and kept to continue working.

[0013] The strategy for switching back to the original instance includes smooth mode rebalance and speed mode rebalance to meet different scenario requirements.

[0014] Furthermore, the WAL log is configured with a separate storage hard drive consisting of SAS hard drives in RAID 1, while the service data is configured with a large-capacity storage hard drive consisting of multiple large-capacity SATA hard drives in RAID 5.

[0015] Furthermore, the dynamic data page buffer allocation method is as follows: two capacity values ​​are set for the data page buffer: initial capacity and normal capacity. Two buffer blocks are set for the buffer blocks that store pages. When the database instance starts from the instance, a hash mapping array and a first buffer block are created according to the initial capacity. At this time, the buffer size is the initial capacity. When the slave instance is promoted to the master instance, the hash mapping array is increased and a second buffer block is created. The buffer is increased to the normal capacity. When the master instance is demoted to the slave instance, the hash mapping array is reduced and the second buffer block is deleted.

[0016] Furthermore, the ratio of the initial capacity to the normal capacity is 1:4.

[0017] Furthermore, the specific implementation method for promoting an instance from a primary instance is as follows:

[0018] (1) Increase the size of the hash map array;

[0019] (2) Calculate the difference between the normal capacity and the initial capacity, request a second buffer block and form a buffer block group with the first buffer block;

[0020] (3) According to the dynamic hash algorithm, some pages are migrated from the first buffer block to the second buffer block;

[0021] (4) Page access will automatically redirect to the new storage location.

[0022] Furthermore, the specific implementation method for downgrading the primary instance to a secondary instance is as follows:

[0023] (1) According to the dynamic hash algorithm, the data pages in the second buffer block are migrated to the first buffer block;

[0024] (2) If there is no free space in the first buffer block, flush the remaining data pages back to the data file;

[0025] (3) Reduce the hash map array;

[0026] (4) Release the memory space of the second buffer block;

[0027] (5) Page visits will automatically redirect to the new storage location.

[0028] Furthermore, in the computing resource balancing strategy, the coordination manager also sets the number of threads for parallel replay according to the instruction to modify the RTO threshold. When the RTO threshold is modified to 0, parallel replay from the instance will be triggered immediately. The specific implementation method of parallel replay from the instance is as follows:

[0029] (1) The receiving thread flushes the received WAL logs back to the log file;

[0030] (2) Receive thread notifications to the coordination manager regarding log flushing progress;

[0031] (3) The replay thread reads the WAL log sequentially for replay;

[0032] (4) The replay thread notifies the coordination manager of the log replay progress;

[0033] (5) The coordination manager detected that the deviation between the replay progress and the playback progress exceeded the RTO threshold, so more threads were started to play the playback in parallel.

[0034] (6) The coordination manager checks and finds that all playbacks have been completed, so it releases and retains one playback thread to continue working.

[0035] Furthermore, the specific implementation method of the smoothing mode rebalance is as follows:

[0036] (1) Register the rebalance event and start a background task;

[0037] (2) The primary instance continues to provide complete services to the outside world;

[0038] (3) Background task monitoring starts from the replay progress of the instance and continues until completion;

[0039] (4) A background task triggers a rebalance, switching the master-slave roles. The master instance is demoted to a slave instance, and the slave instance is promoted to a master instance.

[0040] (5) The new primary instance begins to provide query and computation services.

[0041] Furthermore, the specific implementation method of the speed mode rebalance is as follows:

[0042] (1) Execute the rebalance statement and wait for it to finish;

[0043] (2) Restrict the MPP parallel database from providing update, delete, and other modification services to external users;

[0044] (3) The notification starts multiple threads from the instance to replay in parallel;

[0045] (4) Once playback is complete, switch the master and slave roles: the master instance is demoted to a slave instance, and the slave instance is promoted to a master instance.

[0046] (5) Once the rebalance statement finishes execution, the new primary instance begins providing query calculations.

[0047] The advantages and positive effects of this invention are:

[0048] This invention fully considers the characteristics of parallel computing, batch data loading, and multiple queries with a single write in MPP parallel databases. It balances instance-level replicas from four aspects: storage I / O, physical memory, computing resources, and switching back to the original primary instance. Ultimately, it maximizes the computing service capacity of the primary instance without compromising the redundancy of the secondary instance. Attached Figure Description

[0049] Figure 1 This is a diagram illustrating the existing master-slave instance deployment;

[0050] Figure 2 This is a schematic diagram of the master-slave instance storage balancing method of the present invention;

[0051] Figure 3 This is a schematic diagram of the data page buffer of an existing database instance;

[0052] Figure 4 This invention increases the data page buffer (promoting an instance to a primary instance);

[0053] Figure 5 This invention reduces the data page buffer (the primary instance is downgraded to a secondary instance);

[0054] Figure 6 This is a schematic diagram of parallel playback of instances according to the present invention;

[0055] Figure 7 This is a schematic diagram of the smoothing mode rebalance of the present invention;

[0056] Figure 8 This is a schematic diagram of the speed mode rebalance of the present invention. Detailed Implementation

[0057] The following detailed description of embodiments of the present invention is provided in conjunction with the accompanying drawings.

[0058] A method for MPP parallel database instance-level replica load balancing includes:

[0059] 1. Storage I / O balancing strategies

[0060] MPP parallel databases have very high requirements for storage metrics, typically considering storage capacity and I / O bandwidth. I / O load balancing issues arise between master-slave instances on the same server, necessitating research into whether master-slave instances should use independent storage or share the entire storage system.

[0061] To ensure data consistency among replicas, MPP parallel databases require that the corresponding WAL logs on the slave instances be successfully written to storage simultaneously when a transaction is committed to the master instance. When MPP parallel databases periodically load data in batches, there can be significant I / O write conflicts between the master and slave instances on the same server. Clearly, in this situation, independent storage can maximize loading performance. However, independent storage introduces the following two problems:

[0062] (1) Storage capacity: When processing large amounts of data, MPP parallel databases may temporarily write some intermediate results to external storage due to insufficient physical memory. The slave instance does not provide queries and does not need this storage overhead. This will result in the master instance having a greater storage space overhead than the slave instance, and there may even be a situation where the master instance's storage is exhausted but the slave instance still has spare storage.

[0063] (2) IO bandwidth: MPP parallel databases have very high requirements for IO bandwidth when performing tasks. If independent storage is used, the master instance can only use 50% of the total IO bandwidth. According to the characteristics of MPP parallel databases, which write once and query multiple times, most of the slave instances are idle at this time and cannot effectively utilize this part of the IO bandwidth.

[0064] To balance the efficiency of storage space and I / O bandwidth utilization, this invention designs the following storage I / O balancing strategy, such as... Figure 2 As shown:

[0065] (1) Equip WAL logs (WAL log circular queue buffer) with separate storage. Because the storage capacity of WAL logs is not large, but the requirements for write performance and reliability are very high, choose SAS hard drives with better performance to form RAID1.

[0066] (2) Equip the business data (data page buffer) with a shared large-capacity storage, and use multiple larger capacity SATA hard drives to form RAID5, so as to provide greater IO bandwidth while ensuring storage space utilization.

[0067] 2. Physical memory balancing strategies

[0068] For traditional hard disk-based database management systems, the slow hard drive is the biggest performance bottleneck in the entire data access path. To mitigate the performance impact of this speed mismatch, a data page buffer is implemented internally in the database. Its working principle is similar to that of a CPU cache, prefetching and caching frequently accessed data. The data page buffer consists of a hash table, including a hash mapping array responsible for mapping and buffer blocks responsible for storing the data. See the structural diagram for details. Figure 3 During operation, the page ID is used as the index, and the corresponding position in the buffer block is located through hash mapping before the actual data is read or written. MPP parallel databases are geared towards analysis and statistics, often requiring access to large amounts of data, where the performance improvement brought by the data page buffer is more significant.

[0069] Data page buffers are typically allocated statically, meaning a buffer of a specified size is allocated during database instance startup and remains unchanged during subsequent operation. If an MPP parallel database still uses static allocation, to ensure that slave instances can provide the same computing power as the original master instance after a master instance failure, data page buffers of the same size need to be configured for both master and slave instances.

[0070] According to industry research on CPU cache hit rates, an optimal hit rate is achieved when the cache size and working set size are equal. Insufficient cache size reduces the hit rate, but increasing the cache size does not improve it. Similarly, the primary instance performs computations on a massive dataset and should provide a sufficiently large data page buffer, while the secondary instance only handles WAL log replay; an excessively large data page buffer does not necessarily lead to higher performance. Clearly, an equal, static allocation method is not suitable for scenarios where primary and secondary instances coexist.

[0071] To balance the efficiency of physical memory usage, this invention designs a dynamic data page buffer allocation method. This allocation method sets two capacity values ​​for the data page buffer: an initial capacity and a normal capacity. The buffer block used to store pages is also changed from one to two: buffer block 1 and buffer block 2, referred to as a buffer block group. When the database instance starts as a slave instance, a hash mapping array and buffer block 1 are first created according to the initial capacity; the buffer size at this time is the initial capacity. When the slave instance is promoted to a master instance, the hash mapping array is increased and buffer block 2 is created, increasing the buffer size to the normal capacity. Figure 4 As shown, when a primary instance is downgraded to a secondary instance, the hash map array is reduced and buffer 2 is deleted, as follows. Figure 5 As shown. Additionally, the buffer uses a dynamic hashing algorithm, which reduces the number of pages moved during rehashing.

[0072] In this embodiment, the ratio of initial capacity to normal capacity is 1:4.

[0073] like Figure 4 As shown, the workflow for increasing the data page buffer (promoting from an instance to a primary instance) is as follows:

[0074] 401: Increase the hash map array;

[0075] 402: Calculate the difference between the normal capacity and the initial capacity, and request buffer block 2, which together with buffer block 1 forms a buffer block group;

[0076] 403: According to the dynamic hash algorithm, some pages are moved from buffer block 1 to buffer block 2;

[0077] 404: The page will automatically redirect to a new storage location;

[0078] like Figure 5 As shown, the workflow for reducing the data page buffer (primary instance downgraded to slave instance) is as follows:

[0079] 501: According to the dynamic hash algorithm, migrate the data pages in buffer block 2 to buffer block 1;

[0080] 502: If there is no free space in buffer block 1, flush the remaining data pages back to the data file;

[0081] 503: Shrink Hash Map Array;

[0082] 504: Release the memory space of buffer block 2;

[0083] 505: Page access automatically redirects to the new storage location;

[0084] 3. Computational resource balancing strategies

[0085] The primary instance is responsible for executing query calculations, requiring the creation of a sufficient number of threads (or processes) and consuming significant computing resources. Replaying WAL logs from secondary instances also requires considerable computing resources. MPP parallel databases prioritize the computing power of the primary instance. To reduce resource contention between primary and secondary instances, typically only one (or a small number) worker threads are created for secondary instances, and log replay is performed asynchronously.

[0086] Unlike online trading systems, which experience continuous high loads, the load on MPP parallel databases is typically periodic. For example, in a hybrid deployment scenario where an online trading database and an MPP parallel database analysis database are used, the online trading database handles daily transactions, and data is synchronized to the MPP parallel database analysis database daily via ETL tools for settlement or analysis. In this scenario, the loading and computational load of the MPP parallel database analysis database exhibits a clear periodicity. Adopting an asynchronous working approach from the instance can effectively smooth out peak loads and troughs.

[0087] RTO (Recovery Time Objective) is a key metric for measuring a system's high availability. It measures how long a slave instance needs to take over and provide services after the primary instance fails. The most crucial preparation for promoting a slave instance to primary is replaying all WAL logs. Insufficient worker threads will inevitably impact replay progress, and asynchronous operations can lead to uncontrolled replay delays, ultimately resulting in an excessively high RTO and amplifying the unavailability window of the MPP parallel database.

[0088] To balance the efficiency of computing resource utilization, this invention designs an adaptive working mode that prioritizes computing resources for the master instance while also meeting reasonable RTO (Recovery Time Objective). This mode adds a log replay thread pool, a coordination manager, and an RTO threshold to the slave instances. Initially, each slave instance starts only one log replay thread to minimize competition for computing resources with the master instance. The coordination manager is responsible for real-time calculation of the WAL (Write-Ahead Log) replay progress. If the replay progress exceeds the set RTO threshold, more threads are awakened for parallel replay until all replays are complete. Then, one replay thread is released but retained to continue working. This effectively achieves strong synchronization between the master and slave instances, resolving the issue of uncontrolled latency in asynchronous operations.

[0089] In addition, to enhance the flexibility of the functionality, the coordination manager can receive command requests, such as modifying the RTO threshold or setting the number of threads for parallel playback. Setting the RTO threshold to 0 will immediately trigger parallel playback.

[0090] like Figure 6 As shown, the specific workflow of parallel playback from instances is as follows:

[0091] 601: The receiving thread flushes the received WAL logs back to the log file;

[0092] 602: Receive thread notification to the coordinator manager regarding log flushing progress;

[0093] 603: The replay thread sequentially reads the WAL logs for replay.

[0094] 604: The replay thread notifies the coordination manager of the log replay progress;

[0095] 605: The Coordination Manager detected that the deviation between the replay progress and the playback progress exceeded the RTO threshold, and started more threads to play the playback in parallel.

[0096] 606: The Coordination Manager has checked and found that all replays have been completed. It has released and retained one replay thread to continue working.

[0097] 4. Strategy for switching back to the original instance

[0098] When the primary instance fails and goes offline, a secondary instance is promoted to primary to continue providing computation. During this time, the service capacity of the MPP parallel database will decrease to some extent. Although some research suggests mitigating this decrease by further distributing the load across multiple nodes, the impact remains perceptible to the application. To restore the full service capacity of the MPP parallel database, the failed server needs to be repaired and the original primary instance restarted as soon as possible. After restarting, the original primary instance may experience data inconsistencies and needs to initially run as a secondary instance. Only after synchronization is complete can it be promoted back to primary; this process is called rebalancing.

[0099] Rebalance has two key metrics: smoothness and speed. Smoothness means that the MPP parallel database needs to be able to continuously provide complete service, but can tolerate longer periods of service capacity degradation. Speed ​​means that the MPP parallel database needs to be able to quickly restore full service capability, but can tolerate certain service limitations. Different business scenarios will have different metric requirements. This invention designs two rebalance modes, "smoothness" and "speed," to meet the needs of different scenarios.

[0100] 4.1 Smooth Rebalance Mode

[0101] Registering a rebalance event triggers an MPP parallel database background task to monitor the rebalance progress until synchronization is complete, at which point the database switches back to the original primary instance. During this period, the MPP parallel database is in a state of maximum availability and can provide full services, but the rebalance process takes a relatively long time.

[0102] like Figure 7 As shown, the workflow of smooth mode rebalance is as follows:

[0103] (1) Register the rebalance event and start a background task;

[0104] (2) The primary instance continues to provide complete services to the outside world;

[0105] (3) The background task monitors the replay progress of the instance (original main instance) until it is completed;

[0106] (4) A background task triggers a rebalance, switching the master-slave roles. The master instance is demoted to a slave instance, and the slave instance is promoted to a master instance.

[0107] (5) The new primary instance begins to provide query and computation services.

[0108] 4.2 Speed ​​Mode Rebalance

[0109] Executing the rebalance statement starts multiple threads within the instance to replay the changes in parallel until synchronization is complete, at which point the system switches back to the original primary instance. In this mode, rebalancing is quick, but during this period, the MPP parallel database can only provide query services, not modifications, and query performance is also somewhat affected. See the diagram for a detailed explanation. Figure 8 .

[0110] like Figure 8 As shown, the workflow of speed mode rebalance is as follows:

[0111] (1) Execute the rebalance statement and wait for it to finish;

[0112] (2) Restrict the MPP parallel database from providing update, delete, and other modification services to external users;

[0113] (3) The notification starts multiple threads from the instance (original primary instance) to replay in parallel;

[0114] (4) Once playback is complete, switch the master and slave roles: the master instance is demoted to a slave instance, and the slave instance is promoted to a master instance.

[0115] (5) Once the rebalance statement finishes execution, the new primary instance begins providing query calculations.

[0116] This invention balances instance-level replicas by utilizing the aforementioned storage I / O, physical memory, computing resources, and the fallback of the original primary instance, thereby maximizing the computing service capabilities of the primary instance without compromising the redundancy of the secondary instances.

[0117] It should be emphasized that the embodiments described in this invention are illustrative rather than limiting. Therefore, this invention includes, but is not limited to, the embodiments described in the specific embodiments. Any other embodiments derived by those skilled in the art based on the technical solutions of this invention also fall within the scope of protection of this invention.

Claims

1. A method for instance-level replica load balancing in MPP parallel databases, characterized in that: This includes strategies for balancing storage I / O, physical memory, computing resources, and switching back to the original host instance. The storage I / O balancing strategy is as follows: configure a separate storage hard drive for each WAL log and a shared large-capacity storage hard drive for business data. The physical memory balancing strategy employs a dynamic data page buffer allocation method. The computing resource balancing strategy adopts an adaptive working mode, which adds a log replay thread pool, a coordination manager, and an RTO threshold to the instance. In the initial stage, the instance only starts one log replay thread. The coordination manager is responsible for calculating the WAL log replay progress in real time. If the replay progress exceeds the set RTO threshold, more threads will be woken up to replay in parallel until all replays are completed. Then, one replay thread is released and kept to continue working. The strategy for switching back to the original main instance includes a smooth rebalance mode and a speed rebalance mode to meet different scenario requirements; The dynamic data page buffer allocation method is as follows: two capacity values ​​are set for the data page buffer: initial capacity and normal capacity. Two buffer blocks are set for the buffer blocks that store pages. When the database instance starts from the instance, a hash mapping array and the first buffer block are created according to the initial capacity. At this time, the buffer size is the initial capacity. When the slave instance is promoted to the master instance, the hash mapping array is increased and the second buffer block is created. The buffer is increased to the normal capacity. When the master instance is demoted to the slave instance, the hash mapping array is reduced and the second buffer block is deleted. The specific implementation method of the smooth mode rebalance is as follows: (1) Register the rebalance event and start a background task; (2) The primary instance continues to provide complete services to the outside world; (3) Background task monitoring starts from the replay progress of the instance and continues until completion; (4) A background task triggers a rebalance, switching the master-slave roles. The master instance is demoted to a slave instance, and the slave instance is promoted to a master instance. (5) The new primary instance begins to provide query and computation services. The specific implementation method of the speed mode rebalance is as follows: (1) Execute the rebalance statement and wait for it to finish; (2) Restrict the MPP parallel database from providing update and delete services to external users; (3) The notification starts multiple threads from the instance to replay in parallel; (4) Once playback is complete, switch the master and slave roles: the master instance is demoted to a slave instance, and the slave instance is promoted to a master instance. (5) Once the rebalance statement finishes execution, the new primary instance begins providing query calculations.

2. The MPP parallel database instance-level replica balancing method according to claim 1, characterized in that: The WAL log is configured with a separate storage hard drive consisting of SAS hard drives in RAID 1, while the service data is configured with a large-capacity storage hard drive consisting of multiple large-capacity SATA hard drives in RAID 5.

3. The MPP parallel database instance-level replica balancing method according to claim 1, characterized in that: The ratio of the initial capacity to the normal capacity is 1:

4.

4. The MPP parallel database instance-level replica load balancing method according to claim 1, characterized in that: The specific implementation method for promoting an instance to a primary instance is as follows: (1) Increase the size of the hash map array; (2) Calculate the difference between the normal capacity and the initial capacity, request a second buffer block and form a buffer block group with the first buffer block; (3) According to the dynamic hash algorithm, some pages are migrated from the first buffer block to the second buffer block; (4) Page access will automatically redirect to the new storage location.

5. The MPP parallel database instance-level replica balancing method according to claim 1, characterized in that: The specific implementation method for downgrading the primary instance to a secondary instance is as follows: (1) According to the dynamic hash algorithm, the data pages in the second buffer block are migrated to the first buffer block; (2) If there is no free space in the first buffer block, flush the remaining data pages back to the data file; (3) Reduce the hash map array; (4) Release the memory space of the second buffer block; (5) Page visits will automatically redirect to the new storage location.

6. The MPP parallel database instance-level replica balancing method according to claim 1, characterized in that: In the computing resource balancing strategy, the coordination manager also sets the number of threads for parallel replay according to the instruction to modify the RTO threshold. When the RTO threshold is modified to 0, parallel replay from the instance will be triggered immediately. The specific implementation method of parallel replay from the instance is as follows: (1) The receiving thread flushes the received WAL logs back to the log file; (2) Receive thread notifications to the coordination manager regarding log flushing progress; (3) The replay thread reads the WAL log sequentially for replay; (4) The replay thread notifies the coordination manager of the log replay progress; (5) The coordination manager detected that the deviation between the replay progress and the playback progress exceeded the RTO threshold, so more threads were started to play the playback in parallel. (6) The coordination manager checks and finds that all playbacks have been completed, so it releases and retains one playback thread to continue working.

Images