Database switching method, apparatus, device, and storage medium

Abstract

The application discloses a database switching method and device, equipment and a storage medium, and relates to the technical field of databases, and comprises the following steps: when a received service request is a write request, synchronously writing data carried by the write request into a source database and a target database; when the service request is a read request, sending the read request to the source database and the target database, and reading data from the source database and the target database based on the first read request; when data consistency verification is performed, verifying the data synchronously written into the source database and the target database and verifying the data read from the source database and the target database; when the result of the data consistency verification meets preset migration conditions, writing the data carried by the write request into the target database based on the first read request, and when the running state of the target database meets preset stable conditions, completing database switching. The application guarantees service continuity during database switching.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to database switching methods, apparatus, devices and storage media. Background Technology

[0002] In database migration and transformation scenarios for high-concurrency, high-availability core business systems, the source and target databases are heterogeneous and have different data models. Existing migration solutions typically adopt a static model of "first migrating all historical data, then incrementally synchronizing, and finally cutting over and switching." This means that all historical data in the source database needs to be extracted, data type mapped, and syntax converted before being loaded into the target database. After data synchronization is completed, business traffic is then switched to the target database.

[0003] However, in high-concurrency business scenarios, the source database stores massive amounts of historical data, making the full migration process extremely time-consuming. During the migration, it is susceptible to factors such as network fluctuations and data volume, leading to data loss or corruption and impacting business continuity. After the migration is complete, data consistency verification is limited to a static comparison of existing data in the two databases, which cannot cover dynamic business scenarios such as high-concurrency writes and transaction order dependencies in a real production environment. This makes it difficult to fully verify the accuracy of the migrated data. If the target database experiences an anomaly after the switch, the source database has stopped receiving new data after the switch, and there is a risk of data loss when switching back to the source database, severely impacting business continuity. Summary of the Invention

[0004] The main objective of this application is to provide a database switching method, database switching device, electronic device, and storage medium, which aims to solve the technical problem of existing database switching affecting business continuity.

[0005] To achieve the above objectives, this application proposes a database switching method, which includes: When the received business request is a write request, the data carried by the write request is synchronously written to the source database and the target database; When the service request is a read request, a first read request corresponding to the read request is sent to the source database, and a second read request corresponding to the read request is sent to the target database, wherein the source database responds to the first read request; When performing data consistency verification, the data synchronously written to the source database and the target database is verified, as are the data read from the source database based on the first read request and the data read from the target database based on the second read request. When the result of the data consistency verification meets the preset migration conditions, the target database responds to the first read request, and when the operating status of the target database meets the preset stability conditions, the data carried by the write request is written to the target database to complete the database switch.

[0006] In one embodiment, the step of verifying the data read from the source database based on the first read request and the data read from the target database based on the second read request includes: Obtain the first query result returned by the source database based on the first read request; Obtain the second query result returned by the target database based on the second read request; The first query result and the second query result are compared to obtain the first verification result.

[0007] In one embodiment, the step of verifying the data synchronously written to the source database and the target database includes: Based on the write request, determine the first total amount of data to be written to the source database and the second total amount of data to be written to the target database within a preset period; The first total data volume and the second total data volume are compared to obtain the second verification result.

[0008] In one embodiment, after the step of verifying the data synchronously written to the source database and the target database, the method further includes: After each preset period ends, the data in the source database and the data in the target database are compared field by field to obtain a third verification result.

[0009] In one embodiment, after performing data consistency verification, the method further includes: When any verification result indicates that there is a difference in data between the source database and the target database, the missing data in the target database compared to the source database is determined, wherein the verification result includes the first verification result, the second verification result and the third verification result; The missing data is retrieved from the source database and added to the target database.

[0010] In one embodiment, the step of the target database responding to the first read request includes: Obtain a preset database sharding routing strategy, wherein the database sharding routing strategy is the routing rule for read requests; According to the database sharding routing strategy, the first read request is distributed to the source database and the target database, so that the source database responds to the read request distributed to the source database, and the target database responds to the read request distributed to the target database. During the preset transition period, the database routing strategy is dynamically adjusted to gradually increase the number of read requests distributed to the target database and correspondingly reduce the number of read requests distributed to the source database until all read requests are distributed to the target database.

[0011] In one embodiment, after the step of the target database responding to the first read request, the method further includes: When an abnormal running status of the target database is detected, the preset database sharding routing strategy is modified, wherein the database sharding routing strategy is the routing rule for read requests; The service provider for the read request will be switched back from the target database to the source database.

[0012] Furthermore, to achieve the above objectives, this application also proposes a database switching device, which includes: The write module is used to synchronously write the data carried by the write request to the source database and the target database when the received business request is a write request; The response module is configured to send a first read request corresponding to the read request to the source database and a second read request corresponding to the read request to the target database when the business request is a read request, wherein the source database responds to the first read request; The verification module is used to verify the data synchronously written to the source database and the target database when performing data consistency verification, and to verify the data read from the source database based on the first read request and the data read from the target database based on the second read request. The read switching module is used to respond to the first read request by the target database when the result of the data consistency verification meets the preset migration conditions, and to write the data carried by the write request into the target database when the running state of the target database meets the preset stability conditions, so as to complete the database switching.

[0013] In addition, to achieve the above objectives, this application also proposes an electronic device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the database switching method described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the database switching method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the database switching method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: In this application, write requests are synchronously written to both the source and target databases, allowing the target database to continuously accumulate incremental data consistent with the source database. This eliminates the need to migrate all historical data, mitigating the time-consuming nature of full migration and the risk of data loss or corruption due to network fluctuations. Read requests are responded to by the source database and returned to the sender of the business request. Consistency verification is performed on the data read from both databases based on the read request. This verification process is driven by real business requests, covering dynamic business scenarios and overcoming the shortcomings of static comparisons in fully verifying data accuracy. After the data consistency verification results meet preset migration conditions, the service provider for the read requests is switched from the source database to the target database. Simultaneously, dual writing continues, ensuring the source database remains consistent with the target database after the switch. This allows for a seamless switchback to the source database without data loss should the target database malfunction. Finally, writing to the source database stops when the target database's operating status meets preset stability conditions, completing the switchover. This enables robust database switching without requiring a full migration of historical data, continuously verifying data consistency in real dynamic business scenarios, and providing secure and reversible rollback capabilities after the switch. Since the database is always online to accept read requests and continuously receive incremental write data throughout the entire switching process, neither read nor write requests are interrupted, thus ensuring business continuity without stopping the business. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating an embodiment of the database switching method of this application. Figure 1 ; Figure 2 A flowchart illustrating an embodiment of the database switching method of this application. Figure 2 ; Figure 3 A flowchart illustrating an embodiment of the database switching method of this application. Figure 3 ; Figure 4 A flowchart illustrating an embodiment of the database switching method of this application. Figure 4 ; Figure 5 A flowchart illustrating an embodiment of the database switching method of this application. Figure 5 ; Figure 6 This is a schematic diagram of the module structure of the database switching device of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the database switching method of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] It should be noted that the executing entity in this embodiment can be an electronic device, such as a server, computer, embedded device, etc.; it can also be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or a chip, processor, or integrated circuit capable of realizing the above functions. The following description uses an electronic device as an example to illustrate this embodiment and the subsequent embodiments.

