Conflict processing method, device, system and equipment of distributed database and medium

Abstract

This invention discloses a conflict resolution method, apparatus, and system for distributed databases, belonging to the field of distributed databases. The method comprises: acquiring consumer update information fed back by a consumer database cluster, wherein the consumer database cluster extracts information from change unit information when cross-datacenter replication is triggered based on change unit information sent by a producer database cluster; generating a replicable MP transaction based on the consumer update information, and determining whether a transaction conflict exists based on the primary key version snapshot corresponding to the replicable MP transaction and the consumer update information; if a conflicting transaction is determined to exist, adjusting the conflicting transaction based on its timestamp or priority to eliminate the conflict. This invention can both prevent data discrepancies between two database clusters due to conflicts, ensuring data consistency between the two clusters, and prevent data loss due to conflicts in one cluster.

Description

Technical Field

[0001] This invention relates to the technical field of distributed databases, and more particularly to a method, apparatus, system, device, and medium for conflict handling in distributed databases. Background Technology

[0002] In a distributed database, nodes are deployed on different machines, and different partitions are handled by different sites within a node. Each site on a node has its own CPU and memory, processing transactions in a single-threaded, serial, lock-free manner. While this can improve processing efficiency, there is no shared content between replicas, making them susceptible to data discrepancies due to non-deterministic operations (such as local timestamp calculations and pseudo-random number generation) and network failures.

[0003] To avoid the above situation, one common approach is the active-active deployment model across data centers. In this model, two or more geographically dispersed distributed database clusters are in a read-write state, and user requests can be routed to either cluster. Data changes on one cluster need to be replicated to the other cluster in real time, and vice versa, thus completing bidirectional cross-data center replication (XDCR).

[0004] However, the above method has the following technical problems: During bidirectional cross-datacenter replication, conflicts can occur due to network latency. For example, at almost the same time, clusters A and B might make different modifications to the same data (e.g., a record with the same user ID). Conflicts not only cause data discrepancies between the two clusters, making them inconsistent, but can also lead to the loss of updated data in one cluster. Summary of the Invention

[0005] This invention provides a method, apparatus, system, device, and medium for handling conflicts in a distributed database, which can solve the technical problem of inconsistent or lost cluster data due to conflicts during the replication process in the prior art.

[0006] A first aspect of this invention provides a conflict resolution method for a distributed database, the method comprising: Obtain consumption update information fed back by the consumer database cluster, wherein the consumption update information is information extracted from the change unit information when the consumer database cluster triggers cross-data center replication based on the change unit information sent by the producer database cluster; A replicating MP transaction is generated based on the consumption update information, and a transaction conflict is determined based on the primary key version snapshot corresponding to the replicating MP transaction and the consumption update information. If a conflicting transaction is identified, it is adjusted based on the timestamp or priority of the conflicting transaction to eliminate the conflict.

[0007] A second aspect of the present invention provides a conflict handling apparatus for a distributed database, the apparatus comprising: The acquisition module is used to acquire consumption update information fed back by the consumer database cluster, wherein the consumption update information is information extracted from the change unit information when the consumer database cluster triggers cross-data center replication based on the change unit information sent by the producer database cluster. The conflict detection module is used to generate a replicated MP transaction based on the consumption update information, and to determine whether there is a transaction conflict based on the primary key version snapshot corresponding to the replicated MP transaction and the consumption update information. The conflict adjustment module is used to adjust conflicting transactions based on their timestamps or priorities to eliminate them if conflicting transactions are identified.

[0008] A third aspect of this invention provides a conflict resolution system for a distributed database, the system comprising: a producer database cluster, a global MP coordinator, and a consumer database cluster; The producer database cluster is connected to the consumer database cluster, and the global MP coordinator is set in the consumer database cluster. The global MP coordinator executes the conflict resolution method for distributed databases as described above.

[0009] A fourth aspect of the present invention provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the conflict resolution method for a distributed database as described above.

[0010] A fifth aspect of the present invention provides a computer-readable storage medium storing computer-executable instructions for causing a computer to perform the distributed database conflict resolution method described above.

[0011] Compared to existing technologies, the present invention provides a method, apparatus, system, device, and medium for conflict handling in a distributed database, which offers the following advantages: The present invention can acquire consumer update information fed back by the consumer database cluster. This consumer update information is extracted from the change unit information when the consumer database cluster triggers cross-datacenter replication based on the change unit information sent by the producer database cluster. A replication-type MP transaction is generated based on the consumer update information, and the existence of a transaction conflict is determined based on the primary key version snapshot corresponding to the replication-type MP transaction and the consumer update information. If a conflicting transaction is determined, it is adjusted according to the timestamp or priority of the conflicting transaction to eliminate it. The present invention can perform conflict detection based on the change unit information of data changes when two database clusters are replicating across data centers, and adjust the transaction based on its timestamp or priority when a conflict occurs to eliminate the conflicting transaction. This avoids data discrepancies between the two database clusters due to conflicts, ensuring data consistency and improving data accuracy. It also avoids data loss due to conflicts in one cluster. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating a conflict resolution method for a distributed database according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a conflict handling device for a distributed database provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a distributed database conflict handling system provided in an embodiment of the present invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] In a distributed database, nodes are deployed on different machines, and different partitions are handled by different sites within a node. Each site on a node has its own CPU and memory, processing transactions in a single-threaded, serial, lock-free manner. While this can improve processing efficiency, there is no shared content between replicas, making them susceptible to data discrepancies due to non-deterministic operations (such as local timestamp calculations and pseudo-random number generation) and network failures.

[0015] To avoid the above situation, one common approach is the active-active deployment model across data centers. In this model, two or more geographically dispersed distributed database clusters are in a read-write state, and user requests can be routed to either cluster. Data changes on one cluster need to be replicated to the other cluster in real time, and vice versa, thus completing bidirectional cross-data center replication (XDCR).

[0016] However, the above method has the following technical problems: During bidirectional cross-datacenter replication, conflicts can occur due to network latency. For example, at almost the same time, clusters A and B might make different modifications to the same data (e.g., a record with the same user ID). Conflicts not only cause data discrepancies between the two clusters, making them inconsistent, but can also lead to the loss of updated data in one cluster.

[0017] In bidirectional replication mode, due to network latency, "conflicts" can occur: at almost the same time in cluster A and cluster B, different modifications are made to the same data (e.g., a record with the same user ID).

[0018] For example, user U1 changes his address to "xx" in cluster A and his phone number to "138..." in cluster B. After the change logs from both clusters propagate between them, what should be the final status of this user's record? For example, user U1 changes his address in cluster A, while simultaneously in cluster B, the administrator deletes the user's account for some reason. Ultimately, there will be a conflict regarding whether the user should remain or be deleted.

[0019] For example, two clusters might happen to assign the same primary key ID to two different new users due to the delay in the globally unique ID generation mechanism.

