Distributed dual-active database system and method across data centers

Abstract

The application discloses a kind of distributed double-live database systems and methods across data center, belong to a kind of distributed database application method, including two QianBase database instances in system, first database instance is located in first data center, second database instance is located in second data center;The first instance database is used by database transaction system when executing the write operation of external application, simultaneously read configuration information, with second instance database to establish peer database.For the current execution plan whether it has replication attribute by database transaction system, so that the granularity of data replication is more fine, to save bandwidth, improve the overall performance of system, and the system has complete double-live support, for different database instances between no longer distinguish between master and standby database, each instance can realize the operation of reading and writing, also can be automatically cached by system in fault condition to difference data, and data synchronization is carried out after fault recovery.

Description

Technical Field

[0001] This invention relates to a distributed database application method, and more specifically, to a distributed active-active database system and method spanning multiple data centers. Background Technology

[0002] Active-active distributed database systems are an important implementation method for high availability architecture, aiming to ensure business continuity. In traditional data centers, business system data is often stored in a single database. This type of data center carries certain business continuity risks. If the database fails and goes down, all business systems connected to that database will be interrupted, and data may even be lost.

[0003] At the database level, active-active solutions mainly include storage-based active-active technologies, database synchronous / asynchronous replication technologies, and multi-active approaches based on the Raft / Paxos consistency protocol. However, all three of these database active-active solutions have varying degrees of drawbacks. For example, storage-based active-active technologies, relying on specific storage hardware systems, lead to hardware dependency and vendor binding. Devices from different vendors have different array compositions and operating principles, resulting in incompatibility. This solution is highly hardware-dependent, and this physical replication often causes problems with data logical consistency; that is, to support active-active, the system must perform bidirectional replication, which many hardware vendors cannot support. Database synchronous / asynchronous replication technologies are essentially master-slave for the data itself. One instance is the master instance, providing data read and write services, while the slave instance often does not provide services, or at most provides read-only services. This is a severely limited active-active approach. The active-active approach based on the Raft / Paxos consensus protocol requires the Paxos / Raft replication protocol. While it can achieve true active-active functionality, it is essentially a data consistency replication protocol within a single database instance. Therefore, it is not active-active across two database instances. If some components of the system fail, causing instance-level problems, even if the data replicas are normal, active-active failover across multiple data centers is impossible because the entire instance becomes unavailable. Therefore, further research and improvement of active-active technologies for distributed databases are necessary. Summary of the Invention

[0004] One of the objectives of this invention is to address the shortcomings by providing a distributed active-active database system and method across data centers. This aims to solve the technical problems of existing active-active database technologies, such as hardware dependence, limited active-active applications, instance-level problems caused by system component failures, and the inability to achieve active-active switching across multiple data centers.

[0005] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0006] This invention provides a distributed active-active database system across data centers. The system includes two QianBase database instances: a first database instance located in a first data center and a second database instance located in a second data center. The first instance database is used by the database transaction system to simultaneously read configuration information and establish a peer database with the second instance database when executing write operations from external applications. The database transaction system synchronously writes the currently executed write operation to the second instance database. When executing a write operation, the database transaction system first determines whether the current execution plan has replication attributes. If the result is yes, it reads the configuration information and establishes a peer database with the second instance database; otherwise, it only executes the current write operation in the first instance database.

[0007] As a preferred further technical solution, the execution plan is generated by a database compiler. When generating the execution plan, the database compiler first identifies whether the current data table has the xdc attribute. If so, it generates an execution plan with the replication attribute.

[0008] A further technical solution is that the xdc attribute is key data that has been manually filtered and retained in the data table beforehand.

[0009] A further technical solution is that the peer-to-peer database uses IP address and port number as identifiers.

[0010] A further technical solution is that the database transaction system synchronously writes the currently executed write operation to the second instance database through the 2PC protocol.

[0011] A further technical solution is as follows: When the first instance database fails during system operation, the system automatically switches the currently working data center to the second data center where the second instance database is located. Then, the database transaction system caches the write operations in the execution plan with replication attributes in the first instance database, and the second instance database continues to provide read and write services to external applications.

[0012] Another aspect of the present invention provides a method for a distributed active-active database across data centers, the method comprising the following steps:

[0013] Step A: When the database transaction system executes write operations from external applications, it simultaneously reads configuration information to establish a peer database with the second instance database. The database transaction system then synchronously writes the currently executed write operations into the second instance database.

[0014] Step B: When the database transaction system performs a write operation, it first determines whether the current execution plan has the replication attribute. If the result is yes, it reads the configuration information and establishes a peer database with the second instance database; otherwise, it only performs the current write operation in the first instance database.

[0015] As a preferred embodiment, a further technical solution is: the method further includes step C, when the first instance database fails, automatically switching the currently working data center to the second data center where the second instance database is located, and then the database transaction system caches the data of the write operation in the execution plan with replication attributes in the first instance database, and the second instance database continues to provide read and write services to external applications.

[0016] A further technical solution is: the execution plan in step B is generated by a database compiler. When generating the execution plan, the database compiler first identifies whether the current data table has the xdc attribute. If so, it generates an execution plan with the replication attribute. The xdc attribute is key data that is manually filtered and retained in the data table beforehand.

[0017] A further technical solution is that the database transaction system synchronously writes the currently executed write operation to the second instance database through the 2PC protocol; the peer database is identified by its IP address and port number.

[0018] Compared with the prior art, one of the beneficial effects of the present invention is that by using a database transaction system to determine whether the current execution plan has replication attributes, the granularity of data replication is made more refined, thereby saving bandwidth and improving the overall performance of the system. In addition, the system has full dual-active support, and there is no longer a distinction between primary and backup databases between different database instances. Each instance can perform read and write operations. The system can also automatically cache the difference data in the event of a failure and synchronize the data after the failure is recovered. Attached Figure Description

[0019] Figure 1 This is a system deployment block diagram used to illustrate an embodiment of the present invention.

[0020] Figure 2 This is a typical application flowchart used to illustrate an embodiment of the present invention. Detailed Implementation

[0021] This invention relates to a system active-active technology based on the QianBase MPP database. QianBase MPP is a relational distributed database designed for data warehouse applications, boasting significant advantages in data storage, high concurrency, high availability, linear scalability, response speed, ease of use, and cost-effectiveness. Its database architecture comprises three layers: the client service layer, the SQL database service layer, and the storage engine layer. The first layer is the client service layer, where the application resides. Applications can be written by users or implemented using third-party ISV tools / solutions. The QianBase database service layer can be accessed using Windows or Linux client drivers provided by QianBase, through standard ODBC / JDBC interfaces. QianBase supports type2 JDBC, type4 JDBC, and ADO.NET drivers. The appropriate driver type can be selected based on specific requirements (response time, number of connections, security requirements, and other factors). The second layer is the SQL database engine layer. This layer includes all QianBase services, encapsulating all services for managing QianBase objects and efficiently executing SQL database requests. These services include connection management, SQL statement compilation and creation of optimal execution plans, SQL execution (serial and parallel), transaction management, and workload management. The third layer is the storage engine layer, which includes the standard Hadoop services (HDFS and Zookeeper) used by QianBase. QianBase objects are stored in a native Hadoop database structure, including HBase, cached text files, and key-value sequence files. QianBase processes SQL requests from applications and transparently translates these requests into the native interface calls required for the underlying data format. QianBase provides a relational schema abstraction on top of HBase, so it can support traditional relational database objects (tables, views, secondary indexes) using familiar DDL / DML syntax (object naming, column definitions, and data type support). Additionally, QianBase supports using native HBase and Hive tables as its external tables.

[0022] Based on the aforementioned QianBaseMPP database system, such as Figure 1 As shown, in Figure 1In the diagram, solid lines represent update (write) operations, and dashed lines represent read operations. Therefore, one embodiment of the present invention is a distributed active-active database system across data centers. In this system, the system includes two QianBase database instances, with the first database instance located in a first data center and the second database instance located in a second data center. The first and second data centers are generally deployed in different regions within the same city; that is, the system of the present invention is a synchronous active-active solution across data centers within the same city.

[0023] The first instance database is used by the database transaction system to read configuration information and establish a peer database with the second instance database when executing write operations from external applications. The database transaction system then synchronously writes the currently executing write operations into the second instance database. The aforementioned peer database is identified by its IP address and port number, and the database transaction system synchronously writes the currently executing write operations into the second instance database using the 2PC protocol (two-phase commit protocol).

[0024] More importantly, when performing a write operation, the database transaction system first determines whether the current execution plan has replication attributes. If the result is yes, it reads the configuration information and establishes a peer database with the second instance database; otherwise, it only performs the current write operation in the first instance database.

[0025] On the other hand, the aforementioned execution plan is generated by a database compiler. When generating the execution plan, the database compiler first identifies whether the current data table has the xdc attribute. If so, it generates an execution plan with the replication attribute. The aforementioned xdc attribute refers to key data that is manually filtered and retained in the data table beforehand.

[0026] Based on the system functions described above, the main idea behind QianBase Synchronous xDC is to treat multiple independent database instances deployed in different data centers as a single remote data copy. This is primarily achieved automatically through the configuration and operation of the database SQL engine, rather than through physical hardware or logical log transfers. In other words, during SQL execution, data is reliably written both locally and remotely.

[0027] First, XDC data replication is configured as an attribute of a database table, allowing administrators to set whether data synchronization is required at the table level. This enables administrators to finely control which critical data needs to be replicated and to remove unnecessary tables and data, thus conserving valuable network resources.

[0028] When a table has the `xdc` attribute, during insert, delete, and update operations on that table, the SQL compiler generates an execution plan with synchronous transaction replication attributes and informs the storage system. When the local database transaction system performs a write operation, if the execution plan has synchronous transaction replication attributes, it reads the configuration information to obtain the peer database's identifier. We use an IP address and port number to represent a peer database. The peer database's storage system is homogeneous with the local database's storage system, both using the same transaction protocol. Then, the transaction processor in the database transaction system adds the peer database's storage engine to the current transaction, executes the same write operations, and uniformly manages the transaction participants of the peer database engine using the two-phase commit protocol.

[0029] Such a write operation becomes a dual-write transaction controlled by the transaction manager in the database transaction system. That is, data is written to the local storage system and simultaneously to the storage system of the peer database instance. The peer database's storage system, as a participant in the distributed transaction, is coordinated by the transaction manager in the local database transaction system and participates in the two-phase commit protocol process, thereby achieving strong consistency replication of the data.

[0030] Let's take an example to examine how the database kernel ensures that data with an xdc attribute in a table can be synchronously replicated to another database instance in a peer data center.

[0031] by Figure 1 Taking the deployment topology in the example, we have two database instances located in two data centers. We use DC1 to represent the instance in data center DC1 and DC2 to represent the database instance in data center DC2.

[0032] To create the xdc attribute on table D1, the syntax is as follows:

[0033] Create table D1 (c1 int not null, c2 int ) attribute incrementalbackup;

[0034] In this way, when a modification operation is performed on table D1, the database engine will generate an execution plan with data assignment markers.

[0035] In the deployment configuration, DC1 is configured with DC2 as its peer database.

[0036] Now we initiate a write operation:

[0037] Update d1 set c2 = 0;

[0038] When this update statement is executed, the database will start a transaction, which is managed by the transaction manager.

[0039] The database compiler recognizes that table D1 has the xdc attribute, so the xdc attribute will be appended to the update operation on table d1 in the generated execution plan.

[0040] Specifically, such as Figure 2 As described above, when the executor performs an update operation with the xdc attribute, it notifies the transaction manager. The transaction manager reads the system configuration to obtain the IP address and port number of DC2. Then, it also uses DC2 as the target of the write operation and adds it to the current transaction.

[0041] Subsequently, the transaction manager coordinates the write operations of the local DC1 storage engine and the remote DC2 storage engine, respectively, and uses the 2PC protocol to ensure strong data consistency.

[0042] Database systems can experience two main types of failures during runtime: network failures and database instance failures. When a network failure occurs, write transactions on any database instance cannot be completed. This is because the two-phase commit protocol requires all participants to complete their work; however, due to network interruption, the database cannot communicate with remote participants (i.e., the storage engine) and cannot ascertain whether I / O operations have been completed. Therefore, the transaction manager will determine that the transaction should be rolled back. At this point, the business system will be interrupted. When a database instance failure occurs—if one of the two database instances in two data centers fails—the transaction manager will also be unable to complete the commit, exhibiting the same symptoms as the first type of failure.

[0043] Therefore, regardless of the type of failure, the entire system will stop serving. Once the database manager detects that all transactions have failed due to remote failures within a certain period (default 1 minute), it will automatically switch to a working data center and set its mode to cached mode. At this time, transaction management will cache all write operations on tables with the xdc attribute and will no longer attempt to include the storage engine of the peer database instance as a transaction participant, allowing the system to continue providing services.

[0044] Based on the above design concept, another embodiment of the present invention is a distributed active-active database method across data centers, which includes the following steps:

[0045] S1. When the database transaction system executes write operations from external applications, it simultaneously reads configuration information to establish a peer database with the second instance database. The database transaction system then synchronously writes the currently executed write operations into the second instance database.

[0046] In this step, the database transaction system described above synchronously writes the currently executed write operation to the second instance database through the 2PC protocol, and the peer database is identified by its IP address and port number.

[0047] S2. When the database transaction system performs a write operation, it first determines whether the current execution plan has the replication attribute. If the result is yes, it reads the configuration information and establishes a peer database with the second instance database; otherwise, it only performs the current write operation in the first instance database.

[0048] In this step, the execution plan is generated by the database compiler. When generating the execution plan, the database compiler first identifies whether the current data table has the xdc attribute. If so, it generates an execution plan with the replication attribute. The xdc attribute is key data that has been manually filtered and retained in the data table beforehand.

[0049] S3. When the first instance database fails, the current working data center is automatically switched to the second data center where the second instance database is located. Then, the database transaction system caches the write operations in the execution plan with replication attributes in the first instance database, and the second instance database continues to provide read and write services to external applications.

[0050] Based on the above embodiments, the present invention has the following characteristics:

[0051] First, the data replication granularity is fine, supporting table-level control. Traditional data replication technologies operate at the overall database level, unable to precisely control the replication needs of data at different importance levels. This technology can precisely control which data needs to be replicated and which does not, thereby saving bandwidth and improving overall system performance.

[0052] Secondly, it provides full active-active support, not just read-only support. The key to a multi-active architecture is that systems in different geographical locations can provide business services; "active" here means providing services in real time. The opposite of "active" is "backup," which normally doesn't provide services externally. If services need to be provided, significant manual intervention and operation are required, taking considerable time to make the "backup" active. The technology of this invention achieves true, fully active-active support, not just primary / backup.

[0053] Third, automatic fault recovery addresses failures caused by various hardware, software, or human errors in real production environments. Network failures between two data centers, or a serious failure in one of the two data center instances, can prevent data synchronization. The technology of this invention can automatically cache discrepancies in fault conditions and automatically resynchronize data after fault recovery.

[0054] Compared to storage replication-based solutions, which are hardware-dependent and incompatible with specific hardware, this solution is a software-based solution, avoiding hardware limitations. Unlike synchronous / asynchronous database replication solutions, which only provide read / write services and either do not offer full access, this invention provides true active-active functionality. Furthermore, Paxos / Raft replication-based solutions, which are essentially storage-layer replicas where only one cluster provides full read / write services while the other provides only read-only services, offer true active-active functionality. Paxos / Raft replication solutions, which are essentially storage-layer replicas where the two data centers form a single large database cluster rather than two independent database instances, cause both data centers to lose service in the event of a database instance failure. This invention, however, maintains two independent database clusters, ensuring that no single point of failure at the database instance level will cause service interruption because the other cluster is a separate, independently running database instance.

[0055] In addition to the above, it should be noted that the terms "one embodiment," "another embodiment," and "embodiment" used in this specification refer to specific features, structures, or characteristics described in connection with that embodiment, which are included in at least one embodiment described in the general description of this application. The appearance of the same expression in multiple places in the specification does not necessarily refer to the same embodiment. Furthermore, when a specific feature, structure, or characteristic is described in connection with any embodiment, the intention is to suggest that implementing such a feature, structure, or characteristic in conjunction with other embodiments also falls within the scope of this invention.

[0056] Although the invention has been described herein with reference to several illustrative embodiments, it should be understood that many other modifications and implementations can be devised by those skilled in the art, which will fall within the scope and spirit of the principles disclosed herein. More specifically, various variations and modifications can be made to the components and / or layout of the subject matter arrangement within the scope of the disclosure, drawings, and claims. Besides variations and modifications to the components and / or layout, other uses will be apparent to those skilled in the art.

Claims

1. A distributed active-active database system spanning multiple data centers, characterized in that... The system includes two QianBase instance databases, wherein: The first instance database is located in the first data center, and the second instance database is located in the second data center; The first instance database is used by the database transaction system to read configuration information and establish a peer database with the second instance database when executing write operations of external applications. The database transaction system synchronously writes the currently executed write operations into the second instance database. When a database transaction system performs a write operation, it first determines whether the current execution plan has replication attributes. If the result is yes, it reads the configuration information and establishes a peer database with the second instance database; otherwise, it only performs the current write operation in the first instance database. The execution plan is generated by the database compiler. When generating the execution plan, the database compiler first identifies whether the current data table has the xdc attribute. If so, it generates an execution plan with the replication attribute. The xdc attribute is key data that is manually filtered and retained in the data table beforehand.

2. The distributed active-active database system across data centers according to claim 1, characterized in that: The peer-to-peer database is identified by its IP address and port number.

3. The distributed active-active database system across data centers according to claim 1, characterized in that: The database transaction system synchronously writes the currently executing write operation to the second instance database using the 2PC protocol.

4. The distributed active-active database system across data centers according to claim 1, characterized in that: During system operation, when the first instance database fails, the system automatically switches the current working data center to the second data center where the second instance database is located. Then, the database transaction system caches the write operations in the execution plan with replication attributes in the first instance database, and the second instance database continues to provide read and write services to external applications.

5. A method for a distributed active-active database across data centers, characterized in that... The method includes the following steps: The first instance database is established by the database transaction system reading configuration information while executing write operations of external applications, and establishing a peer database with the second instance database. The database transaction system synchronously writes the currently executed write operations into the second instance database. When a database transaction system performs a write operation, it first determines whether the current execution plan has replication attributes. If the result is yes, it reads the configuration information and establishes a peer database with the second instance database; otherwise, it only performs the current write operation in the first instance database. The execution plan is generated by the database compiler. When generating the execution plan, the database compiler first identifies whether the current data table has the xdc attribute. If so, it generates an execution plan with the replication attribute. The xdc attribute refers to key data that has been manually filtered and retained in the data table beforehand.

6. The distributed active-active database method across data centers according to claim 5, characterized in that... The method further includes the following steps: when the first instance database fails, the current working data center is automatically switched to the second data center where the second instance database is located. Then, the database transaction system caches the write operation data in the execution plan with replication attributes in the first instance database, and the second instance database continues to provide read and write services to external applications.

7. The distributed active-active database method across data centers according to claim 5 or 6, characterized in that... The database transaction system synchronously writes the currently executing write operation to the second instance database via the 2PC protocol; the peer database is identified by its IP address and port number.

Images