Master-slave database switching method, device, equipment and product

Abstract

The application discloses a kind of master-slave database switching method, device, equipment and product, related to fault switching technical field, method is applied to business system, the method includes receiving traffic request;According to the database mapping table constructed in advance, the traffic request is allocated to database by routing application, and the response database set is obtained, the initial master database in the response database set is detected for failure;In the case where the initial master database is detected to fail, the standby database of the response database set is delayed the lowest as final master database, and the traffic request is handled by the final master database.Thereby, the problem that static fragmentation architecture failure cannot realize automatic database switching, leading to business interruption, is solved, and the efficiency of master-slave database switching is improved.

Description

Technical Field

[0001] This application relates to the field of fault switching technology, and in particular to a method, apparatus, device, and product for switching between primary and backup databases. Background Technology

[0002] In distributed database business scenarios, a routing-based database architecture based on static sharding is a common deployment method. This architecture uses preset rules such as user ID hash modulo to statically configure the mapping relationship between data shards and physical databases, thereby achieving horizontal data partitioning and storage. Some systems are supplemented with a master-slave architecture with one master and one slave or one master and multiple slaves to improve the availability of a single database. This type of architecture is simple to implement and easy to deploy. The business layer directly accesses the corresponding database according to fixed rules, which can meet the basic data storage and access needs of regular business.

[0003] However, this static sharding architecture has obvious drawbacks. When a sharding node fails, it cannot automatically perform failover and sharding redistribution. The routing configuration must be manually modified, which can easily cause business service interruption and cannot meet the automatic disaster recovery requirements of high-concurrency and high-availability distributed systems.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, apparatus, device, and product for primary and backup database switching, which aims to solve the technical problem that the failure of static sharding architecture to achieve automatic database switching leads to business interruption.

[0006] To achieve the above objectives, this application proposes a primary / standby database switching method, which is applied to a business system and includes: Receive traffic requests; Based on a pre-built database mapping table, the traffic requests are allocated to databases through a routing application to obtain a response database set, and fault detection is performed on the initial master database in the response database set. If a failure is detected in the initial primary database, the backup database with the lowest latency in the response database set is selected as the final primary database, and the traffic request is processed through the final primary database.

[0007] In one embodiment, before the step of allocating the traffic request to a response database set through a routing application based on a pre-built database mapping table, the method further includes: The number of physical database partitions is determined based on the business concurrency and storage capacity requirements of the business system. The number of virtual shards is determined based on the number of physical database shards and the routing balance of the business system. The mapping relationship between virtual shards, physical shards, and primary / standby databases is determined based on the number of physical shards and the number of virtual shards. A ring mapping relationship is constructed based on the cross-backup rules of the primary and backup storage databases; A database mapping table is constructed based on the mapping relationships between the virtual shards, physical databases, primary and backup databases, and the ring mapping relationship.

[0008] In one embodiment, the step of allocating the traffic requests to a response database set through a routing application based on a pre-built database mapping table includes: The routing application obtains the mapping relationships between virtual shards, physical databases, and primary / standby databases in the database mapping table. The target virtual shard is determined based on the traffic request. The target virtual shard is matched according to the mapping relationship between the virtual shard, physical database, and primary and backup databases to obtain the initial primary database and several backup databases. The initial primary database and several backup databases are integrated to obtain a response database set.

[0009] In one embodiment, the step of fault detection on the initial master database of the response database set includes: The initial master database is detected by the basic resource layer to obtain the CPU utilization and memory utilization of the initial master database; The initial master database is queried through the underlying data layer, and the response latency corresponding to the query statement is calculated. The response delay is timed out based on the response threshold to obtain the judgment result; The business layer simulates the transaction operation of the traffic request and calculates the transaction failure rate of the transaction operation; Based on the CPU utilization, memory utilization, judgment results, and transaction failure rate, a comprehensive fault detection is performed to obtain the detection results.

[0010] In one embodiment, after the step of allocating the traffic request to a database via a routing application to obtain a response database set, the method further includes: The business data corresponding to the traffic request is synchronized to the several backup databases through a data dual-write mechanism. When the writing of the several backup databases is completed, a global incrementing version number is generated and the global incrementing version number is loaded into the message queue; Duplicate data is determined by analyzing the historical globally incrementing version numbers in the message queue to obtain the determination result; If the determination result is that there is no duplicate data, then the data in the several backup databases is determined to be consistent with the data in the initial master database.

[0011] In one embodiment, the step of selecting the backup database with the lowest latency in the response database set as the final primary database and processing the traffic request through the final primary database when a failure of the initial primary database is detected includes: When an initial primary database failure is detected, the initial primary database is marked as unavailable, and the standby database with the lowest latency in the response database set is promoted to the final primary database; Based on the database mapping table, several backup databases for the final primary database are determined; The database mapping table is updated through the final master database and several backup databases, and the traffic requests are processed through the final master database.

[0012] In one embodiment, after the steps of updating the database mapping table through the final primary database and several backup databases, and processing the traffic request through the final primary database, the method further includes: After the initial primary database is recovered from the failure, the data in the initial primary database is synchronized to obtain the supplementary data; The completed data is subjected to a consistency check to obtain the consistency check result; After the consistency verification result passes, the database mapping table is restored to its initial deployment state, and redundant data is cleaned up.

[0013] Furthermore, to achieve the above objectives, this application also proposes a primary / standby database switching device, which is applied to a business system and includes: The receiving module is used to receive traffic requests; The detection module is used to allocate the traffic requests to a database according to a pre-built database mapping table through a routing application to obtain a response database set, and to perform fault detection on the initial main database in the response database set. The processing module is configured to, in the event of a failure of the initial primary database, select the backup database with the lowest latency in the response database set as the final primary database, and process the traffic request through the final primary database.

[0014] In addition, to achieve the above objectives, this application also proposes a primary / backup database switching device, the 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 primary / backup database switching method described above.

[0015] 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 when the computer program is executed by a processor, it implements the steps of the primary / backup database switching method described above.

[0016] 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 primary / backup database switching method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This application proposes a primary / backup database switching method, apparatus, device, and product. The method, applied to a business system, includes receiving traffic requests; allocating databases to the traffic requests via a routing application based on a pre-built database mapping table to obtain a response database set; performing fault detection on the initial primary database in the response database set; and, if a fault is detected in the initial primary database, designating the backup database with the lowest latency in the response database set as the final primary database, and processing the traffic requests through the final primary database. Thus, by automatically allocating traffic to the initial primary database for processing via a routing application based on the database mapping table and continuously performing fault detection on the initial primary database, no manual intervention is required. Once a primary database fault is detected, the backup database with the lowest latency is immediately and automatically upgraded to the final primary database and takes over the traffic, completing the entire fault switch automatically without manual modification of routing configurations. This avoids business interruption, solves the problem of static sharding architectures failing to achieve automatic database switching, leading to business interruption, and improves the efficiency of primary / backup database switching. Attached Figure Description

[0018] 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.

[0019] 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.

[0020] Figure 1 This is a flowchart illustrating an embodiment of the primary / backup database switching method in this application. Figure 2 This is a schematic diagram illustrating the data processing logic of the standby database synchronizing with the primary database in the primary database switching method of this application. Figure 3 This is a flowchart illustrating Embodiment 2 of the primary / backup database switching method of this application; Figure 4 A simplified flowchart illustrating the primary / standby database switching method provided in Embodiment 2 of this application; Figure 5 This is a schematic diagram of the module structure of the primary / backup database switching device according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the primary / backup database switching method in this application embodiment.

[0021] 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

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] 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.

[0024] The main solution of this application embodiment is as follows: The number of physical databases is determined based on the business concurrency and storage capacity requirements of the business system; the number of virtual shards is determined based on the number of physical databases and the routing balance of the business system; the mapping relationship between virtual shards, physical databases, and primary / standby databases is determined based on the number of physical databases and virtual shards; a ring mapping relationship is constructed based on the cross-backup rules of the primary / standby databases; a database mapping table is constructed based on the mapping relationship between virtual shards, physical databases, and primary / standby databases, as well as the ring mapping relationship. The mapping relationship between virtual shards, physical databases, and primary / standby databases in the database mapping table is obtained through the routing application; the target virtual shard is determined based on the traffic request; the target virtual shard is matched according to the mapping relationship between virtual shards, physical databases, and primary / standby databases to obtain an initial primary database and several standby databases; the initial primary database and several standby databases are integrated to obtain a response database set. The initial master database is monitored at the basic resource layer to obtain its CPU and memory utilization. A query statement is executed on the initial master database at the data layer, and the response latency corresponding to the query statement is calculated. A timeout judgment is performed on the response latency based on a response threshold to obtain a judgment result. The transaction operation of the traffic request is simulated at the business layer, and the transaction failure rate of the transaction operation is calculated. A comprehensive fault detection is performed based on the CPU utilization, memory utilization, judgment result, and transaction failure rate to obtain a detection result. The business data corresponding to the traffic request is synchronized to several backup databases through a dual-write mechanism. When the writing to the several backup databases is completed, a globally incrementing version number is generated and loaded into a message queue. The historical globally incrementing version numbers in the message queue are checked for duplicate data to obtain a determination result. If the determination result indicates that there is no duplicate data, then the data in the several backup databases is determined to be consistent with the data in the initial master database. Upon detecting an initial primary database failure, the initial primary database is marked as unavailable, and the standby database with the lowest latency in the response database set is upgraded to the final primary database. Several backup standby databases are determined based on the database mapping table. The database mapping table is updated using the final primary database and the several backup standby databases, and the traffic requests are processed through the final primary database. After the initial primary database recovers from the failure, data synchronization is performed on the initial primary database to obtain supplementary data. Consistency verification is performed on the supplementary data to obtain a consistency verification result. After the consistency verification result passes, the database mapping table is restored to its initial deployment state, and redundant data is cleaned up. This solves the problem of business interruption caused by the inability to automatically switch databases in static sharded architecture failures, realizes the switching between primary and standby databases, and improves the efficiency of primary and standby database switching.Based on the solution of this invention, starting from the problem that the architecture is simple to implement and easy to deploy, and the business layer can directly access the corresponding database according to fixed rules, which can meet the basic data storage and access needs of regular business, but the efficiency of automatic switching is low, a master-slave database switching method is designed. The effectiveness of the master-slave database switching method of this invention is verified when switching between master and slave databases. Finally, the efficiency of master-slave database switching is significantly improved by the method of this invention.

[0025] In this embodiment, for ease of description, the primary and backup database switching device will be used as the execution subject for the following description.

[0026] Due to inherent defects in the static sharding routing architecture of existing technologies, the reliability and continuity of master-slave database switching still need to be guaranteed. One issue is the automatic failover problem: when a sharding node fails, automatic switching and sharding reallocation are not possible, requiring manual modification of routing configurations, which leads to business interruption and low switching efficiency. Another issue is fault perception: relying solely on heartbeat detection cannot identify hidden faults such as latency and transaction anomalies, and the detection dimension is too limited, significantly reducing the accuracy and timeliness of master-slave switching. Furthermore, there is the data synchronization problem: the master-slave database synchronization mechanism is imperfect, and data loss or inconsistency can easily occur during switching, which also affects continuous database service. Therefore, in traditional sharding architectures, elastic scaling capabilities also have significant shortcomings. Fixed sharding rules cannot be dynamically adjusted with business load, easily causing resource waste or performance bottlenecks, making it difficult to meet the automatic disaster recovery and elastic scaling requirements of high availability and high concurrency scenarios.

[0027] This application provides a solution that automatically allocates traffic to the initial primary database for processing through a routing application based on a database mapping table, and continuously performs fault detection on the initial primary database without manual intervention. Once a primary database failure is detected, the backup database with the lowest latency is immediately and automatically upgraded to the final primary database and takes over the traffic. The entire fault switch is completed automatically without manual modification of the routing configuration, thereby avoiding business interruption. This solves the problem that static sharding architecture cannot achieve automatic database switching due to failure, resulting in business interruption, and improves the efficiency of primary and backup database switching.

[0028] Based on this, this application provides a method for switching between primary and backup databases, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the primary / backup database switching method of this application.

[0029] In this embodiment, the primary / standby database switching method is applied to a business system, and the primary / standby database switching method includes steps S01~S03: Step S01: Receive traffic request; Before the implementation of this embodiment, it should be clear that in distributed database business scenarios, the routing database architecture based on static sharding is a common deployment method. This type of architecture is simple to implement and convenient to deploy. With this architecture, the business layer can directly access the corresponding database according to fixed rules, which can meet the basic data storage and access needs of regular business. However, this type of architecture cannot be dynamically adjusted with the business load, which can easily lead to resource waste or performance bottlenecks and make it difficult to meet the automatic disaster recovery and elastic expansion requirements of high-concurrency and high-availability distributed systems.

[0030] Therefore, in order to solve the above problems, the business system receives various traffic requests initiated from outside through the gateway service, or it can take over the traffic forwarding through a separately deployed routing application service. The received traffic requests include various business-related requests such as business operation instructions and data query requirements, ensuring the integrity and real-time performance of request transmission.

[0031] Step S02: Based on the pre-built database mapping table, the traffic request is allocated to a database through the routing application to obtain a response database set, and the initial master database in the response database set is subjected to fault detection. The routing application obtains a pre-built database mapping table from the metadata service. This mapping table contains the correspondence between virtual shards, physical databases, and primary and standby databases. It determines the target virtual shard based on the business characteristics of the traffic request, matches the initial primary database and the corresponding standby database, and integrates them into a response database set. The initial primary database performs the business processing of the traffic request. At the same time, a multi-dimensional fault detection mechanism is started to monitor the running status of the initial primary database in real time.

[0032] Step S03: If a failure is detected in the initial primary database, the backup database with the lowest latency in the response database set is selected as the final primary database, and the traffic request is processed through the final primary database.

[0033] When the multi-dimensional fault detection mechanism detects an anomaly in the initial primary database, it immediately triggers the failover process. It performs real-time detection and sorting of the replication latency of all backup databases in the response database set, selects the backup database with the lowest latency to upgrade to the final primary database, and quickly switches all traffic requests to the final primary database for processing, ensuring uninterrupted business services.

[0034] Specifically, before step S02 above, which involves allocating the traffic request to a database based on a pre-built database mapping table through a routing application to obtain the response database set, the method further includes: Step S0201: Determine the number of physical database partitions based on the business concurrency and storage capacity requirements of the business system; Step S0202: Determine the number of virtual shards based on the number of physical database shards and the routing balance of the business system; Step S0203: Determine the mapping relationship between virtual shards, physical shards, and primary / standby databases based on the number of physical shards and the number of virtual shards; Step S0204: Construct a ring mapping relationship according to the cross-backup rules of the primary and backup storage databases; Step S0205: Based on the mapping relationship between the virtual shards, physical databases, and primary / standby databases, as well as the ring mapping relationship, a database mapping table is constructed.

[0035] First, historical business concurrency data for the past 3-6 months is collected through the operation and maintenance management platform, including peak concurrency, average concurrency, and low concurrency. Combined with the business department's business growth expectations for the next 1-2 years, and taking into account key indicators such as the growth rate of data storage capacity and data read / write frequency, a load balancing algorithm is used to reasonably determine the number of physical database shards. Typically, the number of physical database shards is set to 4-16 to ensure that the physical database shards can stably bear the existing and potential business loads and avoid single database overload.

[0036] Subsequently, based on the determined number of physical database shards and the routing balance requirements of the business system, the number of virtual shards is set. The number of virtual shards is usually 2-8 times the number of physical database shards, and must be an integer power of 2 to achieve more flexible routing scheduling and load balancing, and avoid sharding issues.

[0037] Based on the number of physical databases and virtual shards, a hash mapping algorithm is used to establish the correspondence between virtual shards and physical databases. Each physical database corresponds to multiple virtual shards. At the same time, a corresponding primary and standby database is configured for each physical database. The primary and standby databases use the same hardware configuration and the ownership relationship and data synchronization rules of each primary and standby database are clearly defined.

[0038] Based on the cross-backup rules of the primary and backup databases, a ring mapping relationship is constructed, so that each physical database serves as both the primary database for a virtual shard and the backup database for two other adjacent virtual shards, forming a closed-loop mutual backup system. This ensures symmetrical and unskewed data distribution and improves the system's disaster recovery capabilities. The mapping relationships of virtual shards, physical databases, and primary / backup databases are integrated with the ring mapping relationship to form a complete database mapping table. The mapping table contains fields such as shard information, database address, primary / backup identifier, and synchronization status. It is maintained in a distributed manner by a metadata service (which can use Zookeeper or Etcd), and the mapping table information is updated in real time to ensure that all routing applications can obtain the latest mapping relationship.

[0039] The mapping relationship between virtual shards, physical databases, and primary / standby databases is illustrated below: Assuming there are 8 virtual shards, if there are 4 physical databases, the mapping ratio between virtual shards and physical databases is 2:1; if there are 8 physical databases, the mapping ratio is 1:1. Assuming 8 physical databases, the initial mapping table between virtual shards and physical databases is shown in Table 1 below:

[0040] Table 1 An example of a database mapping table is as follows: For instance, if there are 8 virtual shards and 8 physical databases, with each physical master database corresponding to 2 standby databases, to ensure 100% utilization of hardware resources, each physical database in the horizontal sharding architecture needs to simultaneously assume the roles of master and standby databases in the vertical high-availability architecture. That is, each physical database simultaneously serves as the master database for one virtual shard and as the standby database for two other virtual shards. A cross-backup ring mapping relationship is designed. This ring mapping design has good scalability; when expanding, only a new ring group needs to be added (e.g., adding 8 physical databases to form a new ring when expanding to 16 virtual shards). Moreover, the data distribution is completely symmetrical, and there will be no data skew causing bottlenecks on a single node. Combined with virtual shards, the initial mapping relationship between the three is shown in Table 2 below:

[0041] Table 2 More specifically, step S02 above, which involves allocating the traffic requests to a database based on a pre-built database mapping table to obtain a response database set via a routing application, includes: Step S021: Obtain the mapping relationship between virtual shards, physical databases, and primary / standby databases in the database mapping table through the routing application; Step S022: Determine the target virtual shard based on the traffic request, and match the target virtual shard according to the mapping relationship between the virtual shard, physical database, and primary / standby database to obtain the initial primary database and several standby databases; Step S023: Integrate the initial primary database and several backup databases to obtain a response database set.

[0042] First, the routing application establishes a long connection with the metadata service, sets a fixed refresh period (usually 100 milliseconds), periodically retrieves the latest database mapping table from the metadata service, and listens for changes to the mapping table. If the mapping table is updated, the latest version is immediately retrieved, and the complete mapping relationship between virtual shards, physical databases, and primary / standby databases is extracted, including information such as virtual shard ID, physical database IP address, port number, primary / standby identifier, and data storage range, to ensure the accuracy of route allocation. The system performs deep analysis on received traffic requests to extract business identification information (such as user ID, order ID, business type, etc.). Combined with preset logical sharding rules (such as user ID hash modulo, order time range sharding, etc.), the system calculates the target virtual shard corresponding to the traffic request using either a hash algorithm or a range matching algorithm. This ensures that the request volume of each virtual shard tends to be balanced. Specifically, the calculation process involves first extracting the business identification information from the traffic request as input parameters for the algorithm. If a hash algorithm is used, the extracted business identification is hashed to obtain a hash value, which is then moduloed by the total number of virtual shards. The result is the target virtual shard ID, corresponding to the target virtual shard. If a range matching algorithm is used, the extracted business identification belongs to a specific range according to preset business identification range rules; the shard corresponding to that range is the target virtual shard. Both algorithms pass preset load balancing checks. If the request volume of a virtual shard exceeds a threshold, the algorithm parameters are dynamically adjusted to ensure that the request volume of each virtual shard tends to be balanced.

[0043] Subsequently, based on the correspondence between virtual shards and physical databases, and primary and standby databases in the database mapping table, the target virtual shard is precisely matched to find the initial primary database corresponding to the virtual shard. At the same time, all standby databases corresponding to the primary database are filtered out. The number of standby databases can be flexibly configured according to the high availability requirements of the business. Usually, two standby databases are configured to form a "one primary and two standby" high availability architecture.

[0044] The initial primary database obtained by matching is integrated with all standby databases. The core processing role of the initial primary database (responsible for the main read and write operations) and the redundant backup role of the standby databases (responsible for data synchronization and failover) are clarified. The running status and connection information of each database are recorded to obtain the response database set, which provides a solid foundation for subsequent traffic processing and failover.

[0045] Further, step S02 above, the step of fault detection of the initial master database in the response database set, includes: Step S024: The initial master database is detected through the basic resource layer to obtain the CPU utilization and memory utilization of the initial master database; Step S025: Execute a query statement on the initial main database through the underlying data layer, and calculate the response latency corresponding to the query statement; Step S026: Based on the response threshold, perform a timeout judgment on the response delay to obtain a judgment result; Step S027: Simulate the transaction operation of the traffic request through the business layer and calculate the transaction failure rate of the transaction operation; Step S028: Perform comprehensive fault detection based on the CPU utilization rate, memory utilization rate, judgment result, and transaction failure rate to obtain the detection result.

[0046] Set a reasonable response latency threshold and adjust it flexibly according to different business scenarios. It is usually set to 800 milliseconds. For core businesses with high concurrency and low latency, the threshold can be adjusted to 500 milliseconds.

[0047] The underlying data layer sends a standard query statement (such as querying the basic information of a specified user) to the initial master database. The query statement initiation time and response time are recorded, and the difference between the two is calculated to obtain the query response latency. The calculated initial master database query response latency is compared with this threshold. If the response latency exceeds the threshold, and the number of requests exceeding the threshold within a preset time period (such as 10 seconds) reaches the set upper limit (such as 3 times), it is judged as an abnormal database response; otherwise, it is judged as normal.

[0048] The system counts the total number of simulated transaction operations and the number of failures within a preset time period (e.g., 60 seconds). Transaction operations include core operations such as data writing, updating, and deleting. The transaction failure rate is obtained by dividing the number of failures by the total number of failures. A preset transaction failure rate threshold (usually 1%) is set. If the actual failure rate exceeds this threshold and the duration reaches the preset duration (e.g., 5 seconds), it is determined to be a transaction processing anomaly.

[0049] The CPU utilization and memory utilization are compared with preset resource usage thresholds (CPU utilization threshold is usually 80%, and memory utilization threshold is usually 85%). Combined with the results of response latency assessment and transaction failure rate assessment, a multi-dimensional comprehensive analysis is performed. A weighted scoring method is used to score each indicator. If any indicator exceeds the corresponding threshold and persists for a preset duration (e.g., 3 seconds), the initial primary database is considered to have failed. The output includes the fault type, fault indicators, and fault duration. If all indicators are within the normal range, the initial primary database is considered to be functioning correctly. The system operates normally and is continuously monitored in real time. The specific steps of the weighted scoring method are as follows: First, the weights of each indicator are preset, with CPU utilization rate weighted at 30%, memory utilization rate weighted at 30%, response latency judgment result weighted at 20%, and transaction failure rate judgment result weighted at 20%. Then, for each indicator, a value is assigned based on the deviation of the actual detected value from the threshold (100 points for normal state, 60-80 points for slight deviation, and 0-40 points for severe deviation). Subsequently, the scores of each indicator are multiplied by their corresponding weights and summed to obtain a comprehensive score. Finally, the status of the master database is determined based on the comprehensive score.

[0050] Furthermore, after step S02 above, where the routing application allocates the traffic request to a database to obtain a response database set, the method further includes: Step S0206: Synchronize the business data corresponding to the traffic request to the several backup databases through a data dual-write mechanism; Step S0207: When the writing of the several backup databases is completed, a global incrementing version number is generated and the global incrementing version number is loaded into the message queue. Step S0208: Duplicate data is determined for the historical globally incrementing version numbers in the message queue to obtain the determination result; Step S0209: When the determination result is that there is no duplicate data, it is determined that the data in the several backup databases is consistent with the data in the initial master database.

[0051] like Figure 2 As shown, after the initial primary database finishes processing the business data corresponding to the traffic request, it immediately starts the dual-write mechanism. This mechanism adopts a synchronous write method. While writing the business data to its own local transaction log (such as MySQL's binlog log), it simultaneously sends the data to all backup databases through a dedicated synchronous channel. The synchronous channel adopts an encrypted transmission method to ensure the security of data transmission and prevent data leakage or tampering.

[0052] After all standby databases return confirmation messages indicating successful data writes, a globally incrementing version number is generated based on a customized Snowflake algorithm. This version number includes a 1-bit sign bit (fixed to 0), a 41-bit millisecond-level timestamp (accurate to milliseconds, supporting a time span of 69 years), a 10-bit virtual shard ID (supporting 1024 virtual shards), a 3-bit replica field (used to distinguish between the primary and standby databases; the primary database is identified as 001, and the standby databases as 002 and 003 respectively), and a 10-bit sequence number (used to distinguish different data synchronization requests within the same millisecond, supporting 1024 concurrent requests), ensuring that each version number is unique and incrementing. The generated globally incrementing version number is then associated with the corresponding business data, data write time, database identifier, and other information, and loaded into a message queue (such as RabbitMQ or Kafka) for persistent storage. Simultaneously, the version number is written to the local transaction logs of both the primary and standby databases for subsequent data traceability and consistency verification.

[0053] Each backup database periodically pulls a globally incrementing version number from the message queue and compares it with the latest processed version number (i.e., the watermark) recorded locally. If the pulled version number is less than or equal to the local watermark, it is determined to be duplicate data and is discarded directly; if it is greater than the local watermark, it is determined to be valid data, the local watermark is updated and the corresponding data is synchronized, thus completing the determination of duplicate data.

[0054] When the result confirms that there is no duplicate data, it means that the standby database has successfully synchronized the business data of the primary database, and the data is free of redundancy, missing data, and errors. At this point, it can be determined that the data in all standby databases is consistent with the data in the initial primary database, effectively ensuring the consistency of primary and standby data and providing a reliable data foundation for subsequent failover.

[0055] This embodiment, through the above-described scheme, specifically involves receiving traffic requests; allocating databases to the traffic requests using a routing application based on a pre-built database mapping table to obtain a response database set; performing fault detection on the initial primary database in the response database set; and, if a fault is detected in the initial primary database, designating the backup database with the lowest latency in the response database set as the final primary database, and processing the traffic requests through the final primary database. Thus, the routing application automatically allocates traffic to the initial primary database for processing based on the database mapping table and continuously performs fault detection on the initial primary database without manual intervention. Once a primary database fault is detected, the backup database with the lowest latency is immediately and automatically promoted to the final primary database and takes over the traffic, completing the entire fault switch automatically without manual modification of routing configurations. This avoids business interruption and solves the problem of static sharding architectures failing to achieve automatic database switching, leading to business interruption, thus improving the efficiency of primary / backup database switching.

[0056] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 In step S03, where a failure is detected in the initial primary database, the backup database with the lowest latency in the response database set is selected as the final primary database, and the traffic request is processed through the final primary database, the primary / backup database switching method further includes steps S031-S033: Step S031: When an initial primary database failure is detected, the initial primary database is marked as unavailable, and the backup database with the lowest latency in the response database set is upgraded to the final primary database. Step S032: Determine several backup databases for the final master database according to the database mapping table; Step S033: Update the database mapping table through the final master database and several backup databases, and process the traffic request through the final master database.

[0057] After the multi-dimensional fault detection mechanism outputs the detection results of the initial primary database failure, the system immediately triggers the fault isolation process, marks the initial primary database as unavailable, updates its status flag in the database mapping table, and prohibits the routing application from allocating any traffic requests to it, so as to prevent the fault from spreading to other database nodes.

[0058] At the same time, the system sends detailed fault alarm information to the operation and maintenance management platform, including the fault node IP, fault type, fault time, fault indicators, etc., so that operation and maintenance personnel can troubleshoot the fault in a timely manner.

[0059] Subsequently, the backup database screening process is initiated, and the replication latency of all backup databases in the response database set is monitored in real time. By comparing the binlog log synchronization progress and data difference between each backup database and the initial master database, the replication latency of each backup database is calculated. The latency times are sorted in ascending order, and the backup database with the lowest latency and normal operating status (CPU, memory, and response speed are all within the normal range) is selected and upgraded to the final master database. Its role identifier in the database mapping table is updated to clarify its role as the master database.

[0060] Based on the circular mapping relationship in the database mapping table, a physical database with the same hardware configuration and running status as the final primary database is selected from the next adjacent virtual shard to the virtual shard to which the final primary database belongs. The number of backup databases is consistent with the number of original backup databases to ensure that the configuration of backup databases complies with the cross-backup rules and to ensure the integrity of the high availability architecture.

[0061] The role of the final primary database, the ownership of the backup database, and its status identifier are synchronously updated to the database mapping table. The metadata service synchronizes this updated information in real time to ensure that all routing applications can obtain the latest mapping relationship in a timely manner. At the same time, the final primary database continuously processes all traffic requests and uses a transaction caching mechanism to handle requests that are not completed during the switchover process, maintaining the continuity and stability of business services.

[0062] Specifically, after step S03 above, which involves updating the database mapping table through the final primary database and several backup databases, and processing the traffic request through the final primary database, the method further includes: Step S04: After the initial master database is recovered from the failure, the initial master database is synchronized to obtain the supplementary data; Step S05: Perform a consistency check on the supplemented data to obtain the consistency check result; Step S06: After the consistency verification result passes, restore the database mapping table to the initial deployment state and clean up redundant data.

[0063] After the initial primary database failure is resolved and restored to normal operation, the operations and maintenance personnel send a data synchronization command through the operations and maintenance management platform. The system determines the data source for data synchronization based on the role of the primary database and its corresponding backup database before the failure, and prioritizes data synchronization from the primary database of the current corresponding virtual shard (i.e., the new primary database corresponding to the initial primary database before the failure) to avoid affecting the normal operation of other business nodes.

[0064] Data synchronization supports two methods: full synchronization and differential data recovery. When the new master database has low business pressure (CPU utilization is below 60%), the full synchronization method is used to completely synchronize all data in the new master database to the recovered initial master database. When the new master database has high business pressure (CPU utilization is above 60%), the differential data recovery method is used. By comparing the last global incrementing version number of the initial master database before the failure with the current version number of the new master database, only the data missing during the failure is synchronized, reducing the amount of data to be synchronized, shortening the synchronization time, and obtaining the missing data.

[0065] A comprehensive consistency check is performed on the supplemented data, using a two-way comparison mechanism to compare the supplemented data in the initial master database with the data in the data source database. The focus is on checking the continuity of the global incremental version number, the completeness and accuracy of the business data, and the standardization of the data format. At the same time, the integrity of the transaction log is checked to ensure that there is no missing data, no data errors, and no format deviations.

[0066] If the consistency check passes, it means that the initial primary database has been restored to a normal data state and is running stably. Within the preset maintenance window (usually during off-peak business hours, such as 2:00-4:00 AM), the database mapping table is updated to the initial deployment state before the failure, the initial mapping relationship of each virtual shard, physical shard, and primary / standby database is restored, and the role identifiers and status information of each database are updated.

[0067] Redundant data generated in the physical shards that temporarily act as backup databases during failover is cleaned up. Data unrelated to the current virtual shard, temporary cached data, and expired log data are deleted to release storage resources, optimize database performance, and ensure the high efficiency and stability of the database cluster. At the same time, a data cleanup report is generated and maintenance records are retained.

[0068] This embodiment, through the above-described scheme, specifically marks the initial primary database as unavailable upon detecting a failure, and upgrades the backup database with the lowest latency in the response database set to the final primary database. Several substitute backup databases are determined based on the database mapping table. The database mapping table is updated using the final primary database and the several substitute backup databases, and the traffic request is processed by the final primary database. Thus, the routing application automatically allocates traffic to the initial primary database for processing based on the database mapping table and continuously detects faults in the initial primary database without manual intervention. Once a primary database failure is detected, the backup database with the lowest latency is immediately and automatically upgraded to the final primary database and takes over the traffic. The entire fault switchover is completed automatically without manual modification of the routing configuration, thereby avoiding business interruption. This solves the problem of static sharding architecture failures preventing automatic database switching and causing business interruption, and improves the efficiency of primary / backup database switching.

[0069] For example, to help understand the implementation flow of the primary / standby database switching method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 4 , Figure 4 A simplified flowchart of a primary / standby database failover method is provided, specifically: The business system receives various external traffic requests through the front-end gateway. The gateway first verifies the legitimacy of the requests and filters for malicious attacks. After ensuring the security of the requests, it forwards the requests to the routing application.

[0070] The routing application obtains a pre-built database mapping table from the metadata service. This mapping table integrates the mapping relationship between virtual shards, physical databases, and primary and secondary databases, as well as the ring cross-backup relationship. It includes core information such as shard ID, database address, primary and secondary identifier, and synchronization status. The routing application maintains a long connection with the metadata service to synchronize the mapping table updates in real time.

[0071] The routing application performs deep analysis on traffic requests, extracts business identification information, calculates target virtual shards based on preset sharding rules, accurately matches the initial primary database and several backup databases according to the mapping table, integrates them into a response database set, and prioritizes the processing of traffic requests by the initial primary database. At the same time, a multi-dimensional fault detection mechanism is activated, which collects the CPU utilization and memory utilization of the initial primary database in real time from the basic resource layer, executes query statements and calculates response latency from the data layer, simulates transaction operations and calculates transaction failure rate from the business layer, and judges the operating status of the primary database through multi-dimensional comprehensive analysis.

[0072] After the primary database finishes processing the business data, it initiates a dual-write mechanism to synchronously write the data to its own transaction log and all standby databases. Once all standby databases have finished writing, a unique globally incrementing version number is generated based on a customized Snowflake algorithm. This version number is then associated with the business data and loaded into the message queue. Each standby database compares the version number with its local watermark to filter duplicate data and ensure consistency between the primary and standby databases.

[0073] When an initial primary database failure is detected, it is immediately marked as unavailable and a failure alarm is sent. The replication latency of all standby databases in the response database set is detected and sorted. The standby database with the lowest latency is selected to be upgraded to the final primary database. A backup standby database is selected based on the ring mapping relationship. The database mapping table is updated and synchronized to all routing applications. The final primary database quickly takes over all traffic requests to ensure uninterrupted business operations.

[0074] After the initial primary database is recovered from the failure, full or differential synchronization is performed based on the data in the new primary database to obtain the supplementary data. Consistency verification is performed through bidirectional comparison. After the verification passes, the database mapping table is restored to the initial deployment state during the maintenance window during off-peak business periods, and redundant data is cleaned up. The entire process realizes automatic switching, data synchronization and cluster recovery of primary and backup databases without manual intervention, effectively meeting the automatic disaster recovery and elastic scaling requirements of high-concurrency and high-availability distributed systems.

[0075] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the primary and backup database switching method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0076] This application also provides a primary / standby database switching device; please refer to... Figure 5 The primary / backup database switching device includes: Receiver module 10 is used to receive traffic requests; The detection module 20 is used to allocate the traffic request to a database according to a pre-built database mapping table through a routing application to obtain a response database set, and to perform fault detection on the initial main database in the response database set. Processing module 30 is configured to, in the event of a failure of the initial primary database, select the backup database with the lowest latency in the response database set as the final primary database and process the traffic request through the final primary database.

[0077] The primary / standby database switching device provided in this application, employing the primary / standby database switching method described in the above embodiments, can solve the technical problem of service interruption caused by the inability to automatically switch databases due to static sharding architecture failures. Compared with the prior art, the beneficial effects of the primary / standby database switching device provided in this application are the same as those of the primary / standby database switching method described in the above embodiments, and other technical features in the primary / standby database switching device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0078] This application provides a primary / backup database switching 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, and the instructions are executed by the at least one processor to enable the at least one processor to perform the primary / backup database switching method in the first embodiment described above.

[0079] The following is for reference. Figure 6 The diagram illustrates a structural schematic suitable for implementing a primary / backup database switching device in the embodiments of this application. The primary / backup database switching device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The primary / backup database switching device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0080] like Figure 6As shown, the primary / standby database switching 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 the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the primary / standby database switching 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. Communication device 1009 allows the primary / standby database switching device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows primary / standby database switching devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0081] 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.

[0082] The primary / standby database switching device provided in this application, employing the primary / standby database switching method described in the above embodiments, can solve the technical problem of service interruption caused by the inability to automatically switch databases due to static sharding architecture failures. Compared with the prior art, the beneficial effects of the primary / standby database switching device provided in this application are the same as those of the primary / standby database switching method described in the above embodiments, and other technical features of this primary / standby database switching device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0083] 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.

[0084] 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.

[0085] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the primary / backup database switching method described in the above embodiments.

[0086] 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.