[0020] These conflicts not only cause discrepancies in the data between the two clusters, but also, during the conflict, the later-arriving modification will overwrite the previous one, resulting in the loss of one of the updates (address or phone number).

[0021] To address the aforementioned issues, the following detailed description and explanation will be provided through specific embodiments of a distributed database conflict resolution method, apparatus, device, and medium provided in this application.

[0022] To address the technical issues of inconsistency or data loss in cluster data due to conflicts during replication in existing technologies, refer to Figure 1 The diagram shows a flowchart of a conflict resolution method for a distributed database according to an embodiment of the present invention.

[0023] In one embodiment, the conflict resolution method for the distributed database is applied to a global MP coordinator, which is set up in the consumer database cluster.

[0024] As an example, the conflict resolution method for the distributed database may include: S11. Obtain the consumption update information fed back by the consumer database cluster, wherein the consumption update information is the information extracted from the change unit information when the consumer database cluster triggers cross-data center replication based on the change unit information sent by the producer database cluster.

[0025] In one embodiment, the consumer update information is obtained by the consumer database cluster pausing partition log processing based on the change unit information sent by the producer database cluster, and extracting information about the global transaction ID and change data from the change unit information.

[0026] In one operating mode, the producer database cluster can receive distributed transactions, and then the producer database cluster can generate change unit information based on the distributed transactions and send the change unit information to the consumer database cluster.

[0027] The consumer database cluster can pause the log processing flow of the corresponding partition of the distributed transaction based on the change unit information, and extract information about the global transaction ID and changed data from the change unit information. Then, the consumer database cluster can use the extracted information about the global transaction ID and changed data as consumption update information and feed it back to the global MP coordinator. As an example, the operation of the producer database cluster sending change unit information may include the following sub-steps: S21. After receiving a distributed transaction, the producer database cluster generates Binlog information and working units in the partition corresponding to the distributed transaction, wherein the working unit contains a globally unique transaction ID and the change data of the partition in which it is located.

[0028] S22. The producer database cluster inserts the work unit into the Binlog information to generate change unit information, and sends the change unit information to the consumer database cluster.

[0029] When a distributed transaction (MP transaction) is committed in the producer database cluster, each partition involved in the transaction generates a special marker called a "Work Unit" in addition to generating regular Binlogs. During this process, each single partition ensures that all transactions are executed strictly serially to maintain partition-level consistency and operation order and avoid concurrency interference.

[0030] It should be noted that after generating a special marker, all transactions within each single partition are ensured to be executed strictly serially in order to maintain partition-level consistency and operation order. Specifically, the principle is as follows: 1. Transaction Sequencing Queue: Each partition maintains a local transaction sequence number generator. When an MP transaction enters a partition, the system assigns it a monotonically increasing sequence number. This sequence number not only represents the transaction's commit order but also serves as a logical timestamp for the subsequent generation of "work units."

[0031] 2. Partition-level Lock Manager: To prevent concurrency interference, a partition requests exclusive locks based on the row records involved in a transaction when processing a transaction. Before the MP transaction is committed, the lock manager enforces that transactions must acquire locks in sequence number order. If a transaction has a later sequence number, but the resources it involves are locked by an earlier transaction, then the transaction must enter the waiting queue, thus physically ensuring the serialization of transactions within the partition.

[0032] 3. Binding of Work Units: After a transaction acquires a lock and completes data changes, the system encapsulates the transaction's sequence number, lock status information, and changes into a "work unit." Since the work unit is generated before the lock is released, it naturally inherits the serialization attribute of the transaction, ensuring that the execution order of the producer database cluster is preserved when it is subsequently replicated to the consumer database cluster.

[0033] In one embodiment, when generating a work unit, each work unit contains a globally unique "transaction ID" and the specific data changes made by that partition for this MP transaction (i.e., the Binlog content of that partition).

[0034] In one operating mode, the generation of a globally unique "transaction ID" for each unit of work includes the following steps: The first step is centralized-distributed coordinated generation: During the distributed transaction initiation phase, the system deploys a dedicated transaction ID generation service (such as a coordinator). This service maintains an incrementing global counter or timestamp combined with random expansion (e.g., {physical timestamp} - {cluster number} - {auto-incrementing sequence number}).

[0035] The second step is a decentralized conflict avoidance solution: Each cluster or partition pre-allocates a set of consecutive transaction ID ranges. When a transaction is initiated, the header ID of the range is requested first to ensure that even if multiple clusters allocate concurrently, there will be no identification error due to ID overlap.

[0036] Step 3, ID transfer and synchronization: During the transaction's lifecycle, this global transaction ID serves as metadata and flows with the transaction context across all partitions, coordinators, Binlog records, and asynchronous queues.

[0037] Step 4: Uniqueness verification and anti-duplicate mechanism: Each partition must locally verify that the assigned transaction ID is unique within the transaction window. If a conflict is found (such as a historical ID not being cleared), the transaction is rejected and upper-level compensation is triggered to ensure that there are no duplicate transaction IDs globally in the system.

[0038] Step 5: Bind the transaction ID to the partition operation: During the distributed transaction coordination phase, the system writes the same transaction ID into the context objects of all relevant partitions, forming an implicit association.

[0039] Before a transaction is pre-committed, each partition writes its local data changes and transaction IDs to a temporary write set (transaction cache) to facilitate the subsequent generation of bound work units.

[0040] In one embodiment, in order for the partitions of the producer database cluster to make specific data changes for this MP transaction, each partition can perform the following steps: Step 1, change the monitoring: The partitioned transaction execution engine has a built-in change capture module that intercepts all data read / write operations belonging to the current MP transaction in real time and records them to the local change pipeline in the order of operations.

[0041] The second step is to perform hierarchical archiving: For multi-level nested operations (such as multiple UPDATE and DELETE operations caused by a pre-triggered trigger), the system records the causal chain of changes at each level during capture, ensuring that the operation order can be completely restored when the Binlog is written.

[0042] The third step is to change the merge algorithm (non-programming implementation): Before a transaction is committed, all duplicate UPDATEs belonging to the same primary key are merged into a final write, retaining only the final state of necessary fields (saving Binlog space and making the aggregation meaning clearer).

[0043] Step 4: Apply category tags: For the INSERT, UPDATE, and DELETE operations, mark the operation type, the table name involved, the primary key information, and the field values ​​before and after the change.

[0044] The above operations enable each partition of the producer database cluster to identify transactions and perform data modification operations.

[0045] In one embodiment, after generating work units and Binlog information, the producer database cluster can insert these work units into the Binlog information of their respective partitions, that is, insert the work units into the normal Binlog stream of their respective partitions, thereby generating change unit information, which is then sent to the consumer database cluster.

[0046] In one operating mode, to generate change cell information by inserting work cells into the normal Binlog stream of their respective partitions, the process includes the following steps: The first step is the serialization preparation during the transaction commit phase.

[0047] In a producer database cluster, when a distributed transaction commits, internal transaction serialization control is first performed within each involved partition. Each partition uses a partition-level transaction sequence number generator (based on a monotonically increasing logical clock) to assign a local sequence number to the current MP transaction. This sequence number records the execution order of all transactions within that partition, ensuring that MP transaction changes within a partition are strictly serialized and not intertwined with other concurrent transactions within the partition. The generator runs independently in each partition, but all partitions share the same global transaction ID to identify the overall integrity of the MP transaction. At this point, each partition's change operations (such as INSERT, UPDATE, or DELETE) are temporarily buffered in a partition-local transaction change queue, which is arranged in sequence number order to prevent premature insertion of Binlog events from subsequent independent transactions.

[0048] The second step is the construction and labeling of work units.

[0049] Based on buffered change operations, a work unit is constructed for each partition. This work unit, as a composite Binlog event, contains the following core elements: a global transaction ID (used for cross-partition association), a local sequence number (used for maintaining order within the partition), a partition identifier (specifying the source partition), a list of change operations (including specific SQL statements or data differences, such as key-value pair changes), and a transaction boundary marker (a predefined metadata label indicating that the event is part of an MP transaction, rather than an independent single-partition operation). During construction, the partition node verifies the integrity of the change queue. If a missing sequence number or an out-of-order sequence is detected, a rollback mechanism is triggered to ensure that the work unit is generated only after all partition changes have been serialized. This step is implemented through the partition's internal change log recorder, avoiding the risk of partial loss during network transmission.

[0050] The third step is to locate and integrate the insertion into the normal Binlog stream.

[0051] After the work unit is constructed, the partition node initiates the Binlog stream insertion process. First, the node queries the tail position of the current Binlog stream (by the offset recorded in the Binlog index file) and locks write access to that position to prevent concurrent appending of Binlog events from independent transactions. Next, the work unit is inserted as a single atomic event into the specified position in the Binlog stream: this position follows all independent transaction Binlog events with lower sequence numbers but precedes any subsequent events with higher sequence numbers, ensuring that MP transaction changes maintain atomic boundaries in the partition log. If multiple independent transaction events await appending in the Binlog stream, the work unit is placed between them, forming a logical group (e.g., by adding separator tags such as "BEGIN_MP" and "END_MP" before and after the work unit), thus isolating and merging MP transaction changes with other events without splitting the stream structure. After insertion, the lock is immediately released, allowing the normal Binlog stream to continue appending subsequent events. This fusion approach fills the technical gap in the traditional Binlog mechanism due to the fragmentation of multi-partition transaction logs, ensuring that the consumer database cluster can accurately reconstruct the transaction order during replay without additional reorganization overhead.

[0052] The fourth step is to verify the integrity of the Binlog stream.

[0053] After inserting a work unit, the partition node performs a Binlog stream integrity check. This includes: calculating the checksum of Binlog events before and after the work unit (using a simple hash function, such as a byte-level CRC checksum), and appending the checksum to the Binlog header metadata; simultaneously, updating the partition's Binlog index file to record the start offset and length of the work unit. If the check fails (e.g., due to disk I / O anomalies), the insertion is rolled back and re-serialized. This step ensures the robustness of the Binlog stream, preventing data tampering or loss during transmission.

[0054] The fifth step is to send the data to the consumer database cluster via streaming.

[0055] After verification, the work unit and normal Binlog stream can be used as change unit information, so that the work unit is sent to the consumer database cluster through the XDCR transport channel along with the normal Binlog stream of its partition.

[0056] The transmission adopts an incremental streaming push mechanism: the partition node maintains a send buffer, packages the Binlog stream (including newly inserted work units) into fixed-size transmission packets in batches (e.g., each packet does not exceed 1MB), and attaches a sequence number and checksum.

[0057] The transmission process is managed by a partition-level transmission coordinator, which monitors network latency. If a transmission interruption is detected, subsequent packet transmission is paused and the current packet is retransmitted until it is confirmed that the corresponding partition in the consumer database cluster has received and stored the stream segment. Upon arrival at the consumer database cluster, the receiving partition appends the Binlog stream to its local log, awaiting further processing by the global MP coordinator. This transmission method achieves reliable transmission through a batch acknowledgment mechanism (consumer partitions return ACK signals), overcoming the shortcomings of existing XDCR systems in guaranteeing the order of multi-partition logs, ensuring relative consistency of work units within the arrival time window across different partitions, and supporting atomic replication in high-latency network environments.

[0058] In one embodiment, after receiving change unit information, the consumer database cluster can generate consumption update information based on the change unit information, and then feed the consumption update information back to the global MP coordinator.

[0059] As an example, the operation of the consumer database cluster feeding back consumption update information may include the following sub-steps: S31. After the consumer database cluster identifies the work unit with the distributed transaction mark from the change unit information, it suspends the Binlog processing and execution of the partition corresponding to the distributed transaction, and temporarily stores the work unit in the local partition cache.

[0060] S32. The consumer database cluster extracts the global transaction ID, partition identifier, and data change list from the working unit, packages the global transaction ID, partition identifier, and data change list into consumer update information, and sends it.

[0061] In one embodiment, the partition node of the consumer database cluster receives the Binlog stream from the XDCR channel and identifies the work unit marked with MP transaction. Then, it can immediately pause the processing and execution of all subsequent ordinary Binlogs of that partition and temporarily store the current work unit in the local partition cache without persisting data changes.

[0062] Specifically, when any partition in the consumer database cluster receives a Binlog marked as a "unit of work," it does not immediately apply the Binlog. Instead, it submits this unit of work to the global MP coordinator and suspends processing of subsequent Binlog streams from that producer partition.

[0063] It should be noted that the data partition node can be a shard node in the consumer database cluster that stores data and is responsible for receiving the Binlog and performing data operations; the MP transaction marker is the BEGIN_MP or END_MP label in the Binlog, which indicates that the log belongs to a multi-partition distributed transaction.

[0064] The partition nodes of the consumer database cluster can extract the global transaction ID, partition identifier, and data change list from the work unit; and report the extracted information and the original work unit text as consumer update information to the global MP coordinator.

[0065] After sending the consumption update information, you can wait for instructions from the global MP coordinator without writing any data.

[0066] S12. Generate a replicated MP transaction based on the consumption update information, and determine whether there is a transaction conflict based on the primary key version snapshot corresponding to the replicated MP transaction and the consumption update information.

[0067] The global MP coordinator can generate a replicated MP transaction based on the consumer update information. This replicated MP transaction is a replica of the distributed transaction received by the producer database cluster.

[0068] Next, it can be determined whether there is a transaction conflict based on the primary key version snapshot corresponding to the replicated MP transaction and the consumption update information.

[0069] In an optional embodiment, the step of generating a replicated MP transaction based on the consumption update information and determining whether a transaction conflict exists based on the replicated MP transaction and the version snapshot corresponding to the consumption update information may include the following sub-steps: S121. Extract the global transaction ID from the consumer update information, and after receiving the work units reported by all associated partitions in the consumer database cluster, parse the data change content of the work unit and generate a consumer change intention that is consistent with the distributed transaction execution order corresponding to the change unit information.

[0070] S122. After binding the global transaction ID and the consumer change intention, a local distributed transaction of the consumer database cluster is generated to obtain a replicated MP transaction.

[0071] S123. Extract all primary key sets of the distributed transactions corresponding to the change unit information from the consumer change intention, request the storage engine of the consumer database cluster to read the current data version corresponding to the primary key set and generate the corresponding version snapshot.

[0072] S124. If it is determined that the version snapshot and the replicated MP transaction have concurrent primary key modifications, then it is determined that there is a conflicting transaction.

[0073] S125. If it is determined that the version snapshot and the replicated MP transaction have no concurrent primary key modifications, then it is determined that there are no conflicting transactions.

[0074] The global MP coordinator is responsible for collecting all units of work with the same "transaction ID" from different producer partitions. Once the coordinator has collected all units of work for a complete MP transaction, it recombines the data changes within these units and then initiates a corresponding new distributed transaction on the consumer database cluster, atomically applying all changes at once. Through the coordinator's intervention, the execution order of multi-partition transactions on the consumer database cluster is ensured to be consistent with that on the producer database cluster, maintaining end-to-end atomicity. Specifically, after receiving all units of work, the global MP coordinator does not directly execute the SQL; instead, it parses out the "change intentions" (e.g., Row-level Change Sets) for each partition. The global MP coordinator encapsulates these intentions within a distributed transaction, with itself acting as the "transaction manager."

[0075] The new distributed transaction refers to a local distributed transaction initiated by the global MP coordinator on the target (consumer) cluster. Its "correspondence" is reflected in two aspects: Corresponding data changes: The operation content (add, delete, modify) of this transaction is completely consistent with the original MP transaction committed by the producer database cluster, that is, the same modification is performed on records with the same primary key.

[0076] Semantic consistency correspondence: The execution of this transaction in the consumer database cluster needs to reproduce the atomicity (all operations either all succeed or all fail) and isolation (from the perspective of the consumer database cluster, this replication transaction should take effect as an indivisible unit).

[0077] In one embodiment, the global MP coordinator creates a transaction aggregation queue using the global transaction ID as the unique key; and continuously receives work units reported by all associated partitions, waiting for full collection; before all work units are collected, it continues to wait and does not trigger subsequent processes.

[0078] It should be noted that the transaction aggregation queue can be a queue in the coordinator's memory used to temporarily store all work units of the same MP transaction; full collection means receiving all work units of the MP transaction involved in the producer database cluster, ensuring no omissions or gaps.

[0079] The global MP coordinator can parse the data changes of all work units, restore the complete operations (INSERT, UPDATE, DELETE) of the producer database cluster transactions, eliminate duplicate changes, merge operations with the same primary key, and generate consumer change intentions; it records the local sequence number of the producer database cluster transactions to ensure that the execution order is consistent with the execution order of the distributed transactions corresponding to the producer database cluster.

[0080] It should be noted that the data changes within a work unit include: the table name, primary key, field values ​​before or after the change, and operation type stored within the work unit. The consumer change intent can be a standardized data operation instruction restructured by the coordinator and executable within the consumer database cluster. The local sequence number can be a monotonically increasing sequence number assigned to a transaction by a partition in the producer database cluster, used to ensure the execution order within the partition.

[0081] The global MP coordinator can initiate a new local distributed transaction in the consumer database cluster based on the consumer's change intent. This new transaction corresponds completely to the transaction in the producer database cluster (data consistency, semantic consistency, and atomicity consistency). The new transaction is then bound to the global transaction ID and marked as a replicative MP transaction.

[0082] It should be noted that the new distributed transaction is a multi-partition transaction local to the consumer database cluster, which completely replicates the operation of the producer database cluster; the replication-type MP transaction is a distributed transaction triggered by cross-cluster replication, rather than by local business.

[0083] In one embodiment, the global MP coordinator can extract the set of all primary keys involved in the current transaction from the consumer's change intent. This set of primary keys can trigger a batch conflict pre-check, a mandatory verification step before the replication transaction commits. The primary key set can be a list of unique identifiers (primary keys) for all data records involved in the current transaction. The batch conflict pre-check can check all primary keys for local concurrent modifications at once, rather than checking each row individually.

[0084] The global MP coordinator can request the current data version corresponding to the primary key set from the consumer database cluster storage engine; generate a version snapshot, bind it to the replication transaction context to be committed, and use it as a pre-detection credential; it can also record the logical timestamp or version number of the version snapshot for subsequent verification. The version snapshot can be a snapshot of the local data state at the pre-detection time, used to determine whether it has been modified after the pre-detection. The logical timestamp is a microsecond-level timestamp used for conflict resolution and version comparison. The pre-detection credential can be a version snapshot and a timestamp, bound to the transaction to prevent time window vulnerabilities.

[0085] The global MP coordinator can compare the changes of a replication transaction with the local version snapshot. If there are no concurrent modifications to the same primary key, the pre-check is considered successful and there is no conflict. Conversely, if there are concurrent modifications to the same primary key, a conflict is identified, and the conflict type can be determined.

[0086] It should be noted that concurrent modification refers to local business transactions and cross-cluster replication transactions performing write operations on the same primary key within a short time window; the conflict window can be a short time range defined by the system to determine whether there is a concurrent conflict.

[0087] S13. If a conflicting transaction is identified, the conflicting transaction is adjusted according to its timestamp or priority to eliminate the conflict.

[0088] In one embodiment, if conflicting transactions are identified, the timestamps or priorities of the two conflicting transactions can be determined, and then the two conflicting transactions can be adjusted according to their timestamps or priorities to eliminate the conflict. By eliminating the conflict, eventual data consistency can be guaranteed.

[0089] In one embodiment, adjusting conflicting transactions based on their timestamps or priorities may include the following sub-steps: S131. Determine the conflict type of the conflicting transaction, wherein the conflict type includes two-party update conflict, update-delete conflict, and two-party insertion conflict.

[0090] S132. If the conflict type is a two-way update conflict, then based on the comparison result of the modification operation timestamps of the two conflicting transactions, one of the two conflicting events is determined as the target event, and the update processing of the target event is performed.

[0091] S133. If the conflict type is an update / delete conflict, then based on the comparison result of the modification operation priorities of the two conflicting transactions, one of the two conflicting events is determined as the target event, and the update processing of the target event is performed.

[0092] S134. If the conflict type is a two-way insertion conflict, then based on the comparison result of the insertion operation timestamps of the two conflicting transactions, one of the two conflicting events is determined as the target event, and the update processing of the target event is performed.

