A database state management method and system based on dynamic frequency adaptation

Abstract

The application discloses a kind of based on dynamic frequency adaptation's database state management method and system, belong to database cloud management platform and intelligent operation and maintenance field.The application divides database state into two categories of database itself state and cloud management platform acquisition state, and respectively defines the state set and state conversion relationship of each other, realize the fine management of database state.Aiming at the acquisition cycle of database running index, the application proposes a kind of dynamic frequency estimation algorithm, based on the success and failure sequence of historical detection or acquisition, the weight of each detection or acquisition is obtained by dynamically calculating the decay rate, and then the time interval of next detection or acquisition is adaptively adjusted.When continuous or recent detection fails, the algorithm can dynamically delay subsequent detection or acquisition time, avoid invalid operation to the occupation of system resources.The application solves the problem of state management confusion in existing database cloud management platform, and the fixed acquisition cycle leads to resource waste, can effectively reduce system resource pressure, reduce invalid alarm, improve platform stability and user experience.

Description

Technical Field

[0001] This invention relates to a sophisticated database status management method and system, belonging to the fields of database cloud management platforms and intelligent database operation and maintenance. Background Technology

[0002] The database cloud management platform, positioned as a one-stop database lifecycle management dbPaaS platform, helps users transform traditional models and establish an automated, self-service, and intelligent database management system. The platform supports various database types and provides users with multiple functions, from installation and deployment, monitoring and alerting, performance analysis, intelligent inspection to intelligent operation and maintenance capabilities. It also integrates standardized operation and maintenance processes to improve database operational security and data security, helping users easily cope with the challenges of managing massive nodes and complex database architectures brought about by business digitalization and distributed architectures.

[0003] In a database cloud management platform, the monitoring and alarm function continuously probes various operational metrics of the database to understand its health status. Furthermore, when database anomalies are detected, alarms are immediately triggered to notify database administrators, facilitating timely intervention. Clearly, the monitoring and alarm function plays a crucial role in ensuring the stable operation of the database.

[0004] In the process of implementing the monitoring and alarm function, the management of the database status is of paramount importance. The database status is mainly divided into: (1) the database status itself, that is, the overall status of the controlled database in the cloud management platform, such as normal, no detection started, low frequency detection, etc.; (2) the cloud management platform detection status, that is, the status of the cloud management platform in detecting various operating indicators of the controlled database, such as normal, low frequency detection, data error, etc.

[0005] In cloud management platforms, databases exhibit a variety of states. These states can transition between different states depending on the events that occur. For example, a controlled database in a normal state might immediately enter a low-frequency probe state when the cloud management platform detects that its connection limit has been reached; conversely, it might immediately return to a normal state when the connection limit is restored. Under the dual pressure of numerous database state types and frequent state transitions, fine-grained management of database states is necessary to prevent a chaotic situation. If the cloud management platform's database state labeling is inconsistent, users will experience greater confusion, leading to a degraded user experience. Attached Figure Description

[0006] Figure 1 This is a diagram showing the transition relationships between the database's own states.

[0007] Figure 2A diagram showing the transition relationships between the detection states of the cloud management platform. Summary of the Invention

[0008] To address the problems of chaotic database state management, unclear state transitions, and resource waste caused by fixed detection cycles in existing database cloud management platforms, this invention proposes a database state management method based on dynamic frequency adaptation. This method includes the following steps:

[0009] (1) Define the database's own state set and its transformation relationships;

[0010] (2) Define the set of detection states of the cloud management platform and their transition relationships;

[0011] (3) Based on historical detection results, dynamically calculate the time period for the next detection by the cloud management platform.

[0012] Furthermore, the database state itself mentioned in step (1) includes normal state, low-frequency database detection state, stopped monitoring state, and initialization state. The normal state indicates that the current monitoring state of the controlled database is normal. The low-frequency database detection state indicates that the previous process of establishing a connection with the controlled database was abnormal, reducing the detection frequency of the connection state of the controlled database. The low-frequency database detection state can be further divided into the state where the number of connections of the platform to the controlled database reaches the upper limit, the connection failure state, the database port not connected state, and the username and password error state.

