CN114791900A - Operator-based Redis operation and maintenance method, device, system and storage medium - Google Patents
Operator-based Redis operation and maintenance method, device, system and storage medium Download PDFInfo
- Publication number
- CN114791900A CN114791900A CN202210462668.2A CN202210462668A CN114791900A CN 114791900 A CN114791900 A CN 114791900A CN 202210462668 A CN202210462668 A CN 202210462668A CN 114791900 A CN114791900 A CN 114791900A
- Authority
- CN
- China
- Prior art keywords
- redis
- development
- cluster
- fault processing
- operator
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1464—Management of the backup or restore process for networked environments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1469—Backup restoration techniques
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application belongs to the field of finance and the field of cloud computing, and particularly relates to an Operator-based Redis operation and maintenance method, device, system and storage medium. The method includes the steps that whether Redis in at least two development clusters breaks down or not is monitored through an operation and maintenance management server, and the Redis in the at least two development clusters has a master-slave relationship; if the Redis of a first development cluster in the at least two development clusters is determined to have a fault, generating a fault processing task according to the first development cluster and the master-slave relationship, and determining an executive party of the fault processing task, wherein the fault processing task is used for indicating Redis fault processing; and sending the fault processing task to an executing party. The cross-cluster Redis operation and maintenance method and device based on the Operator can achieve cross-cluster Redis operation and maintenance based on the Operator under the use scenes of multiple data centers or disaster tolerance and the like.
Description
Technical Field
The application relates to the field of finance and cloud computing, in particular to a Redis operation and maintenance method, a Redis operation and maintenance device, a Redis operation and maintenance system and a storage medium based on Operator.
Background
Remote Dictionary service (Remote Dictionary Server, Redis) is widely used by a wide variety of developers in recent years as one of the most popular Key-value (KV) databases. With the gradual maturity of cloud computing technology, cloud becomes an industry consensus in business. In such a background, cloud-native containerized Redis database services have also come into play, for example, Operator is proposed to expand the ability of development clusters (also referred to as kubernets clusters) to manage stateful applications.
At present, a Redis operation and maintenance method based on Operator generally writes operation and maintenance logic of a Redis cluster in the Redis Operator based on a Custom Resource Definition (CRD) mechanism of a development cluster. However, the scope of the scheme is limited to a single development cluster, and the scheme is not applicable to the use scenes of multiple data centers, disaster recovery and the like.
Disclosure of Invention
The application provides a Redis operation and maintenance method, a device, a system and a storage medium based on Operator, which are used for realizing the Redis operation and maintenance of cross-cluster based on Operator in the use scenes of multiple data centers or disaster tolerance and the like.
In a first aspect, the present application provides an Operator-based Redis operation and maintenance method, which is applied to an operation and maintenance management server, where the operation and maintenance management server is used to perform operation and maintenance management on remote dictionary services Redis of at least two development clusters, and the Operator-based Redis operation and maintenance method includes: monitoring whether Redis in at least two development clusters fails or not, wherein the Redis in at least two development clusters has a master-slave relationship; if the Redis of a first development cluster in the at least two development clusters is determined to have a fault, generating a fault processing task according to the first development cluster and the master-slave relationship, and determining an executive party of the fault processing task, wherein the fault processing task is used for indicating to carry out Redis fault processing; and sending the fault processing task to an executing party.
In one possible embodiment, generating the fault handling task according to the first development cluster and the master-slave relationship includes: if the Redis in the first development cluster is determined to be the master Redis according to the first development cluster and the master-slave relationship, generating a fault processing task for indicating the first development cluster to adjust the master Redis to be the slave Redis and indicating one development cluster in other development clusters to adjust the slave Redis to be the master Redis; and if the Redis in the first development cluster is determined to be the secondary Redis according to the first development cluster and the master-slave relationship, generating a fault processing task for indicating the first development cluster to restart the Redis.
In one possible implementation, the method further includes: when first indication information used for creating a Redis container for a second development cluster in at least two development clusters is detected, generating a corresponding creation request, wherein the creation request is used for indicating the creation of the Redis container; and sending a creation request to the second development cluster.
In one possible embodiment, when first indication information for creating a Redis container for a second development cluster of the at least two development clusters is detected, generating a corresponding creation request includes: when the first indication information is detected, determining deployment parameters of Redis according to the first indication information, wherein the deployment parameters comprise Redis deployment rules, the number of Redis containers and a list of Redis to be created, and the Redis deployment rules are used for determining the master-slave relationship of Redis; determining the number of Redis according to a list of Redis to be created; generating a container list of Redis corresponding to the second development cluster according to the Redis deployment rule, the number of Redis and the number of Redis containers; from the container list, a create request is generated.
In one possible embodiment, the method further comprises: when second indication information used for deleting the Redis container for a third development cluster in the at least two development clusters is detected, generating a corresponding deletion request, wherein the deletion request is used for indicating the deletion of the Redis container; and sending a deletion request to the third issuing cluster.
In a second aspect, the present application provides an Operator-based Redis operation and maintenance method, which is applied to a server in a development cluster, where an operation and maintenance management server is used to perform operation and maintenance management on remote dictionary services Redis of at least two development clusters, and the Operator-based Redis operation and maintenance method includes: receiving a fault processing task sent by an operation and maintenance management server, wherein the fault processing task is generated according to the Redis master-slave relationship between a development cluster and at least two development clusters when the Redis of the development cluster fails, and is used for indicating to perform Redis fault processing; and performing Redis fault processing according to the fault processing task.
In one possible implementation, performing Redis fault handling according to a fault handling task includes: if the fault processing task is used for indicating that at least Redis of the development cluster is a master Redis and a fault occurs, adjusting the master Redis to be a slave Redis according to the fault processing task; and if the fault processing task is used for indicating that Redis of the development cluster is the secondary Redis and a fault occurs, restarting the secondary Redis according to the fault processing task.
In one possible embodiment, the method further comprises: receiving a creation request sent by an operation and maintenance management server, wherein the creation request is used for indicating the creation of a Redis container; according to the creation request, determining a self-defined resource definition (CRD) of Redis, wherein the CRD comprises first description information of a Redis creation task; generating a Redis container according to the first description information; redis is created from Redis containers.
In one possible embodiment, the method further comprises: receiving a deletion request sent by an operation and maintenance management server, wherein the deletion request is used for indicating to delete a Redis container; according to the deletion request, determining a user-defined resource definition (CRD) of Redis, wherein the CRD comprises second description information of a Redis deletion task; and deleting Redis according to the second description information.
In a third aspect, the present application provides an Operator-based Redis operation and maintenance apparatus, which is applied to an operation and maintenance management server, where the operation and maintenance management server is used to perform operation and maintenance management on remote dictionary services Redis of at least two development clusters, and the Operator-based Redis operation and maintenance apparatus includes: the monitoring module is used for monitoring whether Redis in at least two development clusters fails, and the Redis in the at least two development clusters has a master-slave relationship; the generating module is used for generating a fault processing task according to the first development cluster and the master-slave relationship if the Redis of the first development cluster in the at least two development clusters is determined to have a fault, and determining an executing party of the fault processing task, wherein the fault processing task is used for indicating to carry out Redis fault processing; and the sending module is used for sending the fault processing task to the executing party.
In a fourth aspect, the present application provides an Operator-based Redis operation and maintenance device, which is applied to a server in a development cluster, where an operation and maintenance management server is used to perform operation and maintenance management on remote dictionary services Redis of at least two development clusters, and the Operator-based Redis operation and maintenance device includes: the system comprises a receiving module, a fault processing module and a fault processing module, wherein the receiving module is used for receiving a fault processing task sent by an operation and maintenance management server, the fault processing task is generated according to a Redis master-slave relationship between a development cluster and at least two development clusters when the Redis of the development cluster fails, and the fault processing task is used for indicating to perform Redis fault processing; and the processing module is used for performing Redis fault processing according to the fault processing task.
In a fifth aspect, the present application provides an Operator-based Redis operation and maintenance system, including: the operation and maintenance management server and the servers in the at least two development clusters; the operation and maintenance management server is used for executing the Operator-based Redis operation and maintenance method of the first aspect; and developing a server in the cluster for executing the Operator-based Redis operation and maintenance method of the second aspect.
In a sixth aspect, the present application provides a server, comprising: a processor, and a memory communicatively coupled to the processor; the memory stores computer-executable instructions; the processor executes the memory-stored computer-executable instructions to implement the Operator-based Redis operation and maintenance method of the first aspect and/or to implement the Operator-based Redis operation and maintenance method of the second aspect.
In a seventh aspect, the present application provides a computer-readable storage medium, in which computer-executable instructions are stored, and when executed by a processor, the computer-executable instructions are used to implement the Operator-based Redis operation and maintenance method according to the first aspect or the second aspect.
In an eighth aspect, the present application provides a computer program product, including a computer program, where the computer program, when executed by a processor, implements the Operator-based Redis operation and maintenance method of the first aspect or the second aspect.
According to the Redis operation and maintenance method, device, system and storage medium based on Operator, Redis of at least two development clusters is established, deleted, monitored and the like across clusters through an operation and maintenance management server, when the operation and maintenance management server detects indication information used for establishing Redis containers for one or more of the at least two development clusters, an establishment request can be generated to indicate the one or more development clusters to establish Redis, or when the operation and maintenance management server detects the indication information used for deleting Redis containers for one or more of the at least two development clusters, a deletion request can be generated to indicate the one or more development clusters to delete Redis; and when monitoring that Redis of at least two development clusters has a fault, the operation and maintenance management server can generate a fault processing task and determine an executive party of the fault processing task, so that the executive party is instructed to execute the fault processing task, and cross-cluster Redis operation and maintenance based on Operator under the use scenes of multiple data centers or disaster tolerance and the like are realized.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.
Fig. 1 is a schematic structural diagram of an Operator-based Redis operation and maintenance system provided in the prior art;
fig. 2a is a schematic structural diagram of an Operator-based Redis operation and maintenance system according to an embodiment of the present application;
fig. 2b is a schematic view of an application scenario of the Operator-based Redis operation and maintenance method according to the embodiment of the present application;
fig. 3 is a flowchart of a first embodiment of an Operator-based Redis operation and maintenance method provided in the embodiment of the present application;
fig. 4 is a flowchart of a second embodiment of an Operator-based Redis operation and maintenance method according to the embodiment of the present application;
fig. 5 is a schematic structural diagram of a first embodiment of an Operator-based Redis operation and maintenance apparatus according to the embodiment of the present application;
fig. 6 is a schematic structural diagram of a second embodiment of an Operator-based Redis operation and maintenance apparatus according to the embodiment of the present application;
fig. 7 is a schematic structural diagram of a server according to an embodiment of the present application.
Specific embodiments of the present application have been shown by way of example in the drawings and will be described in more detail below. These drawings and the description are not intended to limit the scope of the present inventive concept in any way, but rather to illustrate it by reference to a specific embodiment for a person skilled in the art, from which further drawings may be derived, without inventive faculty, for a person skilled in the art.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
The terms referred to in this application are explained first:
kubernets: the container arrangement engine supports automatic deployment, large-scale expansion and application containerization management of containers;
CRD: the Kubernetes built-in resource type is used for creating resources of user-defined resource types;
operator: by extending kubernets custom controller, the corresponding crd resource is observed and the custom task is executed according to the actual state.
Redis: the remote dictionary service is an open source Application Programming Interface (API) which is written in ANSI C language, supports network, can be based on a memory, and can also be a persistent log-type Key-Value database, and can provide multiple languages.
Pod: the smallest resource management component in kubernets, Pod, is also the resource object that minimizes running containerized applications. One Pod represents one process running in the cluster. Most other components in kubernets surround the Pod to support and extend the functionality of the Pod.
In the prior art provided in the background art, at least the following technical problems exist:
redis is widely used by a large number of developers in recent years as one of the most popular KV databases at present. With the gradual maturity of cloud computing technology, cloud becomes an industry consensus in business. In such a background, a cloud-native containerized Redis database service has been developed. Among them, kubernets as a framework of container arrangement is very mature and powerful in management of stateless applications, but for management and arrangement of stateful applications like Redis, kubernets are not yet able to well meet the requirements of Redis. Thus, Operator was proposed to extend the ability of kubernets to manage stateful applications. Therefore, many Operator-based containerized Redis management components are currently emerging in the industry.
At present, a method for performing Redis operation and maintenance by a Redis management component based on an Operator is usually based on a CRD mechanism of Kubernetes, and an operation and maintenance logic of a Redis cluster is written in the Redis Operator, for example, operation and maintenance functions of creation/deletion of the Redis cluster, health check of the Redis cluster, failure handling of the Redis cluster, pushing of an event of the Redis cluster, and the like are performed, where each operation and maintenance function in the Redis Operator corresponds to a Redis Pod in the Redis cluster, and may be, as shown in fig. 1, a Redis Pod0, a Redis Pod1, a Redis Pod2, and a Redis Pod 3. However, the method has a defect that the scope is only limited to a single development cluster, and the operation and maintenance method is not suitable for use in the use scenes of multiple data centers or disaster recovery and the like.
In order to solve the above problems, the application provides an Operator-based Redis operation and maintenance method, which performs operation and maintenance management on Redis of at least two development clusters through an operation and maintenance management server, for example, performing cross-cluster creation, deletion, monitoring and the like on Redis of at least two development clusters. If the operation and maintenance management server monitors that Redis of at least two development clusters has a fault, the operation and maintenance management server can generate a fault processing task and determine an executive party of the fault processing task, so that the executive party is instructed to execute the fault processing task, and therefore the technical scheme of the application is not only suitable for Redis operation and maintenance based on Operator in a single development cluster using scene, but also suitable for Redis operation and maintenance based on Operator in a multi-data center or disaster-tolerant using scene including a plurality of development clusters.
In one embodiment, the Operator-based Redis operation and maintenance method can be applied in an application scenario. Fig. 2a is a schematic structural diagram of an Operator-based Redis operation and maintenance system according to an embodiment of the present application, and as shown in fig. 2a, the Operator-based Redis operation and maintenance system may include: the operation and maintenance management module comprises a plurality of development clusters, and the plurality of development clusters are assumed to comprise a development cluster 1 and a development cluster 2 in the graph.
In the above scenario, the development cluster 1 includes a Redis management custom resource definition module, a Redis Operator module, and a plurality of Redis containers, and the plurality of Redis containers includes Redis-Pod-0, Redis-Pod-1, Redis-Pod-2, and Redis-Pod-3 in FIG. 2 a. The modules and components included in development cluster 2 are the same as those in development cluster 1.
In the above scenario, the Redis management custom resource definition module is a medium for data interaction between the Redis Operator module and the operation and maintenance management module, and the Redis management custom resource definition module, that is, the Redis management CRD module, is actually a set of kubernets' CRD resources, and defines corresponding different CRD resources according to different Redis operation and maintenance functions.
In the above scenario, an operation and maintenance logic of Redis is written in a Redis Operator module, where the Redis operation and maintenance functions related to the present application include functions of Redis container creation/deletion, fault handling, cluster monitoring, and the like. The Redis Operator module is composed of a Redis Operator, and aiming at each Redis operation and maintenance CRD resource defined in the Redis management CRD module, a Controller is corresponding to the Redis Operator in the Redis Operator, and the Controller is responsible for executing the corresponding operation and maintenance task. Each Controller included in the Redis Operator is essentially a piece of code logic, and monitors a corresponding CRD resource in kubernets, and completes execution of an operation and maintenance task according to description in the CRD resource.
In the above scenario, the operation and maintenance management module may be configured to perform Redis cross-cluster scheduling, Redis cross-cluster fault processing, and Redis cross-cluster monitoring. With the Redis management CRD module and the Redis Operator module, the Redis operation and maintenance capability in a single development cluster is built, but in the use scene of a multi-data center or disaster tolerance and the like, when Redis is required to be deployed across clusters, the Redis operation and maintenance management module is required to carry out cross-cluster scheduling and operation and maintenance, so that the technical scheme of the application can be suitable for Redis operation and maintenance based on Operator in the use scene of a single development cluster, and is also suitable for Redis operation and maintenance based on Operator in the use scene of a multi-data center or disaster tolerance and the like containing a plurality of development clusters.
In the above scenario, the operation and maintenance management module may be deployed in an operation and maintenance management server, each development cluster in the multiple development clusters may include multiple servers, each server may have multiple Redis pods deployed therein, and the Redis pods deployed in all the servers in one development cluster may form a complete Redis, as shown in fig. 2 b.
Fig. 2b is a schematic view of an application scenario of the Operator-based Redis operation and maintenance method provided in this embodiment, in fig. 2b, the operation and maintenance management server 101 may perform data interaction with a server in the development cluster 102 and a server in the development cluster 103, multiple Redis pods that form a Redis of the development cluster are deployed in the server in the development cluster 102, and multiple Redis pods that form a Redis of the development cluster are deployed in the server in the development cluster 103, so that Operator-based cross-cluster Redis operation and maintenance in a usage scenario of multiple data centers or disaster tolerance may be implemented.
With reference to the above scenario, the following describes in detail how to solve the above technical problem and the technical solution of the present application with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.
Fig. 3 is a flowchart of a first embodiment of an Operator-based Redis operation and maintenance method provided in the embodiment of the present application, and as shown in fig. 3, the method is applied to an operation and maintenance management server, where the operation and maintenance management server is configured to perform operation and maintenance management on remote dictionary services Redis of at least two development clusters, and the method includes the following steps:
s301: monitoring whether Redis in at least two development clusters fails.
In this step, there is a master-slave relationship between the Redis in at least two development clusters, where the Redis in one development cluster is the master Redis, and the Redis in the other development cluster is the slave Redis.
In the above scheme, the operation and maintenance management server may monitor Redis in all development clusters in real time, and when it is monitored that Redis in a certain development cluster or a certain number of development clusters fails, a failure processing task may be generated, so that the Redis in the failed development cluster may perform failure processing.
S302: and if the Redis of the first development cluster in the at least two development clusters is determined to have a fault, generating a fault processing task according to the first development cluster and the master-slave relationship, and determining an executive party of the fault processing task.
In this step, the trouble processing task is used to instruct the Redis trouble processing to be performed.
In the above scheme, whether Redis in the first development cluster is master Redis or slave Redis may cause different fault processing tasks and different task executors, and therefore, it is necessary to generate a fault processing task according to a master-slave relationship between a development cluster in which Redis fails and the Redis, and determine an executor of the fault processing task.
S303: and sending the fault processing task to an executing party.
In this step, after the executing party is determined, the operation and maintenance management server may send a fault handling task to the executing party, and the executing party may perform fault handling.
In the above solution, the executing party is also a server in the development cluster, and the operation and maintenance management server sends the fault processing task to the executing party, that is, sends the fault processing task to the server in the development cluster.
In the Redis operation and maintenance method based on Operator provided by the embodiment, the Redis of at least two development clusters is monitored in a cross-cluster manner through the operation and maintenance management server, and when the Redis of at least two development clusters fails, a fault processing task can be generated and an executive party of the fault processing task can be determined, so that the executive party of the fault processing task is instructed to execute the fault processing task, therefore, the method is not only suitable for the Redis operation and maintenance based on Operator in a single development cluster use scene, but also can be used for the Redis operation and maintenance based on Operator in a multi-data center or disaster tolerance use scene containing a plurality of development clusters.
In one embodiment, generating the fault handling task from the first development cluster and the master-slave relationship comprises: if the Redis in the first development cluster is determined to be the master Redis according to the first development cluster and the master-slave relationship, generating a fault processing task for indicating the first development cluster to adjust the master Redis to be the slave Redis and indicating one development cluster in other development clusters to adjust the slave Redis to be the master Redis; and if the Redis in the first development cluster is determined to be the slave Redis according to the first development cluster and the master-slave relationship, generating a fault processing task for indicating the first development cluster to restart the Redis.
In the scheme, when the master Redis fails and the slave Redis does not fail, master-slave switching is required, the master Redis is adjusted to the slave Redis, and the slave Redis is adjusted to the master Redis; when the slave Redis fails and the master Redis does not fail, the slave Redis only needs to be restarted. Therefore, the failure processing task can be generated according to the failed first development cluster and the master-slave relationship of Redis.
In the above solution, if the Redis of the first development cluster fails and the Redis of the first development cluster is the master Redis, the master Redis and the slave Redis need to be subjected to master-slave exchange, at this time, an executing party of the failure processing task is one of the first development cluster and the other development clusters, the first development cluster is used to adjust the master Redis to the slave Redis and can recover the backup data, and one of the other development clusters is used to adjust the slave Redis to the master Redis.
In the above solution, if the Redis of the first development cluster fails and the Redis of the first development cluster is the slave Redis, only the slave Redis needs to be restarted, at this time, an executing party of the failure processing task is the first development cluster, and the first development cluster is used to restart the slave Redis and simultaneously recover the backup data.
In the above scheme, a CRD resource of the type FaultsHandler may be used to describe a certain fault handling task. The core fields of the CRD resource of the type FaultsHandler may include: a Pod field for describing the execution object Pod of the fault handling task, which may be represented as Pod: redis-group 0-0-0; an operation field, which is used to describe the specific operation of the fault processing task, such as restarting Redis, main Redis and secondary Redis switching, backup data recovery, etc., for example, the operation field may be represented as operation: restart, which represents that the specific operation of the fault processing task is restart; a faultsTypeNumber field for describing the fault code that the fault handling task needs to resolve the fault, which may be represented as faultsTypeNumber 10; the faultstypelame field is used for describing a fault name of a fault processing task needing to solve the fault, and can be expressed as faultstypelame, namely out of memory, by way of example. After the fault resolution is completed, the Controller may set the status bit as successful, that is, set status as successful, indicating that the execution of the current fault processing task is completed.
In one embodiment, further comprising: when first indication information used for creating a Redis container for a second development cluster in at least two development clusters is detected, generating a corresponding creation request, wherein the creation request is used for indicating the creation of the Redis container; and sending a creation request to the second development cluster.
In the scheme, when Redis in a second development cluster needs to be created, a user can issue an instruction for creating Redis across the clusters through interactive operation, and after responding to the instruction, the operation and maintenance management server parses the instruction, so that first indication information used for creating a Redis container for the second development cluster in at least two development clusters in the instruction is detected, a creation request is generated, and the creation request is sent to the second development cluster needing to create Redis, so that the second development cluster can create Redis.
In the above solution, the number of the second development clusters may be one or multiple. When the number of the second development clusters is multiple, the operation and maintenance management server may send creation requests to the multiple second development clusters, respectively, so that the second development clusters receiving the creation requests may all create Redis.
In one embodiment, upon detecting first indication information for creating a Redis container for a second development cluster of the at least two development clusters, generating a corresponding creation request includes: when the first indication information is detected, determining deployment parameters of Redis according to the first indication information, wherein the deployment parameters comprise Redis deployment rules, the number of Redis containers and a list of Redis to be created, and the Redis deployment rules are used for determining the master-slave relationship of the Redis; determining the number of Redis according to a list of Redis to be created; generating a container list of Redis corresponding to the second development cluster according to the Redis deployment rule, the number of Redis and the number of Redis containers; from the container list, a create request is generated.
In this scheme, after detecting the first indication information, the operation and maintenance management server may determine a deployment parameter of Redis, where the deployment parameter mainly includes: the method includes the following steps that Redis deployment rules (which may also be called deployment modes), the number of Redis containers (i.e., the number of data fragments or Pod of Redis), and a list of Redis to be created (i.e., a Kubernets list) are set, the Redis deployment rules may be used to determine a master-slave relationship across Redis clusters, the list of Redis to be created may correspond to the Kubernets list, and which Kubernets (i.e., second development clusters) need to create Redis; then generating corresponding CRD resources, such as Redis PodList resources, according to the Redis deployment rules; and calling a second development cluster needing Redis creation, and creating a corresponding Redis PodList resource, so as to trigger a Redis Operator corresponding to the second development cluster to execute the Redis Pod creation task.
In the above solution, after sending the creation request to the second development cluster, the operation and maintenance management server may query, to each second development cluster, the creation condition of the RedisPodList resource, summarize the creation information, and determine the condition that each second development cluster creates Redis. The operation and maintenance management server can realize Redis cross-cluster deployment rule logic and distribution and summarization of creation information, so that the operation and maintenance management server has the Redis cross-cluster scheduling capability, and the technical scheme can be suitable for Operator-based cross-cluster Redis operation and maintenance in use scenes such as multiple data centers or disaster tolerance.
In the above scheme, the deployment parameter of Redis may be input by a user, and after detecting the first indication information, the operation and maintenance management server may query the deployment parameter of Redis input by the user, so as to obtain the deployment parameter.
In the above scheme, since the master-slave relationship of the Redis is already determined by the Redis deployment rule, when a plurality of second development clusters are provided, the creation request generated by the operation and maintenance management system also includes the master-slave relationship of the plurality of rediss, and after the second development cluster receives the creation request, the corresponding master Redis or slave Redis can be created according to the master-slave relationship.
In one embodiment, further comprising: when second indication information used for deleting the Redis container for a third development cluster in the at least two development clusters is detected, generating a corresponding deletion request, wherein the deletion request is used for indicating the deletion of the Redis container; and sending a deletion request to the third issuing cluster.
In this solution, the operation and maintenance management server may instruct the development cluster to delete Redis, in addition to instruct the development cluster to create Redis. When a user needs to delete Redis in one or more development clusters, for example, a third development cluster, an instruction for deleting a Redis container may be issued through an interactive operation, and after responding to the instruction, the operation and maintenance management server parses the instruction, thereby detecting second instruction information used for deleting the Redis container for the third development cluster in at least two development clusters in the instruction, thereby generating a deletion request, and sending the deletion request to the third development cluster that needs to delete Redis, so that the third development cluster may delete Redis.
Fig. 4 is a flowchart of a second embodiment of an Operator-based Redis operation and maintenance method provided in the embodiment of the present application, and as shown in fig. 4, the method is applied to a server in a development cluster, an operation and maintenance management server is used for performing operation and maintenance management on remote dictionary services Redis of at least two development clusters, and the method includes the following steps:
s401: and receiving the fault processing task sent by the operation and maintenance management server.
In this step, the fault processing task is generated by the operation and maintenance management server according to the Redis master-slave relationship between the development cluster and at least two development clusters when the Redis of the development cluster fails, and the fault processing task is used for indicating to perform Redis fault processing.
In the above scheme, the operation and maintenance management server may monitor whether Redis in at least two development clusters fails, and if it is determined that Redis of a certain development cluster in the at least two development clusters fails, a fault processing task may be generated according to a master-slave relationship between the development cluster and the Redis, and an executor of the fault processing task may be determined.
In the above solution, a development cluster with a fault in Redis in at least two development clusters may be an executing party of a fault processing task, and in this case, it is described that Redis in the development cluster may be a master Redis or a slave Redis. When the Redis in the development cluster is the main Redis, the executing party of the fault processing task can also be one of the development clusters which do not have faults in the Redis in the at least two development clusters; when Redis in the development cluster is Slave Redis, the executor of the fault handling task is only the development cluster.
S402: and performing Redis fault processing according to the fault processing task.
In this step, after receiving the fault handling task sent by the operation and maintenance management server, the development cluster may perform Redis fault handling according to an instruction of the fault handling task.
In one embodiment, Redis fault handling according to a fault handling task includes: if the fault processing task is used for indicating that at least Redis of the development cluster is a master Redis and a fault occurs, adjusting the master Redis to be a slave Redis according to the fault processing task; and if the fault processing task is used for indicating that Redis of the development cluster is the secondary Redis and a fault occurs, restarting the secondary Redis according to the fault processing task.
In this solution, when a development cluster performs Redis fault processing according to a fault processing task, if the fault processing task is used to indicate that Redis of the development cluster is a master Redis and fails, the development cluster needs to adjust the master Redis to a slave Redis, and meanwhile, a certain development cluster of which Redis not failed in at least two development clusters needs to adjust the slave Redis to a master Redis, so that master-slave switching of the Redis can be achieved, and a problem that the entire data system cannot be used when the master Redis failed is avoided.
In the above scheme, if the fault processing task is used to indicate that the Redis of the development cluster is the slave Redis and a fault occurs, the slave Redis does not affect the use of the entire data system, and therefore the development cluster only needs to be restarted from the Redis.
In the above scheme, the operation and maintenance management server may monitor Redis in a plurality of development clusters in real time, and send a fault processing task to the development clusters when a fault is found. In addition, the development cluster can also monitor Redis by itself, and when the Redis has a fault, the development cluster reports fault information to the operation and maintenance management server, and the operation and maintenance management server can generate a fault processing task according to the received fault information and send the fault processing task to the corresponding development cluster, so that the corresponding development cluster can perform Redis fault processing according to the processing task.
In the above scheme, when a development cluster monitors Redis by itself, it may be determined whether a failure occurs in Redis by monitoring a CRD resource, for example, a CRD resource of the type clusterSupervisory may be monitored, and the CRD resource of the type clusterSupervisory may be used to describe a parameter necessary for monitoring the development cluster, for example, a prometheusdadd field may be used to describe an address of a monitoring component prometheus, and for example, the prometheusdadd field may be represented as prometheusdadd, Redis-group 0-0-0; an eventManagerAdd field, which may be used to describe the address of the event management component, and which may be denoted as eventManagerAdd, for example, restart; a monitorendexandthreshold field, which may be used to define monitoring data items and alarm thresholds, for example, may be expressed as monitorendexandthreshold: cpu: 90; and 70, memory. Thus, the self-monitoring of the development cluster can be realized.
In one embodiment, further comprising: receiving a creation request sent by an operation and maintenance management server, wherein the creation request is used for indicating the creation of a Redis container; according to the creation request, determining a Custom Resource Definition (CRD) of Redis, wherein the CRD comprises first description information of a Redis creation task; generating a Redis container according to the first description information; redis is created from Redis containers.
In the scheme, after the development cluster receives a creation request sent by an operation and maintenance management server, a redisPodList _ controller in a Redis Operator module of the development cluster can query a kube-api component to see whether a new CRD resource is generated, for example, the RedispedList resource, and if not, the query is continued; if yes, a corresponding Redis container can be created according to first description information in a newly generated Redis PodList resource, namely Redis Pod is created, specifically, a field value in the Redis PodList resource is analyzed out and then the field value is transmitted to a field of the Redis Pod as a parameter; then checking whether the Redis Pod creation task is completed or not, and continuously retrying if the Redis Pod creation task is not completed; if the Redis Pod is successfully created, a status flag bit status of the Redis Listpod may be set to succade, which indicates that the creation of the Redis Listpod resource is completed, that is, the Redis creation in the development cluster is completed.
In the above scheme, a CRD resource of type RedisPodList may be used for information describing aspects of a set of Redis Pod that requires processing by a Redis Operator. For example, the pos field in the sepc field may be used to describe the number of Pod contained in reds, and for example, the pos field may be represented as pos: 2, which represents that the number of Pod is 2; the redisImage field may be used to describe the mirror used by the set of Redis Pods, and may be expressed, for example, as redisImage: dockerhub.com:5000/Redis: 5.0.0; the resources field may be used to describe the specification of the set of Redis Pod, and may be expressed as limits, cpu: "1"; memory is 1 Gi; requests CPU: "1"; memory is 1 Gi; storageSize is 100 Gi; the storageType is hostPath.
In the above solution, it should be noted that the redispostlist _ controller may allocate a thread to each RedisListPod resource, that is, multiple tasks for creating the RedisListPod resource may be executed in parallel without interfering with each other.
In one embodiment, further comprising: receiving a deletion request sent by an operation and maintenance management server, wherein the deletion request is used for indicating to delete a Redis container; according to the deletion request, determining a user-defined resource definition (CRD) of Redis, wherein the CRD comprises second description information of a Redis deletion task; and deleting Redis according to the second description information.
In this embodiment, if the development cluster receives a deletion request sent by the operation and maintenance management server, the development cluster may determine, according to the deletion request, second description information in the CRD resource, for example, second description information in the RedisPodList resource, so as to delete the corresponding Redis, specifically, delete a field value in the Redis Pod (the field value is a field value in a field that parses a field value in the RedisPodList resource and then passes to the Redis Pod as a parameter).
In the above scheme, when a certain RedisListPod resource is deleted, the redislistlist _ controller queries that the resource does not exist, and then may trigger a procedure of deleting the RedisListPod.
In the Operator-based Redis operation and maintenance method provided in this embodiment, an operation and maintenance management server performs cross-cluster creation, deletion, monitoring, and the like on Redis of at least two development clusters, and when detecting indication information for creating a Redis container for one or more development clusters of the at least two development clusters, the operation and maintenance management server may generate a creation request to indicate the one or more development clusters to create the Redis, or when detecting indication information for deleting the Redis container for one or more development clusters of the at least two development clusters, may generate a deletion request to indicate the one or more development clusters to delete the Redis; moreover, when the operation and maintenance management server monitors that the Redis of at least two development clusters has a fault, the operation and maintenance management server can generate a fault processing task and determine an executive party of the fault processing task, so that the executive party is instructed to execute the fault processing task, and therefore cross-cluster Redis operation and maintenance based on Operator can be achieved under the use scene including a plurality of development clusters such as a multi-data center or disaster recovery.
In general, the technical scheme provided by the application is a technical scheme which can be suitable for Operator-based Redis operation and maintenance in a single development cluster use scene, and can also be suitable for Operator-based Redis operation and maintenance across clusters in a plurality of development cluster use scenes.
The embodiment of the application further provides an Operator-based Redis operation and maintenance device, which is applied to an operation and maintenance management server and is used for performing operation and maintenance management on the remote dictionary service Redis of at least two development clusters. Fig. 5 is a schematic structural diagram of a first embodiment of an Operator-based Redis operation and maintenance apparatus according to an embodiment of the present application, and as shown in fig. 5, the Operator-based Redis operation and maintenance apparatus 500 includes:
the monitoring module 501 is configured to monitor whether Redis in at least two development clusters fails, where the Redis in the at least two development clusters has a master-slave relationship;
a generating module 502, configured to generate a fault processing task according to the first development cluster and the master-slave relationship if it is determined that Redis of a first development cluster of the at least two development clusters has a fault, and determine an executor of the fault processing task, where the fault processing task is used to instruct Redis fault processing;
a sending module 503, configured to send the fault handling task to the executing party.
Optionally, there is a master-slave relationship between Redis in at least two development clusters, and the generating module 502 may be further specifically configured to: if the Redis in the first development cluster is determined to be the master Redis according to the first development cluster and the master-slave relationship, generating a fault processing task for indicating the first development cluster to adjust the master Redis to be the slave Redis and indicating one development cluster in other development clusters to adjust the slave Redis to be the master Redis; and if the Redis in the first development cluster is determined to be the slave Redis according to the first development cluster and the master-slave relationship, generating a fault processing task for indicating the first development cluster to restart the Redis.
Optionally, the Operator-based Redis operation and maintenance apparatus 500 may further include: a first detection module (not shown) that can be configured to: when first indication information used for creating a Redis container for a second development cluster in at least two development clusters is detected, generating a corresponding creation request, wherein the creation request is used for indicating the creation of the Redis container; and sending a creation request to the second development cluster.
Optionally, when detecting first indication information used to create a Redis container for a second development cluster of the at least two development clusters and generating a corresponding creation request, the first detection module may be specifically configured to: when the first indication information is detected, determining deployment parameters of Redis according to the first indication information, wherein the deployment parameters comprise Redis deployment rules, the number of Redis containers and a list of Redis to be created, and the Redis deployment rules are used for determining the master-slave relationship of Redis; determining the number of Redis according to a list of Redis to be created; generating a container list of Redis corresponding to the second development cluster according to the Redis deployment rule, the number of Redis and the number of Redis containers; from the container list, a create request is generated.
Optionally, the Operator-based Redis operation and maintenance apparatus 500 may further include: a second detection module (not shown) that can be used to: when second indication information used for deleting Redis containers for third development clusters in at least two development clusters is detected, generating corresponding deletion requests, wherein the deletion requests are used for indicating deletion of the Redis containers; and sending a deletion request to the third issuing cluster.
The Operator-based Redis operation and maintenance device provided in this embodiment is used to implement the technical solution of the Operator-based Redis operation and maintenance method applied to the operation and maintenance management server in the foregoing method embodiment, and the implementation principle and technical effect are similar, which are not described herein again.
The embodiment of the application further provides an Operator-based Redis operation and maintenance device, which is applied to a server in the development cluster, wherein the operation and maintenance management server is used for performing operation and maintenance management on the Redis of the remote dictionary services of at least two development clusters. Fig. 6 is a schematic structural diagram of a second embodiment of an Operator-based Redis operation and maintenance apparatus 600 according to an embodiment of the present application, as shown in fig. 6, the Operator-based Redis operation and maintenance apparatus 600 includes:
the receiving module 601 is configured to receive a fault processing task sent by the operation and maintenance management server, where the fault processing task is generated according to a master-slave relationship between a development cluster and at least two development clusters when a Redis of the development cluster fails, and the fault processing task is used to instruct to perform Redis fault processing;
and the processing module 602 is configured to perform Redis fault processing according to the fault processing task.
Optionally, the processing module 602 may be specifically configured to: if the fault processing task is used for indicating that the Redis of the development cluster is a master Redis and a fault occurs, adjusting the master Redis to be a slave Redis according to the fault processing task; and if the fault processing task is used for indicating that Redis of the development cluster is the secondary Redis and a fault occurs, restarting the secondary Redis according to the fault processing task.
Optionally, the Redis operation and maintenance apparatus 600 based on Operator may further include: a creation module (not shown) that can be used to: receiving a creation request sent by an operation and maintenance management server, wherein the creation request is used for indicating the creation of a Redis container; according to the creation request, determining a Custom Resource Definition (CRD) of Redis, wherein the CRD comprises first description information of a Redis creation task; generating a Redis container according to the first description information; redis is created from Redis containers.
Optionally, the Operator-based Redis operation and maintenance apparatus 600 may further include: a deletion module (not shown) that can be used to: receiving a deletion request sent by an operation and maintenance management server, wherein the deletion request is used for indicating that a Redis container is deleted; according to the deletion request, determining a self-defined resource definition (CRD) of the Redis, wherein the CRD comprises second description information of the Redis deletion task; and deleting Redis according to the second description information.
The Operator-based Redis operation and maintenance device provided in this embodiment is used to implement the technical solution of the Operator-based Redis operation and maintenance method applied to develop a server in a cluster in the foregoing method embodiment, and the implementation principle and technical effect are similar, which are not described herein again.
The embodiment of the present application further provides an Operator-based Redis operation and maintenance system, where the Operator-based Redis operation and maintenance system includes: the operation and maintenance management server and the servers in the at least two development clusters; the operation and maintenance management server is used for executing the Operator-based Redis operation and maintenance method applied to the operation and maintenance management server; the servers in the development cluster are used for executing the Operator-based Redis operation and maintenance method applied to the servers in the development cluster.
The embodiment of the application also provides a server. Fig. 7 is a schematic structural diagram of a server according to an embodiment of the present disclosure, and as shown in fig. 7, a server 700 may include a processing component 701, which further includes one or more processors, and a memory resource represented by a memory 702 for storing instructions, such as an application program, executable by the processing component 701. The application programs stored in memory 702 may include one or more modules that each correspond to a set of instructions. Further, the processing component 701 is configured to execute instructions to perform an embodiment of the Operator-based Redis operation and maintenance method described above.
The server 700 may also include a power component 703, the power component 703 configured to perform power management of the server 700, a wired or wireless network interface 704 configured to connect the server 700 to a network, and an input output (I/O) interface 705. The server 700 may operate based on an operating system stored in memory 702, such as Windows Server, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, or the like.
The Memory may be, but is not limited to, a Random Access Memory (RAM), a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Read-Only Memory (EPROM), an electrically Erasable Read-Only Memory (EEPROM), and the like. The memory is used for storing programs, and the processor executes the programs after receiving the execution instructions. Further, the software programs and modules within the aforementioned memories may also include an operating system, which may include various software components and/or drivers for managing system tasks (e.g., memory management, storage device control, power management, etc.), and may communicate with various hardware or software components to provide an operating environment for other software components.
The processor may be an integrated circuit chip having signal processing capabilities. The Processor may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Network Processor (NP), and the like. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
An embodiment of the present application further provides a computer-readable storage medium, where a computer-executable instruction is stored in the computer-readable storage medium, and when the computer-executable instruction is executed by a processor, the computer-executable instruction is used to implement the technical solution of the Operator-based Redis operation and maintenance method provided in the foregoing method embodiment.
The embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the computer program is used to implement the technical solution of the Operator-based Redis operation and maintenance method provided in the foregoing method embodiment.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
It will be understood that the present application is not limited to the precise arrangements that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.
Claims (14)
1. A Redis operation and maintenance method based on Operator is applied to an operation and maintenance management server, the operation and maintenance management server is used for performing operation and maintenance management on remote dictionary services Redis of at least two development clusters, and the Redis operation and maintenance method based on Operator comprises the following steps:
monitoring whether Redis in the at least two development clusters fails, wherein the Redis in the at least two development clusters has a master-slave relationship;
if the Redis of a first development cluster in the at least two development clusters is determined to have a fault, generating a fault processing task according to the first development cluster and the master-slave relationship, and determining an executing party of the fault processing task, wherein the fault processing task is used for indicating to carry out Redis fault processing;
and sending the fault processing task to the executive party.
2. The Operator-based Redis operation and maintenance method according to claim 1, wherein the generating a fault handling task according to the first development cluster and the master-slave relationship comprises:
if the Redis in the first development cluster is determined to be a master Redis according to the first development cluster and the master-slave relationship, generating the fault processing task to be used for indicating the first development cluster to adjust the master Redis to be a slave Redis and indicating one development cluster in other development clusters to adjust the slave Redis to be the master Redis;
and if the Redis in the first development cluster is determined to be a slave Redis according to the first development cluster and the master-slave relationship, generating the fault processing task to be used for indicating the first development cluster to restart the Redis.
3. The Operator-based Redis operation and maintenance method according to claim 1 or 2, further comprising:
when first indication information used for creating a Redis container for a second development cluster in the at least two development clusters is detected, generating a corresponding creation request, wherein the creation request is used for indicating the creation of the Redis container;
and sending the creation request to the second development cluster.
4. The Operator-based Redis operation and maintenance method according to claim 3, wherein the generating a corresponding creation request when detecting first indication information for creating a Redis container for a second development cluster of the at least two development clusters comprises:
when the first indication information is detected, determining deployment parameters of Redis according to the first indication information, wherein the deployment parameters comprise Redis deployment rules, the number of Redis containers and a list of Redis to be created, and the Redis deployment rules are used for determining the master-slave relationship of Redis;
determining the number of Redis according to the list of Redis to be created;
generating a container list of Redis corresponding to the second development cluster according to the Redis deployment rule, the number of Redis and the number of Redis containers;
and generating the creation request according to the container list.
5. The Operator-based Redis operation and maintenance method according to claim 1 or 2, further comprising:
when second indication information used for deleting Redis containers for third development clusters in the at least two development clusters is detected, generating corresponding deletion requests, wherein the deletion requests are used for indicating that the Redis containers are deleted;
and sending the deletion request to the third sending cluster.
6. The Redis operation and maintenance method based on the Operator is applied to a server in a development cluster, an operation and maintenance management server is used for performing operation and maintenance management on remote dictionary services Redis of at least two development clusters, and the Redis operation and maintenance method based on the Operator comprises the following steps:
receiving a fault processing task sent by the operation and maintenance management server, wherein the fault processing task is generated by the operation and maintenance management server according to the Redis master-slave relationship between the development cluster and at least two development clusters when the Redis of the development cluster fails, and the fault processing task is used for indicating Redis fault processing;
and performing Redis fault processing according to the fault processing task.
7. The Operator-based Redis operation and maintenance method according to claim 6, wherein the performing Redis fault processing according to the fault processing task comprises:
if the fault processing task is used for indicating that the Redis of the development cluster is a master Redis and a fault occurs, adjusting the master Redis to be a slave Redis according to the fault processing task;
and if the fault processing task is used for indicating that Redis of the development cluster is a secondary Redis and a fault occurs, restarting the secondary Redis according to the fault processing task.
8. The Operator-based Redis operation and maintenance method according to claim 6 or 7, further comprising:
receiving a creation request sent by an operation and maintenance management server, wherein the creation request is used for indicating the creation of a Redis container;
according to the creation request, determining a self-defined resource definition (CRD) of Redis, wherein the CRD comprises first description information of a Redis creation task;
generating a Redis container according to the first description information;
and creating Redis according to the Redis container.
9. The Operator-based Redis operation and maintenance method according to claim 6 or 7, further comprising:
receiving a deletion request sent by an operation and maintenance management server, wherein the deletion request is used for indicating that a Redis container is deleted;
according to the deletion request, determining a self-defined resource definition (CRD) of Redis, wherein the CRD comprises second description information of a Redis deletion task;
and deleting Redis according to the second description information.
10. The Redis operation and maintenance device based on the Operator is applied to an operation and maintenance management server, the operation and maintenance management server is used for performing operation and maintenance management on remote dictionary services Redis of at least two development clusters, and the Redis operation and maintenance device based on the Operator comprises:
the monitoring module is used for monitoring whether Redis in the at least two development clusters fails or not, and the Redis in the at least two development clusters has a master-slave relationship;
a generating module, configured to generate a fault processing task according to the first development cluster and the master-slave relationship if it is determined that Redis of a first development cluster of the at least two development clusters has a fault, and determine an executing party of the fault processing task, where the fault processing task is used to instruct to perform Redis fault processing;
and the sending module is used for sending the fault processing task to the executive party.
11. An Operator-based Redis operation and maintenance device, which is applied to a server in a development cluster, wherein an operation and maintenance management server is used for performing operation and maintenance management on remote dictionary services Redis of at least two development clusters, and the Operator-based Redis operation and maintenance device comprises:
a receiving module, configured to receive a fault processing task sent by the operation and maintenance management server, where the fault processing task is generated by the operation and maintenance management server according to a master-slave relationship between the development cluster and at least two Redis of the development cluster when a Redis of the development cluster fails, and the fault processing task is used to instruct to perform Redis fault processing;
and the processing module is used for carrying out Redis fault processing according to the fault processing task.
12. An Operator-based Redis operation and maintenance system, comprising: the operation and maintenance management server and the servers in the at least two development clusters;
the operation and maintenance management server is used for executing the Operator-based Redis operation and maintenance method according to any one of claims 1 to 5;
the server in the development cluster is used for executing the Operator-based Redis operation and maintenance method according to any one of claims 6 to 9.
13. A server, comprising: a processor, and a memory communicatively coupled to the processor;
the memory stores computer execution instructions;
the processor executes the computer-executable instructions stored in the memory to implement the Operator-based Redis operation and maintenance method of any one of claims 1 to 5 and/or to implement the Operator-based Redis operation and maintenance method of any one of claims 6 to 9.
14. A computer-readable storage medium having stored thereon computer-executable instructions for implementing the Operator-based Redis operation and maintenance method according to any one of claims 1 to 9 when executed by a processor.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210462668.2A CN114791900A (en) | 2022-04-28 | 2022-04-28 | Operator-based Redis operation and maintenance method, device, system and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210462668.2A CN114791900A (en) | 2022-04-28 | 2022-04-28 | Operator-based Redis operation and maintenance method, device, system and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114791900A true CN114791900A (en) | 2022-07-26 |
Family
ID=82462234
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210462668.2A Pending CN114791900A (en) | 2022-04-28 | 2022-04-28 | Operator-based Redis operation and maintenance method, device, system and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114791900A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115567549A (en) * | 2022-09-22 | 2023-01-03 | 中国联合网络通信集团有限公司 | Data caching method and device, electronic equipment and readable storage medium |
-
2022
- 2022-04-28 CN CN202210462668.2A patent/CN114791900A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115567549A (en) * | 2022-09-22 | 2023-01-03 | 中国联合网络通信集团有限公司 | Data caching method and device, electronic equipment and readable storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110389900B (en) | Distributed database cluster testing method and device and storage medium | |
| CN107783975B (en) | Method and device for synchronous processing of distributed databases | |
| CN109634728B (en) | Job scheduling method and device, terminal equipment and readable storage medium | |
| CN105357038A (en) | Method and system for monitoring virtual machine cluster | |
| US20120159421A1 (en) | System and Method for Exclusion of Inconsistent Objects from Lifecycle Management Processes | |
| CN106940699B (en) | Synchronous processing method, device, server and system for memory data | |
| EP3591485B1 (en) | Method and device for monitoring for equipment failure | |
| US10924538B2 (en) | Systems and methods of monitoring software application processes | |
| US11157373B2 (en) | Prioritized transfer of failure event log data | |
| WO2020232951A1 (en) | Task execution method and device | |
| CN112199355B (en) | Data migration method and device, electronic equipment and storage medium | |
| CN111190732A (en) | Timed task processing system and method, storage medium and electronic device | |
| CN114791900A (en) | Operator-based Redis operation and maintenance method, device, system and storage medium | |
| CN111435356A (en) | Data feature extraction method and device, computer equipment and storage medium | |
| CN115437766A (en) | Task processing method and device | |
| CN113127036B (en) | Software development system, method, apparatus and medium for continuous integration of code | |
| CN115729590A (en) | Service deployment method, device, equipment and computer readable storage medium | |
| CN110188008B (en) | Job scheduling master-slave switching method and device, computer equipment and storage medium | |
| CN110489208B (en) | Virtual machine configuration parameter checking method, system, computer equipment and storage medium | |
| WO2022009438A1 (en) | Server maintenance control device, system, control method, and program | |
| JP2009199213A (en) | Process monitoring method, information processing apparatus and program | |
| CN105677515A (en) | Online backup method and system for database | |
| CN112231231A (en) | Method, system and device for debugging cloud service | |
| CN113220407A (en) | Fault drilling method and device | |
| CN116932274B (en) | Heterogeneous computing system and server system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |