WO2024103902A1

WO2024103902A1 - Database access method, apparatus and system, and device and readable storage medium

Info

Publication number: WO2024103902A1
Application number: PCT/CN2023/115587
Authority: WO
Inventors: 高长玉
Original assignee: 苏州元脑智能科技有限公司
Priority date: 2022-11-14
Filing date: 2023-08-29
Publication date: 2024-05-23
Also published as: CN115470303A; CN115470303B

Abstract

Disclosed in the present application are a database access method, apparatus and system, and a device and a readable storage medium in the technical field of computers. The method in the present application is applied to a virtual database, and can comprise: according to a load balancing policy, routing a database access request to any target database node managed by a virtual database, wherein the virtual database manages a plurality of MySQL database nodes, and all the MySQL database nodes share the same repository; and enabling the target database node to complete the processing of the request by means of accessing the repository. The present application abandons the master-slave database concept and makes MySQL database nodes share the same repository, such that a synchronization operation in a high-concurrency scenario can be avoided, and data storage can also be made consistent; in addition, the stability, reliability and high availability of a database access service can also be ensured by means of load balancing. The database access apparatus and system, and the device and the non-volatile readable storage medium provided in the present application also have the above technical effects.

Description

A database access method, device, system, equipment and readable storage medium

This application claims priority to a Chinese patent application filed with the China Patent Office on November 14, 2022, with application number 202211417410.7 and application name “A Database Access Method, Device, System, Equipment and Readable Storage Medium”, all contents of which are incorporated by reference into this application.

Technical Field

The present application relates to the field of computer technology, and in particular to a database access method, device, system, equipment and non-volatile readable storage medium.

Background technique

In the related art, in order to ensure the high availability and stable operation of the MySQL database service, a master node and a slave node are generally set. Among them, the master node is used to process write operations, and the slave node is used to process query operations. In addition, after the master node completes the write operation, it will synchronize the currently written data to the slave node. Therefore, if the current amount of written data is large, the amount of synchronized data will be large. Therefore, in the case of a large number of write operations or low network bandwidth, there will be a delay in data synchronization, which will reduce the performance of the database service.

Summary of the invention

In view of this, the purpose of this application is to provide a database access method, device, system, equipment and non-volatile readable storage medium to improve the database service performance in high concurrency scenarios. The specific scheme is as follows:

In a first aspect, the present application provides a database access method, which is applied to a virtual database, comprising:

receiving a database access request;

Routing database access requests to any target database node managed by the virtual database according to the load balancing strategy; wherein the virtual database manages multiple MySQL database nodes, and all MySQL database nodes share the same repository;

The target database node completes the processing of the database access request by accessing the repository.

In some embodiments, routing a database access request to any target database node managed by a virtual database according to a load balancing strategy includes:

Determine the MySQL database node with the smallest weight among all MySQL database nodes managed by the virtual database according to the load balancing strategy;

The MySQL database node with the smallest weight is determined as the target database node, and the database access request is routed to the target database node.

In some embodiments, the weight calculation process of any MySQL database node includes:

Calculate the routing frequency of the current MySQL database node;

Calculate the load score of the current MySQL database node at the current moment;

The sum of the routing frequency and the load score is used as the weight of the current MySQL database node.

In some embodiments, calculating the routing frequency of the current MySQL database node includes:

The routing frequency of the current MySQL database node is calculated according to the first formula; the first formula is: _Wu = _Ci /C _S , _Wu is the routing frequency of MySQL database node i, _Ci is the number of times MySQL database node i is routed, and C _S is the preset maximum number of times of being routed.

In some embodiments, calculating the load score of the current MySQL database node at the current moment includes:

The load score of the current MySQL database node at the current moment is calculated according to the second formula; the second formula is: W _load =L _CPU ×a+L _m ×b+L _IO ×c, W _load is the load score of the current MySQL database node, L _CPU is the CPU load of the current MySQL database node, L _m is the memory load of the current MySQL database node, L _IO is the IO load of the current MySQL database node, and a, b, and c are all preset coefficients.

In some embodiments, it also includes:

Regularly collect and record the operating status of all MySQL database nodes managed by the virtual database;

If any MySQL database node fails, a failure flag is added to the MySQL database node.

In some embodiments, it also includes:

During the operation of the virtual database, the MySQL database nodes in the node sequence managed by the virtual database are added, deleted or modified by configuring update commands to obtain an updated node sequence;

Manage and configure each MySQL database node in the updated node sequence one by one.

In some embodiments, managing and configuring each MySQL database node in the updated node sequence one by one includes:

Determine the newly added MySQL database node in the updated node sequence;

After managing and configuring the newly added MySQL database nodes one by one, manage and configure the remaining MySQL database nodes in the updated node sequence.

In some embodiments, managing and configuring the newly added MySQL database node includes:

Configure the IP address, port, database account, and database login password of the newly added MySQL database node in the virtual database.

In some embodiments, it also includes:

Query, add, delete or modify the service configuration of the virtual database according to user operations; the service configuration includes: the maximum number of available connections, the maximum number of idle connections, the maximum waiting time, the access address, the access port, the virtual database account and the virtual database login password.

In some embodiments, it also includes:

If the virtual database stops running, add, delete or modify the MySQL database nodes in the node sequence managed by the virtual database, and restart the virtual database.

In a second aspect, the present application provides a database access device, applied to a virtual database, comprising:

A receiving module, used for receiving a database access request;

A routing module, used to route database access requests to any target database node managed by the virtual database according to a load balancing strategy; wherein the virtual database manages multiple MySQL database nodes, and all MySQL database nodes share the same repository;

The processing module is used to enable the target database node to complete the processing of the database access request by accessing the storage repository.

In some embodiments, the routing module is specifically configured to:

In some embodiments, it also includes:

The health monitoring module is used to periodically collect and record the operating status of all MySQL database nodes managed by the virtual database; if any MySQL database node fails, a fault mark is added to the MySQL database node.

In some embodiments, it also includes:

The node configuration online update module is used to add, delete or modify the MySQL database nodes in the node sequence managed by the virtual database through the configuration update command during the operation of the virtual database to obtain the updated node sequence; and manage and configure each MySQL database node in the updated node sequence one by one.

In some embodiments, the node configuration online update module is specifically used to: determine the newly added MySQL database nodes in the updated node sequence; manage and configure the newly added MySQL database nodes one by one, and then manage and configure the remaining MySQL database nodes in the updated node sequence.

In some embodiments, the node configuration online update module is specifically used to: configure the IP address, port, database account and database login password of the newly added MySQL database node in the virtual database.

In some embodiments, it also includes:

The service configuration operation module is used to query, add, delete or modify the service configuration of the virtual database according to user operations; the service configuration includes: the maximum number of available connections, the maximum number of idle connections, the maximum waiting time, the access address, the access port, the virtual database account and the virtual database login password.

In some embodiments, it also includes:

The node configuration offline update module is used to add, delete or modify the MySQL database nodes in the node sequence managed by the virtual database if the virtual database stops running, and restart the virtual database.

In a third aspect, the present application provides a database access system, comprising: the aforementioned disclosed virtual database, multiple MySQL database nodes and a storage repository.

In some embodiments, the virtual database is used to: receive database access requests; route the database access requests to any target database node managed by the virtual database according to a load balancing strategy; wherein the virtual database manages multiple MySQL database nodes, and all MySQL database nodes share the same repository; and enable the target database node to complete the processing of the database access request by accessing the repository.

In some embodiments, the virtual database is used to: determine the MySQL database node with the smallest weight among all MySQL database nodes managed by the virtual database according to the load balancing strategy; determine the MySQL database node with the smallest weight as the target database node, and route the database access request to the target database node.

In some embodiments, the virtual database is used to: calculate the routing frequency of the current MySQL database node; calculate the load score of the current MySQL database node at the current moment; and use the sum of the routing frequency and the load score as the weight of the current MySQL database node.

In some embodiments, the virtual database is used to calculate the routing frequency of the current MySQL database node according to a first formula; the first formula is: _Wu = _Ci / _Cs , _Wu is the routing frequency of MySQL database node i, Ci _is the number of times MySQL database node i is routed, and _Cs is the preset maximum number of times of being routed.

In some embodiments, the virtual database is used to: calculate the load score of the current MySQL database node at the current moment according to the second formula; the second formula is: W _load =L _CPU ×a+L _m ×b+L _IO ×c, W _load is the load score of the current MySQL database node, L _CPU is the CPU load of the current MySQL database node, L _m is the memory load of the current MySQL database node, L _IO is the IO load of the current MySQL database node, and a, b, and c are all preset coefficients.

In some embodiments, the virtual database is used to: regularly collect and record the operating status of all MySQL database nodes managed by the virtual database; if any MySQL database node fails, a fault mark is added to the MySQL database node.

In some embodiments, the virtual database is used to: during the operation of the virtual database, add, delete or modify the MySQL database nodes in the node sequence managed by the virtual database through configuration update commands to obtain an updated node sequence; and manage and configure each MySQL database node in the updated node sequence one by one.

In some embodiments, the virtual database is used to: determine newly added MySQL database nodes in the updated node sequence; manage and configure the newly added MySQL database nodes one by one, and then manage and configure the remaining MySQL database nodes in the updated node sequence.

In some embodiments, the virtual database is used to configure the IP address, port, database account and database login password of the newly added MySQL database node in the virtual database.

In some embodiments, the virtual database is used to query, add, delete or modify the service configuration of the virtual database according to user operations; the service configuration includes: the maximum number of available connections, the maximum number of idle connections, the maximum waiting time, the access address, the access port, the virtual database account and the virtual database login password.

In some embodiments, the virtual database is used to: if the virtual database stops running, add, delete or modify the MySQL database nodes in the node sequence managed by the virtual database, and restart the virtual database.

In a fourth aspect, the present application provides an electronic device, including:

Memory for storing computer programs;

The processor is used to execute the computer program to implement the aforementioned disclosed database access method.

In a fifth aspect, the present application provides a non-volatile readable storage medium for storing a computer program, wherein the computer program implements the aforementioned disclosed database access method when executed by a processor.

It can be seen from the above scheme that the present application provides a database access method, which is applied to a virtual database, including: receiving a database access request; routing the database access request to any target database node managed by the virtual database according to a load balancing strategy; wherein the virtual database manages multiple MySQL database nodes, and all MySQL database nodes share the same repository; and enabling the target database node to complete the processing of the database access request by accessing the repository.

It can be seen that the present application adopts a virtual database to manage multiple MySQL database nodes that share the same repository, and when a database access request is received, the database access request can be routed to any target database node managed by the virtual database according to the load balancing strategy, so that each MySQL database node can complete the processing of the database access request by accessing the repository. This solution abandons the master-slave concept of the database and instead enables each MySQL database node to share the same repository, which not only avoids synchronous operations in high-concurrency scenarios, thereby avoiding the impact of synchronous operations on database service performance, but also allows the same copy of data to exist in one copy, thereby ensuring data consistency. In addition, the various database nodes managed by the virtual database can share access requests according to the load balancing strategy, so as to maximize the availability of each database node, thereby ensuring the stability, reliability and high availability of the entire database access service.

Correspondingly, a database access device, system, equipment and non-volatile readable storage medium provided by the present application also have the above-mentioned technical effects.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

FIG1 is a flow chart of a database access method disclosed in some embodiments of the present application;

FIG2 is a schematic diagram of a database access system disclosed in some embodiments of the present application;

FIG3 is a schematic diagram of a database access device disclosed in some embodiments of the present application;

FIG. 4 is a schematic diagram of an electronic device disclosed in some embodiments of the present application.

Detailed ways

The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

At present, MySQL databases generally set up master nodes and slave nodes. Among them, the master node is used to process write operations, and the slave node is used to process query operations. In addition, after completing the write operation, the master node will synchronize the currently written data to the slave node. Therefore, if the current amount of written data is large, the amount of synchronized data will be large. Therefore, in the case of a large number of write operations or when the network bandwidth is low, there will be a delay in data synchronization, which will reduce the database service performance. To this end, the present application provides a database access solution that enables each MySQL database node to share the same repository, avoids the impact of synchronization operations on database service performance, and can also ensure the consistency of data storage and the stability, reliability and high availability of the entire database access service.

As shown in FIG1 , the embodiment of the present application discloses a database access method, which is applied to a virtual database, including:

S101: Receive a database access request.

In some embodiments of the present application, a database access request is an SQL statement for implementing a query operation or an SQL statement for implementing a write operation. The virtual database in this embodiment can be understood as a software service that can simultaneously manage multiple MySQL database nodes, which are connected to the same storage repository through network devices such as switches, that is, these MySQL database nodes share the same storage repository, thereby realizing a shared storage service.

S102. Routing a database access request to any target database node managed by the virtual database according to a load balancing strategy; wherein the virtual database manages multiple MySQL database nodes, and all MySQL database nodes share the same storage repository.

In some feasible implementations, a database access request is routed to any target database node managed by the virtual database according to a load balancing strategy, including: determining a MySQL database node with the smallest weight among all MySQL database nodes managed by the virtual database according to the load balancing strategy; determining the MySQL database node with the smallest weight as the target database node, and routing the database access request to the target database node.

In some feasible implementations, the weight calculation process of any MySQL database node includes: calculating the routing frequency of the current MySQL database node; calculating the load evaluation of the current MySQL database node at the current moment; The sum of the routing frequency and the load score is used as the weight of the current MySQL database node. The current MySQL database node is any node managed by the virtual database.

Wherein, calculating the routing frequency of the current MySQL database node includes: calculating the routing frequency of the current MySQL database node according to a first formula; the first formula is: _Wu = _Ci /C _S , _Wu is the routing frequency of MySQL database node i, _Ci is the number of times MySQL database node i is routed, and C _S is a preset maximum number of times of being routed.

Wherein, calculating the load score of the current MySQL database node at the current moment includes: calculating the load score of the current MySQL database node at the current moment according to a second formula; the second formula is: W _load = L _CPU × a + L _m × b + L _IO × c, W _load is the load score of the current MySQL database node, L _CPU is the CPU load of the current MySQL database node, L _m is the memory load of the current MySQL database node, L _IO is the IO load of the current MySQL database node, and a, b, and c are all preset coefficients. Generally, a+b+c=1.

S103: Enable the target database node to complete the processing of the database access request by accessing the storage repository.

Since the database access request is actually an SQL statement, the target database node can query the corresponding information in the repository or write certain information into the repository by executing the SQL statement.

It should be noted that the service configuration of the virtual database can be queried, added, deleted or modified according to user operations; the service configuration includes: the maximum number of available connections, the maximum number of idle connections, the maximum waiting time, the access address, the access port, the virtual database account and the virtual database login password.

It can be seen that this embodiment uses a virtual database to manage multiple MySQL database nodes that share the same repository, and when a database access request is received, the database access request can be routed to any target database node managed by the virtual database according to the load balancing strategy, so that each MySQL database node can complete the processing of the database access request by accessing the repository. This solution abandons the master-slave concept of the database and instead enables each MySQL database node to share the same repository, thereby not only avoiding synchronous operations in high-concurrency scenarios, thereby avoiding the impact of synchronous operations on database service performance, but also allowing the same copy of data to exist in one copy, thereby ensuring data consistency. In addition, the various database nodes managed by the virtual database can share access requests according to the load balancing strategy, thereby maximizing the availability of each database node, thereby ensuring the stability, reliability and high availability of the entire database access service.

Based on the above embodiment, it should be noted that the virtual database can monitor the status of each MySQL database node it manages. In some feasible implementations, the operating status of all MySQL database nodes managed by the virtual database is regularly collected and recorded; if any MySQL database node fails, a fault mark is added to the MySQL database node.

Of course, the MySQL database nodes managed by the virtual database can also be flexibly adjusted, including online adjustment and offline adjustment. Online adjustment means: during the operation of the virtual database, the MySQL database nodes in the node sequence managed by the virtual database are added, deleted or modified through the configuration update command to obtain the updated node sequence; each MySQL database node in the updated node sequence is managed and configured one by one. Offline adjustment means: if the virtual database stops running, the MySQL database nodes in the node sequence managed by the virtual database are added, deleted or modified, and the virtual database is restarted. Among them, the managed nodes of the virtual database refer to: nodes that can be used to process requests. In other words, faulty nodes or nodes that have been disconnected from the service are not in the node sequence.

Among them, each MySQL database node in the updated node sequence is managed and configured one by one, including: determining the newly added MySQL database node in the updated node sequence; after managing and configuring the newly added MySQL database node one by one, the remaining MySQL database nodes in the updated node sequence are managed and configured (such as: when the node IP, port and other information are checked to be updated, the corresponding information is updated). Among them, the management and configuration of the newly added MySQL database node includes: configuring the IP address, port, database account and database login password of the newly added MySQL database node in the virtual database. For example: a certain MySQL database node is recorded in the node sequence as: IP: port: username: password.

It should be noted that configuring newly added nodes first can avoid service interruption. For example, the virtual database originally managed nodes A and B. During an online adjustment, nodes A and B were changed to nodes C and D. Then nodes C and D should be configured first so that they can accept access requests. If nodes A and B are stopped first, the virtual database service will be interrupted.

Please refer to Figure 2, this embodiment provides a specific structure for the virtual database, including: virtual service, configuration center, virtual service, load balancing, health check and other modules. Among them, the configuration center module can be used to change and read the relevant configuration information of the virtual database, including: basic connection configuration and service configuration.

The basic connection configuration is used to set each node managed by the virtual database. It uses the form of ip:port:username:password to record each node managed by the virtual database. For example, config.dbpool.serverList = 10.0.0.1:3306:root:mysqladmin|10.0.0.2:3306:root:mysqladmin is the connection configuration corresponding to a certain node.

Among them, the service configuration includes: the maximum number of available connections, such as: config.dbpool.maxActive = 100. The maximum number of idle connections, such as: config.dbpool.maxIdle = 20. The number of initialized connections, such as: config.dbpool.initSize = 10. The maximum waiting time, in ms, such as: config.dbpool.maxWait = 1000. The virtual database address and port, such as: config.server.url = 10.1.1.1:3306. Multiple virtual database access accounts and passwords can be set, such as: config.server.userInfo = root:mysqladmin | test1:test1. Of course, you can also set the user IP that can access the virtual database, such as: config.server.url: x = 10.1.1.1:3306:root:mysqladmin, config.server.userInfo: x = root:mysqladmin | test1:test1, x is an increasing Arabic numeral. It can be seen that multiple user IPs can be set to access the virtual database as needed.

Both the basic connection configuration and the service configuration can be recorded in the configuration file, and the user can modify the configuration file at any time. When the virtual database service is started, the configuration center will read the configuration file and assist other modules to complete the service initialization. After the service is started normally, the user can also query and modify the relevant configuration through the following commands. For example: Use lssharedbconfig-i configName to query the service configuration information. "–i" is an optional parameter. If it is not filled in, all information will be returned. If it is filled in, specific configuration content will be returned. Use chgsharedbconfig-i configName configValue to modify the service configuration information. "–i" is an optional parameter. This parameter has two parameter values. The first item is the configuration name, and the second item is the configuration item content. Use refreshsharedbconfig to read the configuration information and restart the virtual service.

It should be noted that the virtual database is the intermediate bridge between the underlying real database cluster and the user service request. The underlying database cluster is in a black box state for users. Users will not directly access specific database nodes, but access the virtual services provided by the virtual database, so that the virtual services can route requests to specific database nodes. Therefore, the virtual service provides users with a unified access entrance, which can shield the complex internal design and improve the simplicity of the system.

The load balancing module is a pre-function for virtual service routing. This module can select the most suitable node in the current database cluster for virtual service routing according to the set routing rules. This module can ensure that service requests can fall on each node as evenly as possible, providing the load capacity of the entire system. Among them, the load balancing routing rules include: (1) Recording the node routing times of the last 1000 requests, and counting the usage weight score of each node (i.e., routing frequency) each time routing, and the calculation rule is: node routing times/total routing times 1000. (2) Regularly scan the basic performance information of each node, including CPU usage, memory usage, and IO usage, and count the server load weight score (i.e., load score) of each node based on these three pieces of information, and the calculation rule is: CPU usage * 50 + memory usage * 30 + IO usage * 20. (3) Take the sum of the usage weight score and the server load weight score of each node as the final load weight of the node, and the node with the lowest final load weight will be the target node of this routing.

The health check module will regularly check the health status of each database node and collect relevant data for use by the load balancing module. If a node fails, the load balancing module will identify this event, and the node will no longer be included in the routing scope until the health check module reports that it has returned to normal. This module is responsible for troubleshooting node failures in the system and has the ability to automatically recover after the node is normal, ensuring the high availability of the entire system.

Among them, each database node in the database cluster (A, B, C, D as shown in Figure 2) uses shared storage as data storage space to ensure the consistency of data storage. The instance information of each database node is registered in the virtual database through the configuration file. When the virtual database service is started, the configuration center will read the relevant configuration file. After reading, it will notify the health check module to connect and initialize the database node. After checking the connectivity of each database node in turn, the health check module records the database nodes in a healthy state and notifies the virtual service to route the request.

The database cluster can be expanded or reduced in capacity by either stopping or starting the system.

When scaling up or down, the virtual service handles the downtime state. Users can directly modify the configuration file to change the database node list. After the change, restart the service and the scaling will take effect.

When scaling up or down at startup, users can add or delete the database node list through the chgsharedbconfig command. The configuration center can detect the result of this command, and then notify the health check module to perform a new round of node health checks and node connection initialization. At this time, each database node is initialized one by one to ensure that at least one node can process access requests during the entire process, thereby ensuring service availability and avoiding the situation where no available database node can be found when a new request comes in.

Please refer to Figure 2. The processing of a service request includes: after the request reaches the virtual service, the virtual service tries to obtain an available high-performance node with the help of the load balancing module, that is, the load balancing module selects the healthy node with the lowest weight score from the current database cluster as the routing node and returns it to the virtual service. At this time, the virtual service enables the routing node to execute the SQL statement to complete the service request to access the shared storage.

It can be seen that this embodiment provides a unified access entrance for user requests, and establishes a multi-node database cluster based on shared storage, canceling the synchronization mechanism of the master-slave node. On the one hand, it can overcome the data synchronization delay when writing large amounts of data, and on the other hand, it can expand the number of nodes horizontally. In addition, the unified access entrance shields the underlying cluster structure, and with the help of load balancing strategies, the database service can run normally in high concurrency and high pressure scenarios, ensuring the stability, reliability and high availability of the entire service.

A database access device provided in an embodiment of the present application is introduced below. The database access device described below and the database access method described above can be referenced to each other.

As shown in FIG3 , the embodiment of the present application discloses a database access device, which is applied to a virtual database, including:

Receiving module 301, used for receiving a database access request;

The routing module 302 is used to route the database access request to any target database node managed by the virtual database according to the load balancing strategy; wherein the virtual database manages multiple MySQL database nodes, and all MySQL database nodes share the same storage repository;

The processing module 303 is used to enable the target database node to complete the processing of the database access request by accessing the storage repository.

In some feasible implementations, the routing module is specifically used to:

In some feasible implementations, the following further includes:

In some feasible implementations, the node configuration online update module is specifically used to: determine the newly added MySQL database nodes in the updated node sequence; manage and configure the newly added MySQL database nodes one by one, and then manage and configure the remaining MySQL database nodes in the updated node sequence.

In some feasible implementations, the node configuration online update module is specifically used to: configure the IP address, port, database account and database login password of the newly added MySQL database node in the virtual database.

In some feasible implementations, the following further includes:

Among them, for more specific working processes of each module and unit in this embodiment, reference can be made to the corresponding contents disclosed in the aforementioned embodiments, which will not be repeated here.

It can be seen that this embodiment provides a database access device that enables various MySQL database nodes to share the same storage repository, avoids the impact of synchronous operations on database service performance, and ensures the consistency of data storage and the stability, reliability and high availability of the entire database access service.

The embodiment of the present application discloses a database access system, including: the virtual database disclosed in the above embodiment, multiple MySQL database nodes and a storage repository. Specifically, please refer to Figure 2, where the shared storage in Figure 2 is the storage repository.

In some feasible implementations, the virtual database is used to: receive database access requests; route the database access requests to any target database node managed by the virtual database according to a load balancing strategy; wherein the virtual database manages multiple MySQL database nodes, and all MySQL database nodes share the same repository; and enable the target database node to complete the processing of the database access request by accessing the repository.

In some feasible implementations, the virtual database is used to: determine the MySQL database node with the smallest weight among all MySQL database nodes managed by the virtual database according to the load balancing strategy; determine the MySQL database node with the smallest weight as the target database node, and route the database access request to the target database node.

In some feasible implementations, the virtual database is used to: calculate the routing frequency of the current MySQL database node; calculate the load score of the current MySQL database node at the current moment; and use the sum of the routing frequency and the load score as the weight of the current MySQL database node.

In some feasible implementations, the virtual database is used to: calculate the routing frequency of the current MySQL database node according to a first formula; the first formula is: _Wu = _Ci /C _S , _Wu is the routing frequency of MySQL database node i, _Ci is the number of times MySQL database node i is routed, and C _S is the preset maximum number of times of being routed.

In some feasible implementations, the virtual database is used to: calculate the load score of the current MySQL database node at the current moment according to the second formula; the second formula is: W _load =L _CPU ×a+L _m ×b+L _IO ×c, W _load is the load score of the current MySQL database node, L _CPU is the CPU load of the current MySQL database node, L _m is the memory load of the current MySQL database node, L _IO is the IO load of the current MySQL database node, and a, b, and c are all preset coefficients.

In some feasible implementations, the virtual database is used to: regularly collect and record the operating status of all MySQL database nodes managed by the virtual database; if any MySQL database node fails, a fault identifier is added to the MySQL database node.

In some feasible implementations, the virtual database is used to: during the operation of the virtual database, add, delete or modify the MySQL database nodes in the node sequence managed by the virtual database through configuration update commands to obtain an updated node sequence; and manage and configure each MySQL database node in the updated node sequence one by one.

In some feasible implementations, the virtual database is used to: determine newly added MySQL database nodes in the updated node sequence; manage and configure the newly added MySQL database nodes one by one, and then manage and configure the remaining MySQL database nodes in the updated node sequence.

In some feasible implementations, the virtual database is used to configure the IP address, port, database account and database login password of the newly added MySQL database node in the virtual database.

In some feasible implementations, the virtual database is used to query, add, delete or modify the service configuration of the virtual database according to user operations; the service configuration includes: the maximum number of available connections, the maximum number of idle connections, the maximum waiting time, the access address, the access port, the virtual database account and the virtual database login password.

In some feasible implementations, the virtual database is used to: if the virtual database stops running, add, delete or modify the MySQL database nodes in the node sequence managed by the virtual database, and restart the virtual database.

An electronic device provided in an embodiment of the present application is introduced below. The electronic device described below and the database access method and device described above can be referenced to each other.

As shown in FIG4 , an embodiment of the present application discloses an electronic device, including:

Memory 401, used for storing computer programs;

The processor 402 is used to execute the computer program to implement the method disclosed in any of the above embodiments.

Furthermore, an embodiment of the present application also provides a server as the above-mentioned electronic device. The server may specifically include: at least one processor, at least one memory, a power supply, a communication interface, an input/output interface, and a communication bus. The memory is used to store a computer program, and the computer program is loaded and executed by the processor to implement the relevant steps in the database access method disclosed in any of the above-mentioned embodiments.

In this embodiment, the power supply is used to provide working voltage for each hardware device on the server; the communication interface can create a data transmission channel between the server and external devices, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

In addition, the memory as a carrier for resource storage can be a read-only memory, random access memory, disk or CD, etc. The resources stored thereon include operating system, computer programs and data, etc. The storage method can be temporary storage or permanent storage.

The operating system is used to manage and control the hardware devices and computer programs on the server to realize the operation and processing of the data in the memory by the processor, which can be Windows Server, Netware, Unix, Linux, etc. In addition to computer programs that can be used to complete the database access method disclosed in any of the aforementioned embodiments, computer programs can also further include computer programs that can be used to complete other specific tasks. In addition to data such as virtual machines, data can also include data such as the developer information of the virtual machine.

Furthermore, the embodiment of the present application also provides a terminal as the above electronic device. The terminal may specifically include but is not limited to a smart phone, a tablet computer, a laptop computer or a desktop computer.

Generally, the terminal in this embodiment includes: a processor and a memory.

Among them, the processor may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

The memory may include one or more computer non-volatile readable storage media, which may be non-transitory. The memory may also include high-speed random access memory, and non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory is at least used to store the following computer program, wherein, after the computer program is loaded and executed by the processor, it can implement the relevant steps in the database access method performed by the terminal side disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory may also include an operating system and data, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system may include Windows, Unix, Linux, etc. The data may include, but is not limited to, update information of the application.

In some embodiments, the terminal may also include a display screen, an input and output interface, a communication interface, a sensor, a power supply, and a communication bus.

A non-volatile readable storage medium provided in an embodiment of the present application is introduced below. The non-volatile readable storage medium described below and the database access method, apparatus and device described above can be referenced to each other.

A non-volatile readable storage medium is used to store a computer program, wherein the computer program implements the database access method disclosed in the above embodiment when executed by a processor.

The "first", "second", "third", "fourth", etc. (if any) referred to in this application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods or devices.

It should be noted that the descriptions involving "first", "second", etc. in this application are only for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in this field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by this application.

The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of non-volatile readable storage medium known in the art.

Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the idea of the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

A database access method, characterized in that it is applied to a virtual database and comprises:

receiving a database access request;

Routing the database access request to any target database node managed by the virtual database according to the load balancing strategy; wherein the virtual database manages multiple MySQL database nodes, and all MySQL database nodes share the same storage repository;

The target database node completes processing of the database access request by accessing the storage repository.
The method according to claim 1, characterized in that routing the database access request to any target database node managed by the virtual database according to the load balancing strategy comprises:

Determine the MySQL database node with the smallest weight among all MySQL database nodes managed by the virtual database according to the load balancing strategy;

The MySQL database node with the smallest weight is determined as the target database node, and the database access request is routed to the target database node.
The method according to claim 2 is characterized in that the weight calculation process of any MySQL database node includes:

Calculate the routing frequency of the current MySQL database node;

Calculate the load score of the current MySQL database node at the current moment;

The sum of the routing frequency and the load score is used as the weight of the current MySQL database node.
The method according to claim 3, characterized in that the calculating the routing frequency of the current MySQL database node comprises:

The routing frequency of the current MySQL database node is calculated according to the first formula; the first formula is: Wu = Ci /C S , Wu is the routing frequency of MySQL database node i, Ci is the number of times MySQL database node i is routed, and C S is the preset maximum number of times of being routed.
The method according to claim 3, characterized in that the calculating the load score of the current MySQL database node at the current moment comprises:

The load score of the current MySQL database node at the current moment is calculated according to the second formula; the second formula is: W load =L CPU ×a+L m ×b+L IO ×c, W load is the load score of the current MySQL database node, L CPU is the CPU load of the current MySQL database node, L m is the memory load of the current MySQL database node, L IO is the IO load of the current MySQL database node, and a, b, and c are all preset coefficients.
The method according to any one of claims 1 to 5, further comprising:

Regularly collect and record the operating status of all MySQL database nodes managed by the virtual database;

If any MySQL database node fails, a failure flag is added to the MySQL database node.
The method according to any one of claims 1 to 5, further comprising:

During the operation of the virtual database, adding, deleting or modifying the MySQL database nodes in the node sequence managed by the virtual database by configuring an update command to obtain an updated node sequence;

Manage and configure each MySQL database node in the updated node sequence one by one.
The method according to claim 7, characterized in that the step of managing and configuring each MySQL database node in the updated node sequence one by one comprises:

Determine the newly added MySQL database node in the updated node sequence;

After managing and configuring the newly added MySQL database nodes one by one, manage and configure the remaining MySQL database nodes in the updated node sequence.
The method according to claim 8, characterized in that managing and configuring the newly added MySQL database node comprises:

The IP address, port, database account and database login password of the newly added MySQL database node are configured in the virtual database.
The method according to any one of claims 1 to 5, further comprising:

The service configuration of the virtual database is queried, added, deleted or modified according to user operations; the service configuration includes: the maximum number of available connections, the maximum number of idle connections, the longest waiting time, the access address, the access port, the virtual database account and the virtual database login password.
According to the method described in any one of claims 1 to 5, it is characterized in that the virtual database provides a specific composition structure, and the specific composition structure includes at least one of a virtual service module, a configuration center module, a virtual service module, a load balancing module and a health check module; wherein the configuration center module allows the modification and reading of relevant configuration information in the virtual service library, and the configuration information includes at least basic connection configuration and service configuration.
The method according to claim 12 is characterized in that the basic connection configuration is used to set each node managed by the virtual database, and each node managed by the virtual database is recorded in the form of ip:port:username:password.
The method according to claim 11, characterized in that the basic connection configuration and the service configuration are recorded in a configuration file, and the method further comprises:

In response to the virtual database service being started, the configuration center module reads the configuration file and assists other virtual service modules, virtual service modules, load balancing modules, and health check modules to complete service initialization.
The method according to claim 13, further comprising:

After the service is started normally, use lssharedbconfig -i configName to query the service configuration information. The -i parameter is optional. If it is not filled in, all information will be returned. If it is filled in, specific configuration content will be returned.

Use chgsharedbconfig -i configName configValue to modify the service configuration information. The -i parameter is an optional parameter with two parameter values. The first one is the configuration name and the second one is the configuration item content.

Use refreshsharedbconfig to read the configuration information and restart the virtual service module.
The method according to claim 11 is characterized in that the load balancing module is a pre-function for the virtual service module to perform routing, and is configured with routing rules, and the routing rules include at least one of the following:

(1) Record the node routing times of the last 1000 requests, and count the usage weight of each node each time the routing is performed. The calculation rule is: node routing times/total routing times 1000;

(2) Regularly scan the basic performance information of each node, including CPU usage, memory usage, and IO usage. Based on these three pieces of information, the server load weight of each node is calculated. The calculation rule is: CPU usage*50+memory usage*30+IO usage*20;

(3) The sum of the usage weight of each node and the server load weight is taken as the final load weight of the node. The node with the lowest final load weight will be used as the target node for this routing.
The method according to any one of claims 1 to 5, further comprising:

If the virtual database stops running, the MySQL database nodes in the node sequence managed by the virtual database are added, deleted or modified, and the virtual database is restarted.
A database access device, characterized in that it is applied to a virtual database and comprises:

A receiving module, used for receiving a database access request;

A routing module, used for routing the database access request to any target database node managed by the virtual database according to a load balancing strategy; wherein the virtual database manages multiple MySQL database nodes, and all MySQL database nodes share the same storage repository;

The processing module is used to enable the target database node to complete the processing of the database access request by accessing the storage repository.
A database access system, characterized by comprising: a virtual database as claimed in any one of claims 1 to 16, a plurality of MySQL database nodes and a storage repository.
An electronic device, comprising:

Memory for storing computer programs;

A processor, configured to execute the computer program to implement the method according to any one of claims 1 to 16.
A non-volatile readable storage medium, characterized in that it is used to store a computer program, wherein the computer program, when executed by a processor, implements the method according to any one of claims 1 to 16.