[0013] Furthermore, the cloud management platform detection status mentioned in step (2) includes normal detection status, detection failure status, data storage failure status, detection timeout status, initialization status, and low-frequency detection status of the cloud management platform; the low-frequency detection status of the cloud management platform is further divided into the detection failure count reaching the upper limit status and the detection timeout count reaching the upper limit status.

[0014] Furthermore, the specific steps for dynamically calculating the detection cycle in the cloud management platform in step (3) are as follows:

[0015] (3.1) The results of the first N probes, in chronological order from earliest to latest, are r1, r2, …, r N Let i = 1, 2, …, N, where i represents the i-th probe, and r is the number of probes when the probe is successful. i =0, when the probe fails, r i =1;

[0016] (3.2) Calculate the weight of the i-th detection result Among them, the attenuation rate ;

[0017] (3.3) Calculate the next detection time , t NIndicates the time of the Nth detection, t N+1 Indicates the time of the (N + 1)th detection, where T is a fixed period.

[0018] When the calculated time interval for the next detection is greater than the preset low-frequency time threshold (default 600 seconds), the cloud management platform marks the detection status of the controlled database as the cloud management platform low-frequency detection status. If when calculating subsequent periods, the calculated time interval for the next detection is still greater than this threshold, the cloud management platform low-frequency detection status remains unchanged. When the controlled database is in the database low-frequency detection status, if a certain detection operation returns successfully, it jumps to the normal detection status and resumes detecting at the fixed period T. In the initial stage, when the actual number of detections < N, the number of detections is automatically filled to N, and the detection result is default assigned as 0, that is, the detection is successful. The maximum time interval threshold T max The default value is 24 hours. When the calculated theoretical time interval for the next detection exceeds T max make it equal to T max .

[0019] The above specific method adopts a dynamic adjustment mechanism. When an abnormality occurs in the previous detection process, it can dynamically postpone the subsequent detection time. This delay helps to avoid frequent invalid operations and effectively saves resources.

[0020] Based on the above method, the present invention further proposes a database state management system based on dynamic frequency adaptation, which system includes:

[0021] (1) Database self-state definition module, defining the set of database self-states and their conversion relationships;

[0022] (2) Cloud management platform detection state definition module, defining the set of cloud management platform detection states and their conversion relationships;

[0023] (3) Time period calculation module, dynamically calculating the time period for the next detection by the cloud management platform based on historical detection results.

[0024] Furthermore, in the database self-state definition module, the states of the database itself include normal state, database low-frequency detection state, stop monitoring state, initialization state. The normal state indicates that the current monitoring state of the controlled database is normal. The database low-frequency detection state indicates that an abnormality occurred during the previous process of establishing a connection with the controlled database, reducing the detection frequency of the connection state of the controlled database; the database low-frequency detection state can be further divided into the state where the number of connections from the platform to the controlled database reaches the upper limit, connection failure state, database port not connected state, user name and password error state.

[0025] Further, in the cloud management platform detection status definition module, the cloud management platform detection status includes a normal detection status, a detection failure status, a storage failure status, a detection timeout status, an initialization status, and a low-frequency detection status of the cloud management platform; the low-frequency detection status of the cloud management platform is further divided into a status where the number of detection failures reaches the upper limit and a status where the number of detection timeouts reaches the upper limit.

[0026] Further, in the time period calculation module, the specific steps for the cloud management platform to dynamically calculate the detection period are as follows:

[0027] (3.1) The results of the previous N detections are r1, r2,..., r in chronological order from earliest to latest, where i = 1, 2,..., N, i represents the i-th detection, r = 0 when the detection is successful, and r = 1 when the detection fails. N , i = 1, 2,...,N, i represents the i-th detection, r i =0 when the detection is successful, and when the detection fails, r i =1;

[0028] (3.2) Calculate the weight of the i-th detection result , where the decay rate ; <00..​​​​​​​​​​​​​​​​​​This invention clearly divides database states into two main categories: database self-state and cloud management platform probe states. Each state and its transition conditions are strictly symbolically defined, ensuring consistent understanding for developers and operations personnel and preventing state confusion. The trigger conditions between each state are clearly defined, providing an executable logical foundation for automated operations and anomaly handling. Based on historical success / failure sequences, a weighted exponential backoff method is used to dynamically calculate the next probe time. When consecutive failures occur, the probe frequency is significantly delayed, avoiding unnecessary operations that consume system resources. Through dynamic calculation of the decay rate, recent failures have a greater impact on the delay of the next probe time, aligning with the characteristic of anomalies often being continuous in actual operations and maintenance, making it more scientific than fixed-period probes. Low-frequency probes, combined with low-frequency probe states and a dynamic probe frequency algorithm, proactively reduce the probe frequency during anomaly periods, reducing invalid alarms and lowering the CPU / network / storage pressure on the controlled database and the management platform itself. Detailed Implementation

[0032] This invention proposes a refined database state management method to address the complex database state information in database cloud management platforms. This method not only describes the database's own state and the state detected by the cloud management platform, but also defines the possible transition conditions between various states. This method prevents confusion during database state usage on the database cloud management platform. The refined definition of states promotes more standardized and unified management, making it easy for developers and users to understand and preventing the platform from feeling complex or difficult to comprehend, thus improving the user experience.

[0033] Regarding the detection cycle of various database operating indicators, the above method also includes a dynamic frequency estimation (DFE) method. This method can dynamically adjust the detection cycle according to different database states, avoiding resource waste caused by fixed-cycle detection and reducing system resource pressure.

[0034] The database status is mainly divided into two parts:

[0035] (1) The state of the database itself, mainly including:

[0036] 1) Normal status: Indicates that the current monitoring status of the controlled database is normal, represented by Y;

[0037] 2) Low-frequency database probe state: This indicates an anomaly occurred during the connection establishment process with the controlled database. To avoid resource waste from fixed-period probes, the probe frequency for the controlled database connection state is reduced. The state of the controlled database at this time is recorded as the low-frequency database probe state. The reasons for the controlled database entering the low-frequency database probe state vary, therefore, the low-frequency database probe state is further divided into:

[0038] ① The platform reaches the limit on the number of connections to the controlled database: The cloud management platform accesses the controlled database frequently and establishes a large number of connections, reaching the connection limit and causing the connection to the controlled database to fail. The database in the platform enters a low-frequency database probing state, which is represented by C.

[0039] ② Connection failure: When encountering problems such as network interruption or firewall blocking the connection, the cloud management platform fails to connect to the controlled database. The database in the platform enters a low-frequency database probing state, which is represented by I.

[0040] ③ Database port not connected: The listening port of the controlled database service is not open or the IP / port configuration of the controlled database in the platform is incorrect. The cloud management platform shows that the controlled database port is not connected, and the database enters the low-frequency database detection state in the platform. This state is represented by H.

[0041] ④ Incorrect username and password: The provided controlled database username or password is incorrect, causing the cloud management platform to receive a clear authentication failure error. The database in the platform enters a low-frequency database probing state, which is represented by P.

[0042] 3) Stop monitoring: This state is the same as state P above, and both represent the state of the controlled database in the platform when the provided controlled database username or password is incorrect. This state is also represented by P.

[0043] 4) Initialization: In the cloud management platform, the controlled database has been managed, and the detection function for the controlled database's operating indicators has been enabled, but the detection time has not yet arrived, so detection has not yet started. This state is the initialization state of the controlled database in the platform, denoted by S.

[0044] (2) Cloud management platform detection status, mainly including:

[0045] 1) Normal status: This indicates that the cloud management platform is in normal condition.

[0046] The detection status of the controlled database's operating indicators is normal, represented by Y;

[0047] 2) Probe failure status: This indicates that the cloud management platform failed to execute the probe method when probing the operating indicators of the controlled database, denoted by U;

[0048] 3) Data storage failure status: This indicates that after the cloud management platform successfully detected the operating indicators of the controlled database, it failed to save the detected data into the cloud management platform's own database. It is represented by Z.

[0049] 4) Detection Timeout Status: This indicates that the cloud management platform exceeded the detection limit when detecting the operating indicators of the controlled database, resulting in a detection timeout, denoted by T;

[0050] 5) Initialization Status: In the cloud management platform, the controlled database has been managed, and the detection function for the controlled database's operating indicators has been enabled, but the detection time has not yet arrived, so detection has not yet started. This status is the initialization status of the controlled database in the platform, denoted by S.

[0051] 6) Low-frequency probe status on the cloud management platform: This indicates that the previous probe process for various operational indicators of the controlled database encountered an anomaly. To avoid resource waste caused by fixed-period probes, the probe frequency for various operational indicators of the controlled database is reduced. At this time, the controlled database is in the low-frequency probe status of the cloud management platform. The reasons for the controlled database entering the low-frequency probe status of the cloud management platform vary, therefore, the low-frequency probe status of the cloud management platform is further divided into:

[0052] ① The number of probe failures has reached the limit: The cloud management platform probes the operating indicators of the controlled database, but due to reasons such as the performance of the controlled database, multiple probes fail. The database in the platform enters the low-frequency probe state of the cloud management platform, which is represented by E.

[0053] ② The number of probe timeouts reaches the limit: The cloud management platform probes the operating indicators of the controlled database, but due to reasons such as the performance of the controlled database, multiple probes time out. The database in the platform enters the low-frequency probe state of the cloud management platform, which is represented by O.

[0054] In the aforementioned database states, both the database's own state and the cloud management platform's probe state include a low-frequency state. The former is called the database low-frequency probe state, and the latter is called the cloud management platform low-frequency probe state. The main reason for the low-frequency state is that anomalies in the database environment lead to probe failures. If probes continue at the normal frequency in this case, it will inevitably waste hardware resources, and triggering alarms after each anomaly will cause a surge in the number of alarms, resulting in a large number of alarm notifications for maintenance personnel. Therefore, this invention proposes a Dynamic Probe Frequency (DFE) algorithm. This algorithm can dynamically calculate the time for the next probe based on the results of several previous probes. The results of several previous probes may show continuous anomalies or intermittent anomalies. DFE can accurately calculate the time for the next probe according to different situations. DFE can more scientifically and dynamically determine the probe frequency when anomalies occur during the database cloud management platform's probe process, instead of probing at a fixed cycle as in traditional methods, thereby avoiding resource waste and reducing the pressure on system resources.

[0055] The specific process of the DFE algorithm is as follows:

[0056] (1) Initialization: Assume that the results of the previous N detections are, in chronological order from earliest to latest: r1, r2, …, r N , and let i = 1, 2, …, N, where i represents the i-th previous detection. If the i-th detection is successful, then r i = 0; if the i-th detection fails, then r i = 1. Generally, N takes values from 3 to 10.

[0057] (2) Weight calculation: Considering that among the results of the previous N detections, the result with an earlier time point has a lower influence, and the result closer to the current time has a higher influence, different weights are assigned to the results of the previous N detections. Let w i represent the weight of the i-th previous detection result, and its calculation method is:

[0058]

[0059] where λ is the attenuation rate, which determines the speed at which the weight decreases over time. In the DFE algorithm, the value of λ is determined through dynamic calculation, and the calculation method is as follows:

[0060] <0000​​​​​​​​​​​​​​​​​​​​​​​​The DFE algorithm employs a dynamic adjustment mechanism, which dynamically postpones subsequent probe times when an anomaly occurs in the previous probe process. This delay helps avoid frequent invalid operations and effectively conserves resources. Specific Implementation Example 1

[0067] Assuming N=5, there are 3 database performance metrics. The results of the previous N probes for these 3 performance metrics are shown in the table below.

[0068] Operating Indicator 1 0 0 0 1 1 Operating Indicator 2 0 0 1 1 1 Operating Indicator 3 1 1 1 1 1

[0069] The results of the three operational indicators were calculated separately.

[0070] (1) Operational Indicator 1

[0071] Considering that in the previous N probes, results from earlier times have lower influence, while results from times closer to the current time have higher influence, different weights are assigned to the results of the previous N probes, denoted by w. i The weight of the i-th previous probe result is calculated as follows:

[0072]

[0073] Here, λ is the decay rate, which determines how quickly the weight decreases over time. In the DFE algorithm, the value of λ is determined dynamically, as follows:

[0074]

[0075] For performance indicator 1, first calculate...

[0076] .

[0077] Then calculate the weight of each detection result:

[0078]

[0079]

[0080]

[0081]

[0082]

[0083] Then calculate the time for the next detection. Use t N t represents the time of the Nth detection. N+1 Let t represent the time of the next (N+1)th probe. N+1 The calculation method is as follows:

[0084]

[0085] Where T represents the fixed period of detection. Assuming t5 = 10 seconds and T = 1 second, we can obtain t6 = 14.705 seconds.

[0086] (2) Operational Indicator 2

[0087] For performance indicator 2, first calculate...

[0088]

[0089] Then calculate the weight of each detection result:

[0090]

[0091]

[0092]

[0093]

[0094]

[0095] Then calculate the next detection time. Assuming t5 = 10 seconds and T = 1 second, we can get t6 = 21.32 seconds.

[0096] (3) Operational Indicator 3

[0097] For performance indicator 3, first calculate...

[0098]

[0099] Then calculate the weight of each detection result:

[0100]

[0101]

[0102]

[0103]

[0104]

[0105] Then calculate the next detection time. Assuming t5 = 10 seconds and T = 1 second, we can get t6 = 158.413 seconds.

[0106] As can be seen from Example 1, the closer the detection failure is to the current time, the later the next detection time will be. In particular, when all the previous N (N=5) detections failed, the value of t6 reached a relatively large 158.413 seconds. It is evident that the DFE algorithm can dynamically adjust the detection frequency based on historical detection results. Especially when detection failures occur, by reducing unnecessary frequent detections, it can save energy and reduce the burden on the system.

[0107] The following is based on the format of "Specific Implementation Example 1" in the instruction manual you provided (73-Instruction Manual.docx). Specific Implementation Example 2

[0109] This embodiment demonstrates, through comparative experiments, the technical advantages of the Dynamic Frequency Estimation (DFE) algorithm described in this invention over traditional fixed-period detection methods in terms of resource consumption and alarm suppression.

[0110] A database cloud management platform manages 1000 controlled database instances. Each instance has a normal probe cycle of T=60 seconds, meaning it probes once per minute. A network jitter event occurred in a data center, causing 200 of the database instances to fail probes consecutively, with the failure lasting 30 minutes.

[0111] The simulation uses a traditional fixed-period probing scheme. During a 30-minute fault duration, each faulty instance undergoes a total of 30 probes (30 minutes ÷ 1 minute / probing) = 30 probes. For 200 instances, this totals 200 × 30 = 6000 probes. Since all probes fail during the fault, there are 6000 invalid network requests. Each failed probe triggers one alarm, resulting in a total of 6000 alarms.

[0112] The DFE algorithm of this invention was used to simulate the same scenario. N=5, T=60 seconds, and the failure mode was r=[0,0,0,1,1], meaning the first 3 attempts were successful and the last 2 failed. The detection time interval for each round was calculated sequentially according to the method described in Example 1. Rounds 1 to 5 maintained a fixed 60-second cycle, and the time interval dynamically lengthened from round 6 onwards. Calculations showed that each fault instance was detected approximately 15 times within 30 minutes. The total number of detections for 200 instances was 200 × 15 = 3000. Since failures mainly occurred in the later stages of the fault, and the detection frequency significantly decreased after the time interval was lengthened, the number of alarms was only triggered in the first few rounds, totaling approximately 600.

[0113] The above analysis shows that, compared with the traditional fixed-period detection scheme, the technical solution of this application reduces the number of single-instance detections, total detections, and invalid network requests by 50%, and the number of alarms by 90%. As can be seen from this embodiment, the DFE algorithm of this invention can dynamically lengthen the detection interval during anomaly detection, significantly reducing the number of invalid detections and network requests, while greatly reducing the number of alarms, effectively reducing system resource consumption and the workload of maintenance personnel. Once the detection is successful, the system will immediately resume fixed-period detection, ensuring that database operation indicators can be collected in a timely manner after fault recovery, achieving a balance between resource conservation and monitoring timeliness. Specific Implementation Example 3

[0115] This embodiment demonstrates, through comparative experiments, the technical advantages of the Dynamic Frequency Estimation (DFE) algorithm described in this invention compared to the traditional exponential backoff algorithm when dealing with different failure time distributions.

[0116] A database instance has a probe result sequence of r=[0,0,0,0,0,1,1,1,1,1] in the past 10 probes, meaning the first 5 probes were all successful, and the last 5 failed. The current time is after the 10th failed probe, and we need to calculate the time interval for the 11th probe. Assume a fixed period T=60 seconds.

[0117] Traditional exponential backoff algorithms typically employ the following rule: after the first failure, wait 2 seconds. 1 ×T, wait 2 seconds after the second consecutive failure. 2 ×T, and so on, after the kth consecutive failure, wait 2... k ×T, until a preset upper limit is reached. For the failure modes of this embodiment, there are...

[0118] After the 6th failed probe (the first consecutive failure): Wait 2 1 ×T=2T

[0119] After the 7th failed probe (2nd consecutive failure): Wait 2 2 ×T=4T

[0120] After the 8th failed probe (3rd consecutive failure): Wait 2 3 ×T=8 T

[0121] After the 9th failed probe (4th consecutive failure): Wait 2 4 ×T=16 T

[0122] After the 10th failed probe (5th consecutive failure): Wait 2 5 ×T=32 T

[0123] Therefore, the time interval for the 11th detection is 32 × 60 = 1920 seconds.

[0124] Calculate sequentially according to steps (3.1) to (3.3) of this invention.

[0125] Calculate the attenuation rate λ, substitute it into N=10, r1 to r5 is 0, r6 to r 10 If the value is 1, then λ = 15 / 41 ≈ 0.3659.

[0126] Calculate the weight of each detection result Only the failure location needs to be calculated. =1, ≈0.693, ≈0.480, ≈0.333, ≈0.231; Success position (r) i The weight of (=0) does not affect the subsequent index calculation results and does not need to be calculated.

[0127] Calculate the weighted failure sum Σ( ×r i =0.231+0.333+0.480+0.693+1=2.737.

[0128] Calculate the next detection time t 11 =15.43×60≈926 seconds.

[0129] The above analysis shows that when there are 5 consecutive failures (r=[1,1,1,1,1]), the DFE of this invention grows smoothly and does not back off excessively; when there are 5 intermittent failures (r=[1,0,1,0,1]), the DFE is sensitive to the failure distribution, while the traditional algorithm does not distinguish; when there are 5 recent failures (r=[0,0,0,1,1]), the DFE responds more reasonably to recent failures.

[0130] As can be seen from this embodiment, traditional exponential backoff algorithms only focus on the number of consecutive failures and cannot distinguish the temporal distribution characteristics of failures. Regardless of whether failures are concentrated in the recent period or scattered across various locations, the backoff time is the same as long as the number of consecutive failures is the same. In contrast, the DFE algorithm of this invention dynamically calculates the decay rate λ, so that the time position of failure appears in both the numerator and denominator, forming a nonlinear response to the failure distribution: recent failures have a greater impact on the delay of the next detection time, while the impact of early failures gradually decreases. This characteristic is more in line with the objective law that recent anomalies are more valuable than historical anomalies in actual operation and maintenance scenarios, achieving a more scientific and accurate detection frequency adaptation.

[0131] The units, devices, or modules described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. For ease of description, the above devices are described by dividing them into various modules according to their functions. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection between the devices or units shown or discussed can be through some interfaces, and the indirect coupling or communication connection between the devices or units can be electrical, mechanical, or other forms.

[0132] Those skilled in the art will also know that, besides implementing the controller using purely computer-readable program code, the same functions can be achieved by logically programming the method steps, making the controller function as logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers (PLCs), and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the devices within it used to implement various functions can also be considered structures within that hardware component. Alternatively, the devices used to implement various functions can be considered as both software modules implementing the method and structures within a hardware component.

[0133] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, classes, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0134] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0135] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. This application can be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices, etc.