[0024] Based on this, this application provides a database switching method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the database switching method of this application.

[0025] In one feasible embodiment, the application scenarios of the technical solution of this application can be: domestic migration of banking business system databases, upgrade of financial core system database versions, and database replacement of high-concurrency online business systems.

[0026] In this embodiment, the database switching method includes steps S1 to S4: Step S1: When the received business request is a write request, the data carried by the write request is synchronously written to the source database and the target database. It should be noted that the electronic device continuously receives various business requests from the upstream business system, and the microservice center deployed in the electronic device distributes the business requests according to the operation type of the business requests.

[0027] Optionally, the microservice center is a service governance component running on the electronic device, responsible for managing the registration and discovery, load balancing, and routing policies of each microservice instance in the business system. In this embodiment, the microservice center is specifically used to distribute the received business requests to the corresponding database instances for processing according to the configured database sharding routing policy. That is, the microservice center is a functional module inside the electronic device that implements business request routing and distribution, and is called and controlled by the electronic device.

[0028] Optionally, business requests are categorized into write requests and read requests based on the nature of their operations on database data: write requests are operations that require creating, updating, or deleting data in the database, such as inserting a transaction record or updating a user's account balance; read requests are operations that require querying or retrieving data from the database, such as querying customer information or retrieving a list of transaction details.

[0029] Optionally, the source database can be an existing database currently in use by the banking business system, such as an Oracle database, which stores all business data and provides complete read and write services to the outside world; the target database can be a newly created database to achieve database switching, such as a domestic database like GaussDB, which is initially an empty database or does not contain all historical data from the source database.

[0030] Optionally, the database switching method in this application embodiment is applicable to stateless databases, that is, databases that do not save session states or temporary intermediate results related to business logic, but only persistently store business data.

[0031] Additionally, it's important to note that the data in the source database has a lifecycle. Each piece of data is retained in the source database for a preset duration (e.g., 30 days). Historical data exceeding this preset duration is automatically cleaned up; alternatively, historical data exceeding the preset duration in the source database is dumped to a backup database (i.e., archive storage) and removed from the source database. The source database only retains active data within the preset duration. When the dual-write mechanism between the source and target databases has been running continuously for the preset duration (e.g., 30 days of continuous dual-write), the target database has accumulated data completely identical to the current content in the source database through the dual-write mechanism. Historical data in the source database that has exceeded its lifecycle and has been cleaned up or dumped does not exist in the target database. Therefore, the two databases are completely identical in terms of data content. For historical data stored in the source database before the dual-write mechanism was activated, since it had exceeded its lifecycle and was cleaned up or dumped by the source database before the switch occurred, it does not need to be migrated to the target database, thus achieving zero data migration.

[0032] If the lifecycle of data in the source database is longer than the dual-write window period (for example, the source database has been running for 100 days, while the dual-write mechanism has only been running for 30 days, leaving 70 days of historical data that has not been cleaned or dumped), then this part of the historical data will not be able to be read when the read request switches to the target database because it has not been synchronized to the target database by the dual-write mechanism. In this case, one of the following methods can be used: Method 1: When a read request for this part of the historical data is received, the service provider for the read request is switched back from the target database to the source database, and the source database responds to the read request. Since the dual-write mechanism is still running, the source database always has complete and up-to-date data, so the source database can respond to all read requests normally. Method 2: Configure the runtime of the dual-write mechanism to cover the complete data lifecycle of the source database. That is, after the continuous dual-write reaches a complete lifecycle (for example, 100 days), all existing data in the source database has been synchronized to the target database through the dual-write mechanism, and the expired historical data has been cleaned or dumped during the dual-write process. At this time, the data in the two databases are completely consistent, and then the read request switch is performed. The two methods described above ensure that there is always a database available to respond to read requests without migrating any historical data.

[0033] Optionally, when the electronic device determines that the currently received business request is a write request, the electronic device writes the data carried by the write request (such as the record content of the insert operation, the new value of the field of the update operation, etc.) to both the source database and the target database at the same time, that is, performs a "double write" operation.

[0034] Optionally, synchronous writing can be achieved by having electronic devices, through a consumer gateway (such as Kafka), simultaneously forward the data corresponding to the write request to both the source and target databases in a bypass manner. Only after both databases have successfully written the data will a write success response be returned to the business system. Understandably, by using a consumer gateway to handle dual-write traffic in a bypass manner, the dual-write logic is decoupled from the main business process. Business applications do not need to modify their core business code; only minor SQL syntax adaptation is required at the database access layer to integrate the dual-write mechanism. Simultaneously, routing strategy control during the migration process is centralized in the configuration-based database sharding strategy of the microservice center. Switching operations are completed by modifying the configuration, without changing the business application code. Therefore, the intrusion of database migration into the business application code is minimized, achieving lightweight, low-intrusion, and robust database migration in high-concurrency scenarios.

[0035] Optionally, synchronous writing can also involve the electronic device, after receiving a write request, first writing data to the source database, then writing the same data to the target database, and returning a success response after both databases have been successfully written. Optionally, throughout the entire process of the source database providing normal external services, the electronic device continuously performs the operation of synchronously writing the data carried by the write request to both the source and target databases.

[0036] Understandably, since the target database continuously receives and accumulates the same incremental write data as the source database from the moment the migration starts, the data in the target database gradually accumulates to be consistent with the source database over time. Therefore, there is no need to perform the operation of migrating all historical data from the source database to the target database, which fundamentally eliminates the risk of data loss or damage caused by the extremely long full migration process and its susceptibility to network fluctuations and data volume.

[0037] Step S2: When the service request is a read request, a first read request corresponding to the read request is sent to the source database, and a second read request corresponding to the read request is sent to the target database, wherein the source database responds to the first read request; It should be noted that when the electronic device determines that the currently received service request is a read request, the electronic device sends the read request to both the source database and the target database simultaneously to obtain the query results of the same read request from both databases for subsequent consistency comparison. Specifically, only the query result data returned by the source database in response to the read request is returned to the business system to maintain the normal response of the business read service; the target database receives the query result data returned by the read request for consistency verification with the response result of the source database, and does not return it to the business system.