[0093] In one embodiment, the global MP coordinator can accurately identify three conflict types based on operation type: 1. Conflict between two parties: Both parties are performing UPDATE operations, meaning that different or the same fields of the same primary key are modified by two transactions. 2. Update / delete conflict: One party performs an UPDATE operation, and the other performs a DELETE operation, meaning that one primary key is modified and the other is deleted; 3. Insertion conflict between two parties: Both parties are performing INSERT operations (duplicate primary key), that is, different transactions generate the same primary key and perform insertion.

[0094] It should be noted that all tables participating in XDCR can be required in advance to define a primary key, which is considered a unique identifier for a record.

[0095] When a consumer database cluster applies a change log entry from a peer cluster (whether it's an INSERT, UPDATE, or DELETE), the global MP coordinator checks if the operation conflicts with local data. A conflict is defined as concurrent modifications to records with the same primary key within a very short time window.

[0096] Once a conflict is detected, automatic resolution logic may be triggered. The specific steps are as follows: If the conflict type is a two-way update conflict, the timestamps (accurate to microseconds) of the two conflicting modification operations can be compared. The complete record of the version with the later timestamp is retained. For example, if cluster A's update time is T1 and cluster B's is T2, if T2 > T1, then the changes from cluster B are applied, overwriting the changes from cluster A. This ensures that the states of both clusters eventually converge to the same newer version. Optionally, the change fields from cluster B and cluster A can be merged to eliminate conflicts; the specific approach can be adjusted according to actual needs.

[0097] If the conflict type is an update-delete conflict, the "delete" operation has higher priority. If one cluster deletes a record and another cluster modifies it, the end result is that the record is deleted on both clusters. This ensures data consistency and prevents "zombie data." In other words, the "delete" operation is pre-defined as having higher priority, and the operation to be performed is determined based on this priority.

[0098] If the conflict type is a two-way insertion conflict, then the timestamp decision is also applied. The insertion operation with the earlier timestamp is retained, and the later insertion is rejected.

[0099] Optionally, all detected conflict events, along with the automated resolution measures taken, are logged in detail in a dedicated "Export Table Log". This log can be configured to be written to a disk file, sent to a Kafka message queue, or written to another database table for auditing and analysis by developers and DBAs.

[0100] Since the partition nodes of the consumer database cluster receive Binlog streams from the XDCR channel, they immediately suspend the processing and execution of all subsequent ordinary Binlogs for that partition. After resolving the conflict, in order to resume execution, in one embodiment, after the step of adjusting the conflicting transactions according to their timestamps or priorities to resolve the conflict, the method may further include the following sub-steps: S14. Send a pre-commit instruction to the target partition of the consumer database cluster so that each target partition locks an exclusive lock on the row records involved in the transaction, wherein the target partition is the partition in the consumer database cluster where the data change transaction is performed.

[0101] S15. After receiving the pre-commit result from each target partition, send a recovery command to each target partition to restore normal Binlog stream processing for each target partition.

[0102] After completing conflict detection, the global MP coordinator can send a 2PC pre-commit instruction to all affected target partitions. 2PC (Two-Phase Commit) is a distributed transaction atomicity guarantee protocol, and this scheme is a variant of 2PC. The pre-commit instruction can be the first-phase instruction issued by the coordinator, requiring the partition to lock data and record logs, without final commit.

[0103] After receiving a pre-commit instruction, the partition nodes of the consumer database cluster can lock exclusive locks on the row records involved in the transaction; simultaneously, they can record Undo or Redo logs for rollback or commit. The exclusive lock is a row-level lock, preventing other transactions from modifying the current data and ensuring transaction isolation; the Undo or Redo log can be a database transaction log, used for rollback in case of failure or for persistence after commit.

[0104] Partition nodes in the consumer database cluster can return a pre-commit ready or failed status to the coordinator. The global MP coordinator collects the pre-commit results for all partitions, including: all ready and any failed.

[0105] If everything is ready, the global MP coordinator can issue a global commit command to the partition nodes of the consumer database cluster data; conversely, if any one fails, the global MP coordinator can issue a global rollback command to the partition nodes of the consumer database cluster data.

[0106] If it's a global commit command, all partitions' data changes are persisted at once; if it's a global rollback command, all partitions' changes are reversed, and locks are released. Specifically, a global commit means the distributed transaction finally takes effect, and all partition data changes are persisted. A global rollback means the distributed transaction fails, and all partitions are restored to their state before the transaction was executed.

[0107] Once the global MP coordinator has committed or rolled back, it sends recovery commands to all paused target partitions. After receiving the instruction, the partition node of the consumer database cluster resumes normal Binlog stream processing. The resumption instruction can be a control instruction issued by the global MP coordinator to release the Binlog pause state.

[0108] It should be noted that in variant applications of two-phase commit (2PC), it is mainly divided into two phases, as follows: 1. Preparation phase: The global MP coordinator sends a "pre-commit" instruction to all involved target partitions. Each partition locks the corresponding data rows and records Undo / Redo logs, but does not perform the final commit.

[0109] 2. Confirmation Phase: Once all partitions report "Ready," the global MP coordinator issues a "Global Commit" command. If any partition reports failure (e.g., lock conflicts or constraint violations), the global MP coordinator issues a "Global Rollback" command to ensure that the data state of the consumer database cluster remains completely consistent with that of the producer database cluster.

[0110] Order consistency guarantee: The global MP coordinator maintains a "transaction sequence number queue" to ensure that the execution order of all RDTs in the consumer database cluster is strictly consistent with the commit order of the producer database cluster, thereby avoiding logical errors caused by network out-of-order delivery.

[0111] After the application is successfully applied, the global MP coordinator notifies all paused partitions that they can continue processing subsequent Binlog streams.

[0112] It should be noted that the logical relationship between atomic replication of distributed transactions and automatic detection and resolution of data conflicts in the two database clusters is "serial dependency" and "nested verification".

[0113] The process of replicating change unit information sent by the producer database cluster to the consumer database cluster is fundamental, while conflict detection by the global MP coordinator in the consumer database cluster ensures this. Within the consumer database cluster, atomic replication of distributed transactions must precede conflict detection.

[0114] If atomic reassembly is not performed first, and conflict detection is performed directly on the fragmented Binlog, the detection logic will be based on incomplete data state, which will lead to misjudgment (for example: a transaction contains modifications to two partitions, A and B. If only A is checked, it may be judged as a conflict, but if the modification of B is combined, it may be a valid compound operation).

[0115] The nested validation mechanism is as follows: Atomicity reorganization phase: The global MP coordinator reorganizes fragmented units of work into complete transaction contexts.

[0116] Conflict pre-check phase: Before the reorganized transaction is officially committed to the local storage engine, the system will extract all primary key sets involved in the transaction and perform a "batch conflict pre-check" with the current local state.

[0117] Atomic commit phase: Only transactions that pass the preflight check are atomically written to the local database. If the preflight check fails, a conflict resolution strategy is triggered, and the corrected data packet re-enters the atomic commit process.

[0118] In addition, the time point for conflict pre-check is "before commit after reorganization", but there is a "time window vulnerability" after pre-check and before global commit. For example, other concurrent transactions in the local cluster may modify the same primary key data (phantom read), causing the pre-check result to fail.

[0119] To address this situation, the present invention provides the following solution: 1. Version snapshot binding during the pre-inspection phase.

[0120] When the global MP coordinator performs a "batch conflict pre-check", the system not only extracts the set of primary keys involved in the transaction, but also reads the current version number or logical timestamp corresponding to these primary keys, and binds the version snapshot as a "pre-check credential" to the transaction context to be committed.

[0121] 2. Version verification and atomic locking during the commit phase Upon entering the "atomic commit phase," the system does not directly perform a write operation, but instead executes the following sequence of atomic operations: Row-level version verification: When acquiring a row lock, the database engine forcibly verifies whether the actual version number of the current record is consistent with the version number in the "pre-check credential".

[0122] The specific processing logic is as follows: If the versions are the same: This means that no concurrent transactions modified the record locally during the period from pre-check to commit, and the system immediately executes the commit and releases the lock.

[0123] If the versions are inconsistent (phantom read detected): This indicates that other transactions have modified the data locally within the time window following the preflight check. In this case, the system automatically triggers the "transaction reentry" process.

[0124] 3. Transaction reentrancy and adaptive conflict handling When a version mismatch is detected, the system performs the following steps instead of directly reporting an error and rolling back: Step 1: Context refresh: The coordinator discards the current preflight results and rereads the latest data state of the primary key set.

[0125] Step 2: Secondary Conflict Resolution: The system will perform a second conflict detection between the "Changes to be Replicated Transaction" and the "Latest Local Data Status".

[0126] If the conflict can still be resolved by a preset strategy (such as timestamp comparison), the system will dynamically adjust the change set of the transaction to be committed based on the latest data status (e.g., only update fields that have not been covered, or decide whether to cover them based on timestamps).

[0127] If a conflict cannot be resolved automatically (e.g., due to a violation of business logic constraints), the transaction is marked as an "abnormal conflict" and transferred to the "Export Table Log" for manual auditing. At the same time, the transaction is rolled back to prevent dirty data from being written.

[0128] Step 3: Cyclic Commit: The corrected transaction change package re-enters the "atomic commit phase" until the version verification passes or the maximum number of retries is reached.

[0129] This invention ensures that atomic operations in the producer database cluster are also atomic in the consumer database cluster through the aggregation and reorganization of work units, maintaining strict transaction consistency. The serialized execution of transactions within a single partition, combined with the role of the global MP coordinator, further enhances transaction reliability and sequential consistency, avoiding potential inconsistencies at the partition level and across partition levels.

[0130] In the event of a conflict, adjusting conflicting transactions based on timestamps or priorities provides an automatic conflict resolution solution that ensures eventual data consistency and avoids the data loss problem of simple LWW strategies.

[0131] After conflict resolution, detailed conflict logs ensure that every conflict and its resolution is traceable. Furthermore, the conflict resolution logic can be designed as a pluggable module, allowing users to customize more complex resolution strategies based on specific business needs.

[0132] The above mechanism provides a solid technical foundation for building a highly reliable and data-consistent Active-Active database architecture, ensuring that business operations can be smoothly switched in the event of a disaster, with an RPO (Recovery Point Objective) close to zero, achieving true multi-site active-active architecture.

[0133] In one mode of operation, the present invention can be applied in the following embodiments: Example 1: Order processing on a cross-border e-commerce platform.

[0134] A multinational e-commerce platform has deployed an Active-Active database cluster in both Europe (EU) and Asia (AS).

[0135] Scenario 1: Distributed transaction replication.

[0136] A European user places an order for one item from a German warehouse and one item from a French warehouse. This order operation is a distributed transaction because it requires: Reduce inventory in partition P_DE (German warehouse).

[0137] Reduce inventory in partition P_FR (French warehouse).

[0138] Create a new order record in partition P_ORDER (orders).

[0139] After the MP transaction is committed in the EU cluster, each of the three partitions, P_DE, P_FR, and P_ORDER, generates a work unit with the same transaction ID (e.g., MP_TXN_555) and sends it to the AS cluster along with the Binlog stream. Within the EU cluster, each partition (e.g., P_DE) ensures that transactions are executed serially to guarantee the atomicity of inventory deduction; the global MP coordinator coordinates the operations of these partitions to ensure the complete commit of the entire order transaction.

[0140] After receiving these three work units, the global MP coordinator of the AS cluster waits for them all to arrive. As the core coordinator, it verifies the integrity of all work units and initiates a new MP transaction on the AS cluster, atomically deducting inventory and creating an order in the corresponding partition of the AS cluster.

[0141] Once all items are collected, the coordinator initiates a new MP transaction on the AS cluster, atomically deducting the inventory and creating an order in the corresponding partition of the AS cluster.

[0142] Result: This ensured that the data state of this complex order operation was completely consistent across both clusters.

[0143] Scenario 2: Conflict resolution.

[0144] A user with UserID: 888 has a copy of their account information in both the EU and AS clusters.

[0145] Concurrent modifications occurred: T1 (10:00:00.123456 UTC): In the EU cluster, customer service upgraded the user's membership level from "Silver" to "Gold".

[0146] T2 (10:00:00.123500 UTC): In the AS cluster, the user logged into the system and changed his / her shipping address.

[0147] Conflict Detection and Resolution: The change (upgraded membership) log from the EU cluster has reached the AS cluster. The AS cluster detected that the UserID: 888 record was just modified locally at time T2, which is an update-update conflict.

[0148] The AS cluster's conflict resolution module compared timestamps: T2 > T1. Therefore, the AS cluster decided to retain its local changes (new address) and accept the EU cluster's changes (new membership level), merging the two. The final record for UserID: 888 contains the new membership level and the new address.

[0149] Similarly, the change (address change) logs from the AS cluster reach the EU cluster. The EU cluster performs the same comparison and arrives at the same conclusion.

[0150] Eventual consistency: After a brief conflict resolution process, the record for UserID: 888 on both clusters will eventually converge to the same state: both a "Gold" member and using the new shipping address. Simultaneously, this conflict and its resolution are logged for subsequent auditing.

[0151] Example 2: Multi-partition transaction replication in a financial transfer system.

[0152] In an Active-Active deployment of a global financial services platform, two database clusters were deployed in New York (NY) and London (LN) to handle cross-time zone transfers.

[0153] Scenario: Distributed transfer transactions.

[0154] User A initiates an international transfer in the NY cluster: $100 is deducted from their USD account (partition P_USD_A), and the equivalent amount of Euros (approximately 90 Euros) is deposited into their corresponding Euro account in the LN cluster (partition P_EUR_B, user B's account). This is a cross-cluster, multi-partition transaction that requires atomic execution to prevent fund loss.

[0155] Upon commit to the NY cluster, each partition generates a unit of work with a unique transaction ID (e.g., MP_TXN_789). Partition P_USD_A ensures internal transaction serialization, avoiding conflicts with other deduction operations. The global MP coordinator coordinates these units of work and replicates them to the LN cluster via a Binlog stream.

[0156] After the global MP coordinator of the LN cluster gathers all the work units, it initiates a new transaction: atomically depositing in the P_EUR_B partition while simultaneously updating the transaction log partition (P_LOG). If coordination fails, the entire transaction is rolled back to ensure that no funds are transferred.

[0157] Beneficial effects: In financial scenarios, this mechanism ensures the atomicity and consistency of transfers, prevents fund mismatch issues caused by network latency, and supports real-time global transactions.

[0158] Example 3: User content synchronization and conflict resolution on social media platforms.

[0159] A social media platform has deployed Active-Active clusters in Silicon Valley (SV) and Tokyo (TK) for the global synchronization of user-generated content.

[0160] Scenario: Conflict in concurrent content editing.

[0161] User U edits their profile photo in the SV cluster (update operation, timestamp T1), while simultaneously adding a new post in the TK cluster (insert operation, involving partition P_USER_U with the same user ID, timestamp T2>T1).

[0162] When the update log from the SV cluster reaches the TK cluster, an insert-update conflict (same primary key) is detected. The system uses a timestamp rule: retaining earlier updates (photos) and merging later inserts (posts) to ensure the integrity of user data.

[0163] The global MP coordinator ensures atomic replication for any post publishing transaction involving multiple partitions (such as updating user profiles + post partitions). Within a single partition, all edit operations are executed serially on the post partition, avoiding partial overwriting.

[0164] Beneficial effects: In this scenario, the system automatically resolves conflicts, maintains a consistent user experience, and supports concurrent editing across multiple regions without losing any content changes. Conflict logs can be used to analyze user behavior patterns.

[0165] In this embodiment, the present invention provides a conflict resolution method for distributed databases. Its advantages are as follows: The present invention can obtain consumer update information fed back by the consumer database cluster. This consumer update information is extracted from the change unit information when the consumer database cluster triggers cross-datacenter replication based on the change unit information sent by the producer database cluster. A replication-type MP transaction is generated based on the consumer update information, and the existence of a transaction conflict is determined based on the primary key version snapshot corresponding to the replication-type MP transaction and the consumer update information. If a conflicting transaction is determined, it is adjusted according to the timestamp or priority of the conflicting transaction to eliminate the conflict. The present invention can perform conflict detection based on the change unit information of data changes when two database clusters are replicating across data centers, and adjust the transaction based on the timestamp or priority when a conflict occurs to eliminate the conflict. On the one hand, this can avoid data discrepancies between the two database clusters due to conflicts, ensuring data consistency between the two clusters and improving data accuracy. On the other hand, it can also avoid the loss of updated data in one cluster due to conflicts.

[0166] This invention also provides a conflict handling device for a distributed database, see [link to relevant documentation]. Figure 2 The diagram shows a schematic representation of a conflict resolution device for a distributed database according to an embodiment of the present invention.

[0167] As an example, the conflict handling device for the distributed database may include: The acquisition module 201 is used to acquire consumption update information fed back by the consumer database cluster, wherein the consumption update information is information extracted from the change unit information when the consumer database cluster triggers cross-data center replication based on the change unit information sent by the producer database cluster. The conflict detection module 202 is used to generate a replicated MP transaction based on the consumption update information, and determine whether there is a transaction conflict based on the primary key version snapshot corresponding to the replicated MP transaction and the consumption update information. The conflict adjustment module 203 is used to adjust the conflicting transactions according to their timestamps or priorities if a conflicting transaction is determined to exist, so as to eliminate the conflicting transaction.

[0168] Optionally, the step of generating a replicated MP transaction based on the consumption update information and determining whether a transaction conflict exists based on the version snapshot corresponding to the replicated MP transaction and the consumption update information includes: Extract the global transaction ID from the consumer update information, and after receiving the work units reported by all associated partitions in the consumer database cluster, parse the data change content of the work unit and generate a consumer change intention that is consistent with the distributed transaction execution order corresponding to the change unit information; After binding the global transaction ID and the consumer change intent, a local distributed transaction is generated for the consumer database cluster to obtain a replicated MP transaction; Extract all primary key sets of the distributed transactions corresponding to the change unit information from the consumer change intent, request the storage engine of the consumer database cluster to read the current data version corresponding to the primary key set and generate the corresponding version snapshot; If it is determined that the version snapshot and the replicated MP transaction have concurrent primary key modifications, then a conflicting transaction is identified. If it is determined that the version snapshot and the replicated MP transaction do not have concurrent primary key modifications, then it is determined that there are no conflicting transactions.

[0169] Optionally, adjusting conflicting transactions based on their timestamps or priorities includes: Determine the conflict type of the conflicting transaction, wherein the conflict type includes two-party update conflict, update-delete conflict, and two-party insertion conflict; If the conflict type is a two-way update conflict, then based on the comparison result of the modification operation timestamps of the two conflicting transactions, one of the two conflicting events is determined as the target event, and the update processing of the target event is performed. If the conflict type is an update / delete conflict, then based on the comparison result of the modification operation priorities of the two conflicting transactions, one of the two conflicting events is determined as the target event, and the update processing of the target event is performed. If the conflict type is a two-way insertion conflict, then based on the comparison result of the insertion operation timestamps of the two conflicting transactions, one of the two conflicting events is determined as the target event, and the update processing of the target event is performed.

[0170] Optionally, the operation of the producer database cluster sending change unit information includes: After receiving a distributed transaction, the producer database cluster generates Binlog information and working units in the partition corresponding to the distributed transaction. The working unit contains a globally unique transaction ID and the change data of the partition in which it is located. The producer database cluster inserts the work unit into the Binlog information to generate change unit information, and sends the change unit information to the consumer database cluster.

[0171] Optionally, the operation of the consumer database cluster feeding back consumption update information includes: After the consumer database cluster identifies the work unit with the distributed transaction tag from the change unit information, it suspends the Binlog processing and execution of the partition corresponding to the distributed transaction and temporarily stores the work unit in the local partition cache. The consumer database cluster extracts the global transaction ID, partition identifier, and data change list from the working unit, packages the global transaction ID, partition identifier, and data change list into consumer update information, and sends it.

[0172] Optionally, the device further includes: The sending module is used to send a pre-commit instruction to the target partition of the consumer database cluster after the step of adjusting the conflicting transactions according to the timestamp or priority of the conflicting transactions to eliminate the conflicting transactions, so that each target partition locks the row record exclusive lock involved in the transaction, wherein the target partition is the partition in the consumer database cluster where the data change transaction is performed. The recovery module is used to send a recovery command to each target partition after receiving the pre-commit result from each target partition, so that each target partition can resume normal Binlog stream processing.

[0173] This invention also provides a conflict resolution system for distributed databases, see [link to relevant documentation]. Figure 3 The diagram shows a schematic representation of a conflict resolution system for a distributed database according to an embodiment of the present invention.

[0174] As an example, the conflict resolution system of the distributed database may include: a producer database cluster, a global MP coordinator, and a consumer database cluster. The producer database cluster is connected to the consumer database cluster, and the global MP coordinator is set in the consumer database cluster. The global MP coordinator executes the conflict resolution method for distributed databases as described in the above embodiments.

[0175] A global MP coordinator is located on the consumer database cluster side. As the core coordinator for multi-partition transactions, this global MP coordinator is responsible for supervising and coordinating operations across partitions, ensuring the atomicity and consistency of the entire distributed transaction. It acts as a central hub, preventing isolated execution of operations across partitions, thereby avoiding system inconsistencies caused by partial commits.

[0176] Those skilled in the art will understand that, for ease of description and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0177] Furthermore, this application also provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the conflict resolution method for a distributed database as described in the above embodiments.

[0178] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a computer-executable program for causing a computer to execute the conflict resolution method for a distributed database as described in the above embodiments.

[0179] In the description of the embodiments of the present invention, it should be noted that the terms "above," "below," etc., indicating the orientation or positional relationship are based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing the embodiments of the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention. When an element such as a layer, region, or substrate is referred to as being "above" or "on top of" another element, it may be directly on the other element, or there may be an intermediate element. Conversely, when an element is referred to as being "directly on" or "above" another element, there is no intermediate element. It should also be understood that when an element is referred to as being "below" or "under" another element, it may be directly below or under the other element, or there may be an intermediate element. Conversely, when an element is referred to as being "directly below" or "under" another element, there is no intermediate element. Unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0180] Those skilled in the art will understand that embodiments of this application may also include computer program products. Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0181] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), devices, and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0182] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0183] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0184] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A conflict resolution method for a distributed database, characterized in that, The method includes: Obtain consumption update information fed back by the consumer database cluster, wherein the consumption update information is information extracted from the change unit information when the consumer database cluster triggers cross-data center replication based on the change unit information sent by the producer database cluster; A replicating MP transaction is generated based on the consumption update information, and a transaction conflict is determined based on the primary key version snapshot corresponding to the replicating MP transaction and the consumption update information. If a conflicting transaction is identified, it is adjusted based on the timestamp or priority of the conflicting transaction to eliminate the conflict.

2. The conflict resolution method for distributed databases according to claim 1, characterized in that, The step of generating a replicated MP transaction based on the consumption update information and determining whether a transaction conflict exists based on the version snapshot corresponding to the replicated MP transaction and the consumption update information includes: Extract the global transaction ID from the consumer update information, and after receiving the work units reported by all associated partitions in the consumer database cluster, parse the data change content of the work unit and generate a consumer change intention that is consistent with the distributed transaction execution order corresponding to the change unit information; After binding the global transaction ID and the consumer change intent, a local distributed transaction is generated for the consumer database cluster to obtain a replicated MP transaction; Extract all primary key sets of the distributed transactions corresponding to the change unit information from the consumer change intent, request the storage engine of the consumer database cluster to read the current data version corresponding to the primary key set and generate the corresponding version snapshot; If it is determined that the version snapshot and the replicated MP transaction have concurrent primary key modifications, then a conflicting transaction is identified. If it is determined that the version snapshot and the replicated MP transaction do not have concurrent primary key modifications, then it is determined that there are no conflicting transactions.

3. The conflict resolution method for distributed databases according to claim 1, characterized in that, The adjustment of conflicting transactions based on their timestamps or priorities includes: Determine the conflict type of the conflicting transaction, wherein the conflict type includes two-party update conflict, update-delete conflict, and two-party insertion conflict; If the conflict type is a two-way update conflict, then based on the comparison result of the modification operation timestamps of the two conflicting transactions, one of the two conflicting events is determined as the target event, and the update processing of the target event is performed. If the conflict type is an update / delete conflict, then based on the comparison result of the modification operation priorities of the two conflicting transactions, one of the two conflicting events is determined as the target event, and the update processing of the target event is performed. If the conflict type is a two-way insertion conflict, then based on the comparison result of the insertion operation timestamps of the two conflicting transactions, one of the two conflicting events is determined as the target event, and the update processing of the target event is performed.