[0136] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A database state management method based on dynamic frequency adaptation, characterized in that: The method includes the following steps: (1) Define the database's own state set and its transformation relationships; (2) Define the set of detection states of the cloud management platform and their transition relationships; (3) Based on historical detection results, dynamically calculate the time period for the next detection by the cloud management platform.

2. The database state management method based on dynamic frequency adaptation as described in claim 1, characterized in that: The database state in step (1) includes normal state, low-frequency database probe state, stopped monitoring state, and initialization state. The normal state indicates that the current monitoring state of the controlled database is normal. The low-frequency database probe state indicates that the previous process of establishing a connection with the controlled database was abnormal, and the probe frequency of the connection state of the controlled database is reduced. The low-frequency database probe status can be further divided into the following states: the platform has reached its maximum number of connections to the controlled database, connection failure, database port is not connected, and username and password are incorrect.

3. The database state management method based on dynamic frequency adaptation as described in claim 1, characterized in that: The cloud management platform detection status mentioned in step (2) includes normal detection status, detection failure status, data storage failure status, detection timeout status, initialization status, and low-frequency detection status of cloud management platform; the low-frequency detection status of cloud management platform is further divided into the detection failure count reaching the upper limit status and the detection timeout count reaching the upper limit status.

4. The database state management method based on dynamic frequency adaptation as described in claim 1, characterized in that: The specific steps for dynamically calculating the detection cycle in the cloud management platform in step (3) are as follows: (3.1) before N The results of the second probe, arranged chronologically from morning to night, are as follows: r 1, r 2, …, r N , i =1, 2, …, N , i Indicates the first i The next probe, when the probe is successful r i =0, when the probe fails. r i =1; (3.2) Calculate the first i Weight of the sub-detection results Among them, the attenuation rate ; (3.3) Calculate the next detection time , t N Indicates the first N The time of the second detection. t N+1 Indicates the first N +1 probe time, of which T It has a fixed cycle.

5. A database state management system based on dynamic frequency adaptation, characterized in that: The system includes: The database self-state definition module defines the database's own state set and its transformation relationships; The cloud management platform detection status definition module defines the set of cloud management platform detection statuses and their transformation relationships. The time period calculation module dynamically calculates the time period for the next probe on the cloud management platform based on historical probe results.

6. A database state management system based on dynamic frequency adaptation as described in claim 5, characterized in that: In the database self-state definition module, the database self-state includes normal state, database low-frequency detection state, stopped monitoring state, and initialization state. The normal state indicates that the current monitoring state of the controlled database is normal. The database low-frequency detection state indicates that the previous process of establishing a connection with the controlled database was abnormal, and the detection frequency of the connection state of the controlled database is reduced. The low-frequency database probe status can be further divided into the following states: the platform has reached its maximum number of connections to the controlled database, connection failure, database port is not connected, and username and password are incorrect.

7. A database state management system based on dynamic frequency adaptation as described in claim 5, characterized in that: In the cloud management platform detection status definition module, the cloud management platform detection status includes normal detection status, detection failure status, data storage failure status, detection timeout status, initialization status, and cloud management platform low-frequency detection status; the cloud management platform low-frequency detection status is further divided into the detection failure count reaching the upper limit status and the detection timeout count reaching the upper limit status.

8. A database state management system based on dynamic frequency adaptation as described in claim 5, characterized in that: In the time period calculation module, the specific steps for the cloud management platform to dynamically calculate the detection period are as follows: (3.1) before N The results of the second probe, arranged chronologically from morning to night, are as follows: r 1, r 2, …, r N , i =1, 2, …, N , i Indicates the first i The next probe, when the probe is successful r i =0, when the probe fails. r i =1; (3.2) Calculate the first i Weight of the sub-detection results Among them, the attenuation rate ; (3.3) Calculate the next detection time , t N Indicates the first N The time of the second detection. t N+1 Indicates the first N +1 probe time, of which T It has a fixed cycle.

Images