[0087] The aforementioned computer-readable storage medium may be included in the primary / standby database switching device; or it may exist independently and not be assembled into the primary / standby database switching device.

[0088] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the primary / backup database switching device, cause the primary / backup database switching device to: receive a traffic request; allocate databases to the traffic request through a routing application according to a pre-built database mapping table to obtain a response database set; perform fault detection on the initial primary database in the response database set; and, if a fault is detected in the initial primary database, select the backup database with the lowest latency in the response database set as the final primary database and process the traffic request through the final primary database.

[0089] 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).

[0090] 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.

[0091] 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.

[0092] 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 primary / standby database switching method. This solves the technical problem of service interruption caused by the inability to automatically switch databases in a static sharding architecture failure. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the primary / standby database switching method provided in the above embodiments, and will not be repeated here.

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

[0094] The computer program product provided in this application can solve the technical problem of business interruption caused by the inability to achieve automatic database switching due to static sharding architecture failure. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the primary / standby database switching method provided in the above embodiments, and will not be repeated here.

[0095] 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 method for switching between primary and standby databases, characterized in that, The primary / standby database switching method is applied to a business system, and the primary / standby database switching method includes: Receive traffic requests; Based on a pre-built database mapping table, the traffic requests are allocated to databases through a routing application to obtain a response database set, and fault detection is performed on the initial master database in the response database set. If a failure is detected in the initial primary database, the backup database with the lowest latency in the response database set is selected as the final primary database, and the traffic request is processed through the final primary database.

2. The primary / standby database switching method as described in claim 1, characterized in that, Before the step of allocating the traffic request to a response database set through a routing application based on a pre-built database mapping table, the method further includes: The number of physical database partitions is determined based on the business concurrency and storage capacity requirements of the business system. The number of virtual shards is determined based on the number of physical database shards and the routing balance of the business system. The mapping relationship between virtual shards, physical shards, and primary / standby databases is determined based on the number of physical shards and the number of virtual shards. A ring mapping relationship is constructed based on the cross-backup rules of the primary and backup storage databases; A database mapping table is constructed based on the mapping relationships between the virtual shards, physical databases, primary and backup databases, and the ring mapping relationship.

3. The primary / standby database switching method as described in claim 2, characterized in that, The step of allocating the traffic requests to a response database set through a routing application based on a pre-built database mapping table includes: The routing application obtains the mapping relationships between virtual shards, physical databases, and primary / standby databases in the database mapping table. The target virtual shard is determined based on the traffic request. The target virtual shard is matched according to the mapping relationship between the virtual shard, physical database, and primary and backup databases to obtain the initial primary database and several backup databases. The initial primary database and several backup databases are integrated to obtain a response database set.

4. The primary / standby database switching method as described in claim 1, characterized in that, The step of fault detection in the initial master database of the response database set includes: The initial master database is detected by the basic resource layer to obtain the CPU utilization and memory utilization of the initial master database; The initial master database is queried through the underlying data layer, and the response latency corresponding to the query statement is calculated. The response delay is timed out based on the response threshold to obtain the judgment result; The transaction operation of the traffic request is simulated at the business layer, and the transaction failure rate of the transaction operation is calculated. Based on the CPU utilization, memory utilization, judgment results, and transaction failure rate, a comprehensive fault detection is performed to obtain the detection results.

5. The primary / standby database switching method as described in claim 3, characterized in that, After the step of allocating the traffic request to a database through a routing application to obtain a response database set, the method further includes: The business data corresponding to the traffic request is synchronized to the several backup databases through a data dual-write mechanism. When the writing of the several backup databases is completed, a global incrementing version number is generated and the global incrementing version number is loaded into the message queue; Duplicate data is determined by analyzing the historical globally incrementing version numbers in the message queue to obtain the determination result; When the determination result is that there is no duplicate data, it is determined that the data in the several backup databases is consistent with the data in the initial master database.

6. The primary / standby database switching method as described in claim 2, characterized in that, The step of selecting the backup database with the lowest latency in the response database set as the final primary database and processing the traffic request through the final primary database when a failure of the initial primary database is detected includes: When an initial primary database failure is detected, the initial primary database is marked as unavailable, and the standby database with the lowest latency in the response database set is promoted to the final primary database; Based on the database mapping table, several backup databases for the final primary database are determined; The database mapping table is updated through the final master database and several backup databases, and the traffic requests are processed through the final master database.

7. The primary / standby database switching method as described in claim 6, characterized in that, After the steps of updating the database mapping table through the final primary database and several backup databases, and processing the traffic request through the final primary database, the method further includes: After the initial primary database is recovered from the failure, the data in the initial primary database is synchronized to obtain the supplementary data; The completed data is subjected to a consistency check to obtain the consistency check result; After the consistency verification result passes, the database mapping table is restored to its initial deployment state, and redundant data is cleaned up.

8. A primary / backup database switching device, characterized in that, The primary / standby database switching device is applied to the business system, and the primary / standby database switching device includes: The receiving module is used to receive traffic requests; The detection module is used to allocate the traffic requests to a database according to a pre-built database mapping table through a routing application to obtain a response database set, and to perform fault detection on the initial master database in the response database set. The processing module is configured to, in the event of a failure of the initial primary database, select the backup database with the lowest latency in the response database set as the final primary database, and process the traffic request through the final primary database.

9. A primary / standby database switching device, characterized in that, The 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 primary / backup database switching method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the primary / standby database switching method as described in any one of claims 1 to 7.

Images