[0038] Optionally, the same read request can be sent to both the source and target databases simultaneously. This can be achieved using traffic replication: the electronic device copies the received original read request into two identical sub-requests, namely a first read request and a second read request. Both the first and second read requests contain the same query conditions, query fields, and filter conditions. The electronic device sends the first read request to the source database, which then performs a query operation on its stored data based on the query conditions in the first read request and returns a first query result. The electronic device then sends the second read request to the target database, which performs a query operation on its stored data based on the query conditions in the second read request and returns a second query result. It is understood that the content of the first and second read requests is essentially the same; the only difference is that they are sent to different database instances.

[0039] Optionally, after sending the read request to both the source database and the target database simultaneously, the first query result returned by the source database is used to return the query result to the business system to ensure that the business system is always provided with read services by the source database; the second query result returned by the target database is used to compare with the first query result returned by the source database to verify whether the data in the target database is consistent with the data in the source database.

[0040] Understandably, this step sends business read requests to both the source and target databases simultaneously, so that the data consistency verification process is driven by business read requests under real production traffic. This can cover the data consistency verification needs in dynamic scenarios such as high-concurrency queries, transaction order dependencies, and specific business logic, and overcomes the shortcomings of traditional solutions that can only perform static comparisons of existing data in the two databases and cannot fully verify the accuracy of data in dynamic business scenarios.

[0041] Step S3: When performing data consistency verification, the data synchronously written to the source database and the target database is verified, as are the data read from the source database based on the first read request and the data read from the target database based on the second read request. It should be noted that after the electronic device synchronously writes the data carried by the write request to the source database and the target database, and after obtaining the first query result returned by the source database based on the first read request and the second query result returned by the target database based on the second read request, it needs to perform a consistency check on the data in the two databases to determine whether the data in the target database is consistent with the data in the source database, in order to determine whether to perform a subsequent switch.

[0042] Optionally, data consistency verification includes at least: verifying synchronously written data, i.e., verifying write operations; and verifying data read based on read requests, i.e., verifying query operations. Verification of synchronously written data includes periodically verifying the total amount or number of records written to the source and target databases through a timed verification mechanism (e.g., verifying the total amount of written data in both databases every hour), and / or performing detailed field-level verification of the written data in the source and target databases through end-of-day batch processing (e.g., extracting data from both databases to a big data platform for field-by-field comparison daily). Verification of data read based on read requests includes comparing the differences between the first query result returned by the source database and the second query result returned by the target database, either field-by-field or entry-by-entry, such as comparing the number of records returned by the two databases and whether the values ​​of each field are consistent under the same query conditions.

[0043] Understandably, by performing dual verification on both written and read data, we can ensure that the data written to the two databases remains consistent at the storage level, and that the data read from the two databases remains consistent at the business logic level. This builds a data consistency verification system that covers all scenarios, transforming the traditional static migration acceptance into dynamic continuous consistency verification.

[0044] Step S4: When the result of the data consistency verification meets the preset migration conditions, the target database responds to the first read request, and when the running state of the target database meets the preset stability conditions, the data carried by the write request is written to the target database to complete the database switch.

[0045] It should be noted that the electronic device determines whether the preset migration conditions are met based on the data consistency verification results, and performs a read traffic switching operation when the conditions are met.

[0046] Optionally, the preset migration condition can be: within a continuous preset time period (e.g., 30 consecutive days, corresponding to the entire lifecycle of business data in the source database), the synchronously written data verification and read data verification are consistent, meaning that the data in the target database and the data in the source database achieve continuous consistency under dynamic real business traffic. Optionally, the preset migration condition can also be: in a preset number of comparison tasks, the data consistency verification pass rate between the source database and the target database reaches a preset threshold (e.g., above 99.99%).

[0047] Optionally, if the data consistency verification result meets the preset migration conditions, the electronic device switches the service provider of the first read request received subsequently from the source database to the target database. That is, after the switch, the first read request received subsequently is no longer sent to the source database, but directly to the target database. The target database then returns the query results to the business system based on the first read request, achieving a seamless switch of read traffic. Simultaneously, the source database becomes a bypass comparison role; that is, subsequent read requests are no longer sent to the source database, but the data carried by write requests is still synchronously written to both the source and target databases. This ensures that the source database continues to receive the same incremental write data as the target database after the switch, maintaining data consistency between the two databases. Therefore, if the target database experiences an anomaly, the service provider of the read request can be switched back to the source database without data loss, avoiding the risk of data loss during the switchback caused by the source database ceasing to receive new data after the switch, as is common in traditional solutions.

[0048] Optionally, after the target database has accepted all read requests and its operating status meets preset stability conditions (e.g., the target database has been running stably for a preset period of time, system resource utilization is normal, and there are no abnormal errors), the electronic device stops writing data to the source database. That is, the data carried by subsequent write requests is only written to the target database and is no longer synchronously written to the source database, thus completing the database switchover. Optionally, after stopping writing data to the source database, the source database can be taken offline.

[0049] In one implementation, steps S2-S4 can also be described as follows: when the service request is a read request, the read request is sent to the source database and the target database respectively; the data read from the source database is returned to the sender of the service request, and the data read from the target database is used for data consistency verification; during data consistency verification, the data synchronously written to the source database and the target database is verified, as are the data read from the source database and the target database; when the result of the data consistency verification meets the preset migration conditions, the data read from the target database is returned to the sender of the service request, and when the operating state of the target database meets the preset stability conditions, the data carried by the write request is written to the target database to complete the database switch.

[0050] Understandably, because the database remained online throughout the switchover process, continuously accepting read requests and receiving incremental write data, and neither read nor write requests were interrupted, business continuity was ensured without stopping operations. Furthermore, since the switchover was performed only after the data consistency check met the preset migration conditions, data consistency between the two databases was guaranteed during the switchover. Moreover, because data continued to be synchronously written to the source database after the switchover, the source and target databases remained consistent, ensuring a safe and reversible switchover to the source database without data loss should the target database fail.

[0051] This embodiment provides a database switching method. When a business request is received as a write request, the data carried by the write request is synchronously written to both the source and target databases. This allows the target database to continuously receive and accumulate the same incremental write data as the source database from the start of the migration. Therefore, it eliminates the need to perform a full migration of historical data from the source database, fundamentally eliminating the risk of data loss or corruption caused by the extremely long time consumption and susceptibility to network fluctuations and data volume during a full migration process. Simultaneously, when a business request is received as a read request, the read request is sent to the source database. The source database responds to the read request and performs consistency verification on the data synchronously written to the source and target databases and the data read based on the read request. This ensures that the data consistency verification process is driven by real business requests, covering dynamic business scenarios such as high-concurrency writes and transaction order dependencies. This overcomes the shortcomings of traditional solutions, which can only perform static comparisons of existing data between the two databases and cannot fully verify data accuracy. After the data consistency verification results meet the preset migration conditions, the service provider for subsequent read requests is switched from the source database to the target database (i.e., subsequent read requests are responded to by the target database). Since the switch is implemented when the preset migration conditions are met, rather than after data synchronization is completed, the consistency of the two databases is guaranteed during the switch. Specifically, while the target database responds to the read requests received after the switch, it continues to synchronously write the data carried by subsequent write requests to both the source and target databases. This ensures that the source database continues to receive the same incremental write data as the target database after the switch, and the source and target databases always maintain data consistency. Thus, if the target database encounters an anomaly, the service provider for read requests can be switched back to the source database without data loss, avoiding the risk of data loss during the switchback caused by the source database stopping receiving new data after the switch in traditional solutions. Finally, when the target database's operating status meets the preset stability conditions, writing data to the source database stops, and only the data carried by write requests is written to the target database to complete the database switch.

[0052] This enables robust database switching without requiring a full migration of historical data, continuously verifying data consistency in real dynamic business scenarios, and providing secure and reversible rollback capabilities after the switch. Since the database is always online to accept read requests and continuously receive incremental write data throughout the entire switching process, neither read nor write requests are interrupted, thus ensuring business continuity without stopping the business.

[0053] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, step S3, the step of verifying the data read from the source database based on the first read request and the data read from the target database based on the second read request, includes: Step A31: Obtain the first query result returned by the source database based on the first read request; It should be noted that after the electronic device sends the first read request to the source database, the source database performs a query operation on its stored data according to the query conditions (such as the target field, filtering conditions, sorting method, etc.) carried in the first read request, and generates the first query result.

[0054] Optionally, obtaining the query results can be achieved by the electronic device waiting for the source database to return the query results through synchronous calls, or by the electronic device receiving the query results actively pushed by the source database through asynchronous callbacks.

[0055] Optionally, the first query result may include the set of records matched by the source database according to the query conditions in the first read request, and the specific values ​​of each query field in each record.

[0056] Understandably, the first query result is a dynamic query result returned by the source database under the read request driven by the actual business, reflecting the current data status of the source database during the continuous writing and updating of business data.

[0057] Step A32: Obtain the second query result returned by the target database based on the second read request; It should be noted that after the electronic device sends the second read request to the target database, the target database performs a query operation on its stored data based on the query conditions carried in the second read request (which are the same as the query conditions carried in the first read request in step A31), and generates the second query result. The method for obtaining the result can be found in step A31.

[0058] Optionally, the second query result may include the set of records matched by the target database according to the query conditions in the second read request, and the specific values ​​of each query field in each record.

[0059] It is understandable that, since the content of the first read request and the second read request are the same, the difference between the first query result and the second query result is only that they come from different database instances.

[0060] Step A33: Compare the first query result and the second query result to obtain the first verification result.

[0061] It should be noted that after the electronic device obtains the first query result returned by the source database and the second query result returned by the target database, it compares the two to determine whether the response results of the two databases to the same read request are consistent.

[0062] Optionally, the comparison may include comparing the number of records in the first query result and the second query result, comparing the values ​​of each field in the records corresponding to the same primary key or unique identifier, and comparing the overall data structure of the returned results.

[0063] Optionally, when the first query result and the second query result are exactly the same (i.e., the number of records is the same, the values ​​of each field in each record are the same, and the data format is the same), the first verification result can indicate that the query results of the two databases are consistent; when there are any differences between the first query result and the second query result, the first verification result can indicate that the query results of the two databases are inconsistent.

[0064] Optionally, if the first verification result indicates inconsistency, the electronic device writes the difference result to intermediate storage (such as Elasticsearch, a distributed search and analysis engine). The difference result may include information such as inconsistent record identifiers, inconsistent field names, field values ​​in the source database, and field values ​​in the target database, so that operations and maintenance personnel can analyze the reasons for the difference and gradually repair the business logic or eliminate reasonable differences, ultimately achieving consistency of query results between the two databases.

[0065] Understandably, by comparing the results returned by executing queries on two databases for the same read request, near real-time dynamic verification of data consistency between the two databases is achieved under real production traffic. The verification scope covers complex query scenarios such as database index queries, join queries, and aggregation queries, making the verification results more in line with actual business needs and providing accurate data basis for switching decisions.

[0066] For example, to help understand the implementation flow of the database switching method obtained by combining this embodiment with the above embodiments, please refer to... Figure 2Specifically, the same read request is copied and sent to both the source and target databases. The source database responds with the first query result, and the target database responds with the second query result. The first and second query results are then compared to generate a first verification result. This process is driven by real business read requests, covering dynamic scenarios such as high-concurrency queries and transaction order dependencies, thus overcoming the limitation of traditional solutions that can only perform static data comparisons.

[0067] In one feasible implementation, step S3, the step of verifying the data synchronously written to the source database and the target database, includes: Step B31: Based on the write request, determine the first total amount of data to be written to the source database and the second total amount of data to be written to the target database within a preset period; It should be noted that during the process of continuously receiving write requests and synchronously writing the data they carry to the source and target databases, the electronic device needs to periodically check the total amount of data written to the two databases within a preset time range to verify whether there is a difference in the amount of data written at the storage level between the two databases.

[0068] Optionally, the preset period can be a pre-set time interval, such as every hour as a preset period. The electronic device counts the total number of data entries or records actually written to the source database from the data carried by each write request received by the electronic device within the preset period, as the first total data volume; and counts the total number of data entries or records actually written to the target database from the data carried by each write request received by the electronic device within the same preset period, as the second total data volume.

[0069] Optionally, the preset period can also be divided by the cumulative number of write requests. For example, after receiving and processing a preset number (e.g., 10,000) of write requests, the total number of data actually written to the source database in this batch of write requests is counted as the first total data volume, and the total number of data actually written to the target database in the same batch of write requests is counted as the second total data volume.

[0070] Optionally, determining the first and second total data amounts can be achieved by reading the transaction logs, operation audit records, or statistical information (such as table record counts) of the source and target databases respectively; alternatively, the electronic device can automatically increment the counter when writing the data carried by the write request to each database, record the total number of writes to the source database and the total number of writes to the target database respectively, and read the accumulated value from the counter at the end of each preset period as the corresponding total data amount.

[0071] Optionally, the preset period can be flexibly configured according to business characteristics. For example, in high-concurrency business scenarios, where data is written very frequently, the preset period can be shortened to detect data volume differences more promptly; in systems with low write frequency, the preset period can be extended to reduce verification overhead.

[0072] Understandably, by determining the total amount of data written to the two databases within a preset period based on write requests, the system enables periodic monitoring of the amount of data written to the two databases. This allows for timely detection of write loss or omissions in the two databases (e.g., write failures in the target database due to network jitter, or failures in the target database itself to write some data successfully), ensuring timely data replenishment and consistency repair.

[0073] Step B32: Compare the first total data volume with the second total data volume to obtain the second verification result.

[0074] It should be noted that after the electronic device determines the first total amount of data written to the source database and the second total amount of data written to the target database within the preset period, it compares the first total amount of data with the second total amount of data to determine whether the amount of data received and stored by the two databases within the preset period is consistent, and uses the comparison result as the second verification result.

[0075] Optionally, if the first total data volume is the same as the second total data volume, the second verification result can indicate that the total amount of written data in the two databases is consistent within a preset period; if there is a difference between the first total data volume and the second total data volume (for example, the first total data volume is 1000 records while the second total data volume is 998 records), the second verification result can indicate that the total amount of written data in the two databases is inconsistent within a preset period, and the target database is missing some data that should have been written.

[0076] Optionally, when the second verification result indicates that the total amount of data in the two databases is inconsistent, the electronic device uses the interval consumption function of the consumption gateway to forward the missing data to the missing party (i.e., the party with less total data) in a bypass manner to fill in the missing data and maintain the consistency of the data in the two databases.

[0077] It is understandable that by periodically checking the total amount of data written to the two databases within a preset period, a data consistency verification mechanism for the write dimension is constructed. This mechanism complements the aforementioned step of comparing and verifying the query dimension based on the read request return results, and together they cover the data consistency verification requirements for both the write and read dimensions.

[0078] For example, to help understand the implementation flow of the database switching method obtained by combining this embodiment with the above embodiments, please refer to... Figure 3Specifically, the same write request is written to both the source and target databases, and the total amount of data written to the source database and the total amount of data written to the target database within a preset period are counted. Then, the total amounts of data are compared to generate a second verification result, which is used to quickly detect whether any data loss or omission occurs during the dual-database write process.

[0079] In one feasible implementation, after step S3, which verifies the data synchronously written to the source database and the target database, the method further includes: Step C31: After each preset period ends, the data in the source database and the data in the target database are compared field by field to obtain the third verification result.

[0080] It should be noted that after the electronic device completes the verification of the total number of data entries written to the two databases within the preset period, it also needs to perform a more granular content-level verification of the data stored in the source database and the target database at a specific time point after the end of each preset period (e.g., at the end of each day) to verify whether the data content stored in the two databases is completely consistent.

[0081] Optionally, the preset period can be the end-of-day batch processing period, such as a centralized verification of all written data from the previous day at midnight every day. Optionally, the end of each preset period can refer to the end of a natural day, the start of a batch processing window, or a fixed end-of-day time.

[0082] Optionally, data can be compared field by field. Specifically, this can include: electronic devices extracting all or a specified range of data from the source database to a big data platform (e.g., a data analysis platform built on the Hadoop ecosystem) using data extraction tools, and simultaneously extracting the corresponding data from the target database to the same big data platform. Field-by-field comparisons are then performed on the two sets of data within the big data platform. Optionally, field-by-field comparison can compare the values ​​of each field in each record of a data table to see if they are the same. For example, comparing whether all fields such as customer name, ID number, account balance, and account opening date of a record in a customer table are completely consistent between the source and target databases. Optionally, field-by-field comparison can also be performed only on core business fields. Technical fields (e.g., trace log fields, timestamp fields) or fields with known reasonable differences (e.g., minor differences in timestamps due to dual-write timeliness) can be configured to skip comparison or be processed separately.

[0083] Optionally, after field-by-field comparison, the electronic device generates a third verification result. This third verification result may include: the number of completely identical records, the number of records with field differences, the specific inconsistencies in the field names of each differing record, and the field values ​​for each of the two databases. Optionally, if the third verification result indicates a field-level difference, the electronic device writes the difference record to intermediate storage for maintenance personnel to analyze the cause of the difference and perform data repair operations. Optionally, data repair may be achieved by using the interval consumption function of the consumption gateway to re-forward missing or erroneous data to the target database for overwriting or supplementation.

[0084] Understandably, in addition to periodic total data reconciliation, a field-by-field detailed data content reconciliation has been introduced, complementing the total data reconciliation. Total data reconciliation quickly identifies overall differences in write volumes between the two databases, while field-by-field reconciliation precisely pinpoints differences in the content of specific records and fields. Together, they form a multi-level data consistency verification system from macro to micro, comprehensively covering the accuracy verification needs at the storage level. Simultaneously, end-of-day field-by-field reconciliation effectively identifies business anomalies caused by design differences between the source and target databases in areas such as underlying storage engines, data type definitions, character sets, and precision handling, ensuring accurate data migration between heterogeneous databases. Furthermore, field-by-field reconciliation is also applicable to data generated in batches at the end of the day, combining with online real-time reconciliation and scheduled record count reconciliation to jointly cover the data consistency verification needs of all business scenarios.

[0085] For example, to help understand the implementation flow of the database switching method obtained by combining this embodiment with the above embodiments, please refer to... Figure 4 Specifically: After each preset period ends, a consistency check is performed on the data accumulated within the period. Data to be compared within the preset period is obtained from the source database and the target database respectively. After the comparison is completed, a third verification result is generated.

[0086] In one feasible implementation, after performing data consistency verification, the method further includes: Step D31: When any verification result indicates that there is a difference in data between the source database and the target database, determine the missing data in the target database compared to the source database, wherein the verification result includes the first verification result, the second verification result and the third verification result; It should be noted that after the electronic device obtains the first, second, and third verification results, it needs to comprehensively analyze these results to determine whether the data between the source database and the target database is completely consistent, and if there are differences, further determine the specific data content that is missing in the target database compared to the source database.

[0087] Optionally, any verification result indicating a discrepancy could be: the first verification result indicating that the first query result is inconsistent with the second query result; the second verification result indicating that the total amount of the first data is different from the total amount of the second data; or the third verification result indicating that there are records with inconsistent field-level content.

[0088] Optionally, the electronic device can determine whether a single verification result indicates a difference after obtaining it, or it can summarize all verification results after a complete verification cycle (e.g., a calendar day) and then make a comprehensive judgment.

[0089] Optionally, the missing data in the target database compared to the source database can be determined based on the type of difference reflected by different verification results: When the second verification result indicates that the total amount of data in the target database is less than the total amount of data in the source database, the electronic device compares the record identifiers (such as primary keys, unique indexes, etc.) of the two databases to find the record identifiers in the source database that exist in the source database but not in the target database, and determines the complete record content corresponding to these record identifiers as missing data; when the third verification result indicates that the value of a certain field in a record in the target database is inconsistent with that in the source database, the electronic device determines the correct value of the inconsistent field in that record (i.e., the field value in the source database) as missing data; when the first verification result indicates that the query results of the two databases are inconsistent, the electronic device determines the specific missing or incorrect data content in the target database based on the comparison difference between the first query result and the second query result.

[0090] Optionally, the electronic device can compile all the identified missing data into a missing data list, which includes at least the table name of the missing data, the unique identifier of the record, the name of the missing field, and the correct field value in the source database.

[0091] Understandably, by combining the results of the three verification methods to accurately identify missing data, it is possible to comprehensively cover data missing situations at all levels, from total data volume and record granularity to field granularity, ensuring the completeness and relevance of the data entry operation.

[0092] Step D32: Obtain the missing data from the source database and add it to the target database.

[0093] It should be noted that after determining the missing data in the target database compared to the source database, the electronic device needs to read the complete content of this missing data from the source database and write it into the target database to achieve consistency repair between the two databases.

[0094] Optionally, obtaining missing data from the source database can be achieved by the electronic device initiating a data query request to the source database based on the record identifier or primary key value of each missing data entry in the missing data list, and then reading the corresponding complete record content from the source database.

[0095] Optionally, the data can be supplemented to the target database by having the electronic device forward the acquired complete record content to the target database in a bypass manner through the consumption gateway, and then having the target database perform the write operation.

[0096] Optionally, the data entry operation can be performed in a one-time batch, that is, all missing data are read from the source database and written to the target database in batches; or it can be performed in batches, that is, missing records are read from the source database and written to the target database one by one during off-peak hours, so as to reduce the impact of the data entry operation on the normal business processing of the source database.

[0097] Optionally, the specific writing method for supplementing data into the target database can be determined based on the current data status of the target database: if the record does not exist in the target database at all (i.e., the record is missing), the electronic device will insert the obtained complete record as a new record into the target database; if the record already exists in the target database but some field values ​​are inconsistent with the source database (i.e., fields are missing or incorrect), the electronic device will perform an update operation on the record in the target database according to the correct values ​​of the corresponding fields in the obtained complete record, correcting the inconsistent fields to be consistent with the source database.

[0098] Optionally, after the data entry operation is completed, the electronic device can trigger the verification of the entered data again (e.g., re-execute steps A31 to A33 or step C31) to verify that the missing data has been successfully entered and that the data in the two databases has been restored to consistency.

[0099] Understandably, by retrieving missing data from the source database and supplementing it into the target database, automatic data repair and dynamic, continuous consistency between the two databases are achieved. This ensures that the target database remains synchronized with the source database throughout the dual-write process driven by real production traffic, providing reliable data consistency guarantees for subsequent traffic switching. Furthermore, since the supplemented data originates from the source database, its accuracy and reliability are ensured, avoiding the data error risks that might be introduced from supplementing data from other sources.

[0100] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, step S4, the step of the target database responding to the first read request, includes: Step S41: Obtain a preset database sharding routing strategy, wherein the database sharding routing strategy is the routing rule for read requests; It should be noted that before an electronic device performs a service provider switching operation for a read request, it first needs to obtain the preset database sharding routing policy to determine the distribution rules and distribution targets for the current read request.

[0101] Optionally, the database sharding routing strategy is a set of routing rules pre-configured in the microservice center (such as the FTC microservice center) to determine which database instance each read request received by an electronic device should be distributed to for processing.

[0102] Optionally, the database sharding routing strategy can include a combination of one or more routing factors, such as the last digit of the customer number, the range of IP addresses from which the request originates, the business type identifier, and the random sampling ratio.

[0103] Optionally, obtaining the preset database sharding routing policy can be achieved by the electronic device reading the currently effective database sharding routing policy configuration file from the routing configuration management module of the microservice center, or by the electronic device pulling the latest database sharding routing policy from the configuration center (such as a distributed configuration center) at startup or periodically and caching it locally.

[0104] Understandably, the database sharding routing strategy is the core configuration that controls the distribution ratio and rules of read requests between the source database and the target database. By obtaining this database sharding routing strategy, electronic devices can determine which database each read request should be distributed to, thus providing a basis for subsequent traffic distribution and strategy adjustments.

[0105] Step S42: According to the database sharding routing strategy, the first read request is distributed to the source database and the target database, so that the source database responds to the read request distributed to the source database, and the target database responds to the read request distributed to the target database. It should be noted that after obtaining the database sharding routing policy, the electronic device needs to distribute and process read requests according to the rules of the database sharding routing policy.

[0106] Optionally, unlike step S2 where the same read request is sent to both the source and target databases simultaneously for consistency comparison, this step determines the distribution target for each read request based on the database sharding routing strategy during the switchover execution phase.

[0107] Optionally, distribution can be understood as an electronic device selecting one of the source database and the target database as the target database for the current read request according to the routing rules defined in the database sharding routing strategy, and sending the read request to the selected target database, which then performs the query operation and returns the query result.

[0108] Optionally, depending on the different configurations of the database sharding routing strategy, the electronic device can distribute some read requests to the source database, which will then respond to these read requests; at the same time, it can distribute another part of the read requests to the target database, which will then respond to these read requests.

[0109] Optionally, in the initial stage of the switchover execution, the database sharding routing strategy can be configured to distribute all read requests to the source database, which is consistent with the routing method in step S2; during the switchover execution, the database sharding routing strategy can be gradually adjusted to change the distribution ratio.

[0110] Understandably, by distributing read requests according to the database sharding routing strategy, flexible scheduling of read traffic between different databases is achieved, enabling the switching process to proceed smoothly without interrupting business operations.

[0111] Step S43: During the preset transition period, dynamically adjust the database routing strategy to gradually increase the number of read requests distributed to the target database and correspondingly reduce the number of read requests distributed to the source database until all read requests are distributed to the target database.

[0112] It should be noted that, based on the current database sharding routing strategy, the electronic device further performs dynamic adjustment operations on the database sharding routing strategy during a preset transition period to achieve a smooth migration of read traffic from the source database to the target database.

[0113] Optionally, the preset transition period can be a time interval from the start of the switchover to the end of the switchover completion time, such as 30 minutes, 2 hours, or any duration configured according to business characteristics, used to control the rhythm and speed of read traffic switching.

[0114] Optionally, dynamically adjusting the database sharding routing strategy can be achieved by the electronic device gradually modifying the routing factor values ​​or weight configurations used to determine the distribution target in the database sharding routing strategy according to a preset adjustment step size (e.g., increasing the proportion distributed to the target database by 10% every 5 minutes) or a preset adjustment curve (e.g., linear growth, S-curve growth, etc.). For example, when the database sharding routing strategy is based on the last digit of the customer number, the electronic device can gradually adjust the routing rule from "distribute all customers with last digits 0-9 to the source database" to "distribute customers with last digits 0-1 to the target database, and customers with last digits 2-9 to the source database," and then gradually expand the last digit range of the target database until "distribute all customers with last digits 0-9 to the target database." As another example, when the database sharding routing strategy is based on a random sampling ratio, the electronic device can gradually increase the sampling ratio distributed to the target database from 0% to 100%.

[0115] Optionally, the number of read requests distributed to the target database is gradually increased, and the number of read requests distributed to the source database is correspondingly reduced, until all read requests are distributed to the target database. This means that at the end of the transition period, the database sharding routing strategy is adjusted so that all read requests are distributed to the target database, and the target database responds to all first read requests, thereby achieving a complete switchover of the read traffic service provider.

[0116] Optionally, after each adjustment during the transition period, the electronic device can continuously monitor the target database's operating metrics (such as response time, error rate, throughput, etc.). If the monitoring detects anomalies, the adjustment of the database sharding routing strategy can be paused or rolled back to ensure the safety of the switching process.

[0117] Understandably, by acquiring the database sharding routing strategy, distributing traffic according to the strategy, and dynamically adjusting the strategy during the transition period, a smooth, controllable, and observable gradual switch of read traffic from the source database to the target database is achieved. Compared to switching all read traffic from the source database to the target database at a single point in time, this step minimizes the impact of the switch on business through gradual adjustments during the transition period. At the same time, it retains sufficient observation windows and operational space for monitoring and emergency rollback, ensuring the robustness of database switching in high-concurrency scenarios.

[0118] In one feasible implementation, after step S4, where the target database responds to the first read request, the method further includes: Step S44: When an abnormal running status of the target database is detected, the preset database sharding routing strategy is modified, wherein the database sharding routing strategy is the routing rule for read requests; It should be noted that after the electronic device distributes all read requests to the target database and the target database responds to all the first read requests, that is, during the stage when the target database is the primary active database providing read services to the outside world, the electronic device needs to continuously monitor the operating status of the target database so that it can respond in a timely manner when the target database has an anomaly.

[0119] Optionally, detecting abnormal operating status of the target database can be achieved by the electronic device periodically sending health check requests (such as heartbeat detection, lightweight SQL queries, etc.) to the target database through active probing. If no response is received from the target database after multiple consecutive probes or the response times out, the target database is determined to be in an abnormal operating status. Alternatively, the electronic device can passively monitor and collect runtime metrics of the target database in real time (such as error rate, average response time, throughput, number of database connections, etc.). When any metric exceeds a preset alarm threshold (such as an error rate exceeding 1%, an average response time exceeding 500 milliseconds, or the number of database connections reaching the upper limit), the target database is determined to be in an abnormal operating status.

[0120] Alternatively, abnormal operation status can also be caused by hardware failure of the server where the target database is located, unexpected termination of the target database process, or network partitioning that prevents electronic devices from communicating normally with the target database.

[0121] Optionally, when an abnormal operating status of the target database is detected, the electronic device immediately triggers a switchback process, modifies the preset database sharding routing strategy, and changes the rule in the database sharding routing strategy that originally distributed all read requests to the target database to the rule that distributes all read requests to the source database.

[0122] Optionally, modifying the database sharding routing policy can be done by sending a policy update command to the microservice center, which then switches the routing target configuration in the currently effective database sharding routing policy from the target database to the source database and distributes the updated policy to electronic devices in real time.

[0123] Alternatively, modifying the database sharding routing policy can also involve electronic devices directly activating the database sharding routing policy from the locally cached backup routing policy, using the source database as the routing target.

[0124] Understandably, modifying the database sharding routing strategy is the core action of the rollback operation, which enables the overall switching of read request distribution targets.

[0125] Step S45: Switch the service provider for the read request back from the target database to the source database.

[0126] It should be noted that after the electronic device modifies the preset database sharding routing strategy, subsequent read requests are distributed according to the modified database sharding routing strategy. That is, all read requests are distributed to the source database, which responds to these read requests and returns the query results. This realizes that the service provider for read requests is switched back from the target database to the source database.

[0127] Optionally, a rollback refers to switching the service provider of the read request back from the target database after the switch to the source database before the switch, that is, restoring the service state before the switch operation was performed.

[0128] Optionally, the rollback operation is an emergency operation triggered when an anomaly in the target database is detected in step S44. Its execution time window is extremely short, involving only the configuration modification of the database sharding routing strategy, without involving any data migration or replication operations, and therefore can be completed within seconds.

[0129] Optionally, since the electronic device continues to synchronously write the data carried by subsequent write requests to both the source and target databases after switching the service provider for read requests from the source database to the target database in step S4 (i.e., the dual-write mechanism is not disabled after the switch), the source database continues to receive the same incremental write data as the target database after the switch, and the data states of the two databases always remain strictly consistent. Based on this data consistency foundation, when the target database experiences an anomaly, switching the service provider for read requests back to the source database will not cause any data loss or data inconsistency, and the source database can completely and accurately handle all read requests.

[0130] Optionally, after the switchback is completed, the electronic device continues to synchronously write the data carried by the write request to the source database and the target database. The dual-write mechanism continues. After the target database resumes normal operation, the switching process from step S41 to step S43 can be executed again to switch the service provider of the read request from the source database to the target database again.

[0131] Understandably, this implementation method achieves second-level reversible switchback based on dual-write mechanism and database sharding routing strategy, enabling the database migration process to have reversible security protection capabilities. Once the new database encounters an anomaly, no complex data recovery operation is required. All read traffic can be switched back to the old database without loss within seconds simply by modifying the database sharding routing strategy. This greatly reduces the business risk of database switching, ensures business continuity, and achieves switching without time window restrictions.

[0132] For example, to help understand the implementation flow of the database switching method obtained by combining this embodiment with the above embodiments, please refer to... Figure 5 Specifically, it demonstrates how the database switching method of this application works in a real business system. Through the collaboration of the microservice center and the consumer component (Kafka consumer gateway), it achieves a smooth migration of read traffic and a continuous dual-write architecture for write traffic in three stages.

[0133] Before the switch: During this phase, read requests from business systems are uniformly distributed through the microservice center, which routes all read requests to the source database and the source database responds to the read operation.

[0134] During the switchover: This phase is a read traffic distribution transition period. Since the microservice center can only route read requests to a single database instance and cannot proportionally distribute different read requests to different databases simultaneously, read requests generated by the business system are no longer routed through the microservice center. Instead, they are written to a message queue and consumed by the corresponding first and second consumer components. These components then distribute the requests to the source and target databases according to a pre-defined database sharding routing strategy (e.g., splitting by the last digit of the customer number, adjusting weights, etc.). The receiving database instances then respond to their respective read requests, achieving a smooth proportional switchover of read traffic. Before and during the switchover, the first and second consumer components synchronously write data to their respective databases to ensure data consistency between the source and target databases even under continuous high-concurrency writes.

[0135] After the switchover: At this stage, all read traffic has been switched to the target database, and the database sharding routing strategy has converged to distribute all read requests to the target database. At this point, read requests are forwarded by the microservice center, which routes all read requests to the target database, where the target database responds. Simultaneously, the first and second consumer components continue to synchronously write data to the source and target databases, respectively. This dual-write mechanism continues to operate, ensuring that the source database continues to receive incremental write data even when it no longer bears read traffic, maintaining data consistency with the target database. This provides the data foundation for a seamless, second-level switchover.

[0136] Through the above three stages, the microservice center and the consumer component work together to achieve seamless migration of read traffic and continuous dual writing of write data, ensuring that read and write requests of the business system are not interrupted throughout the entire switching process.

[0137] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the database switching method of this application. Any simple variations based on this technical concept, such as the interaction and combination of various embodiments, are all within the protection scope of this application.

[0138] This application also provides a database switching device, please refer to... Figure 6 The database switching device includes: The writing module 10 is used to synchronously write the data carried by the write request to the source database and the target database when the received business request is a write request; The response module 20 is configured to send a first read request corresponding to the read request to the source database when the business request is a read request, and to send a second read request corresponding to the read request to the target database, wherein the source database responds to the first read request; The verification module 30 is used to verify the data synchronously written to the source database and the target database when performing data consistency verification, and to verify the data read from the source database based on the first read request and the data read from the target database based on the second read request. The read switching module 40 is used to respond to the first read request by the target database when the result of the data consistency verification meets the preset migration conditions, and to write the data carried by the write request into the target database when the running state of the target database meets the preset stability conditions, so as to complete the database switching.

[0139] The database switching device provided in this application, employing the database switching method in the above embodiments, can solve the technical problem of existing database switching affecting business continuity. Compared with the prior art, the beneficial effects of the database switching device provided in this application are the same as those of the database switching method provided in the above embodiments, and other technical features in the database switching device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0140] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the database switching method in the first embodiment described above.

[0141] The following is for reference. Figure 7 It shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of this application. Figure 7 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0142] like Figure 7As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0143] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0144] The electronic device provided in this application, employing the database switching method described in the above embodiments, can solve the technical problem of existing database switching affecting business continuity. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the database switching method provided in the above embodiments, and other technical features of the electronic device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0145] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0146] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0147] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the database switching method in the above embodiments.

[0148] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0149] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0150] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0151] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0152] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0153] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described database switching method, thereby solving the technical problem of existing database switching affecting business continuity. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the database switching method provided in the above embodiments, and will not be repeated here.

[0154] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the database switching method described above.

[0155] The computer program product provided in this application can solve the technical problem of business continuity being affected by existing database switching. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the database switching method provided in the above embodiments, and will not be repeated here.

[0156] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A database switching method, characterized in that, The database switching method includes: When the received business request is a write request, the data carried by the write request is synchronously written to the source database and the target database; When the service request is a read request, a first read request corresponding to the read request is sent to the source database, and a second read request corresponding to the read request is sent to the target database, wherein the source database responds to the first read request; When performing data consistency verification, the data synchronously written to the source database and the target database is verified, as are the data read from the source database based on the first read request and the data read from the target database based on the second read request. When the result of the data consistency verification meets the preset migration conditions, the target database responds to the first read request, and when the operating status of the target database meets the preset stability conditions, the data carried by the write request is written to the target database to complete the database switch.

2. The method as described in claim 1, characterized in that, The step of verifying the data read from the source database based on the first read request and the data read from the target database based on the second read request includes: Obtain the first query result returned by the source database based on the first read request; Obtain the second query result returned by the target database based on the second read request; The first query result and the second query result are compared to obtain the first verification result.

3. The method as described in claim 2, characterized in that, The step of verifying the data synchronously written to the source database and the target database includes: Based on the write request, determine the first total amount of data to be written to the source database and the second total amount of data to be written to the target database within a preset period; The first total data volume and the second total data volume are compared to obtain the second verification result.

4. The method as described in claim 3, characterized in that, After the step of verifying the data synchronously written to the source database and the target database, the method further includes: After each preset period ends, the data in the source database and the data in the target database are compared field by field to obtain a third verification result.

5. The method as described in claim 4, characterized in that, After performing data consistency verification, the method further includes: When any verification result indicates that there is a difference in data between the source database and the target database, the missing data in the target database compared to the source database is determined, wherein the verification result includes the first verification result, the second verification result and the third verification result; The missing data is retrieved from the source database and added to the target database.

6. The method as described in claim 1, characterized in that, The step of the target database responding to the first read request includes: Obtain a preset database sharding routing strategy, wherein the database sharding routing strategy is the routing rule for read requests; According to the database sharding routing strategy, the first read request is distributed to the source database and the target database, so that the source database responds to the read request distributed to the source database, and the target database responds to the read request distributed to the target database. During the preset transition period, the database routing strategy is dynamically adjusted to gradually increase the number of read requests distributed to the target database and correspondingly reduce the number of read requests distributed to the source database until all read requests are distributed to the target database.

7. The method as described in claim 1, characterized in that, Following the step of the target database responding to the first read request, the method further includes: When an abnormal running status of the target database is detected, the preset database sharding routing strategy is modified, wherein the database sharding routing strategy is the routing rule for read requests; The service provider for the read request will be switched back from the target database to the source database.

8. A database switching device, characterized in that, The database switching device includes: The write module is used to synchronously write the data carried by the write request to the source database and the target database when the received business request is a write request; The response module is configured to send a first read request corresponding to the read request to the source database and a second read request corresponding to the read request to the target database when the business request is a read request, wherein the source database responds to the first read request; The verification module is used to verify the data synchronously written to the source database and the target database when performing data consistency verification, and to verify the data read from the source database based on the first read request and the data read from the target database based on the second read request. The read switching module is used to respond to the first read request by the target database when the result of the data consistency verification meets the preset migration conditions, and to write the data carried by the write request into the target database when the running state of the target database meets the preset stability conditions, so as to complete the database switching.

9. An electronic device, characterized in that, The electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the database switching method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the database switching method as described in any one of claims 1 to 7.

Images