4. The conflict resolution method for distributed databases according to claim 1, characterized in that, The operation of sending change unit information by the producer database cluster includes: After receiving a distributed transaction, the producer database cluster generates Binlog information and working units in the partition corresponding to the distributed transaction. The working unit contains a globally unique transaction ID and the change data of the partition in which it is located. The producer database cluster inserts the work unit into the Binlog information to generate change unit information, and sends the change unit information to the consumer database cluster.

5. The conflict resolution method for distributed databases according to claim 4, characterized in that, The operation of the consumer database cluster to feed back consumption update information includes: After the consumer database cluster identifies the work unit with the distributed transaction tag from the change unit information, it suspends the Binlog processing and execution of the partition corresponding to the distributed transaction and temporarily stores the work unit in the local partition cache. The consumer database cluster extracts the global transaction ID, partition identifier, and data change list from the working unit, packages the global transaction ID, partition identifier, and data change list into consumer update information, and sends it.

6. The conflict resolution method for a distributed database according to any one of claims 1-5, characterized in that, After the step of adjusting conflicting transactions based on their timestamps or priorities to eliminate them, the method further includes: A pre-commit instruction is sent to the target partition of the consumer database cluster to lock an exclusive lock on the row records involved in the transaction in each target partition, wherein the target partition is the partition in the consumer database cluster where the data change transaction is performed; After receiving the pre-commit result from each target partition, a recovery command is sent to each target partition to enable each target partition to resume normal Binlog stream processing.

7. A conflict handling device for a distributed database, characterized in that, The device includes: The acquisition module is used to acquire consumption update information fed back by the consumer database cluster, wherein the consumption update information is information extracted from the change unit information when the consumer database cluster triggers cross-data center replication based on the change unit information sent by the producer database cluster. The conflict detection module is used to generate a replicated MP transaction based on the consumption update information, and to determine whether there is a transaction conflict based on the primary key version snapshot corresponding to the replicated MP transaction and the consumption update information. The conflict adjustment module is used to adjust conflicting transactions based on their timestamps or priorities to eliminate them if conflicting transactions are identified.

8. A conflict resolution system for a distributed database, characterized in that, The system includes: a producer database cluster, a global MP coordinator, and a consumer database cluster; The producer database cluster is connected to the consumer database cluster, and the global MP coordinator is set in the consumer database cluster. The global MP coordinator executes the conflict resolution method for distributed databases as described in any one of claims 1-6.

9. An electronic device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, when the processor executes the program, it implements a conflict resolution method for a distributed database as described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the conflict resolution method for a distributed database as described in any one of claims 1-6.

Images