CN115543687A - ETCD cluster service data recovery method, device, equipment and storage medium - Google Patents

ETCD cluster service data recovery method, device, equipment and storage medium Download PDF

Info

Publication number
CN115543687A
CN115543687A CN202211182354.3A CN202211182354A CN115543687A CN 115543687 A CN115543687 A CN 115543687A CN 202211182354 A CN202211182354 A CN 202211182354A CN 115543687 A CN115543687 A CN 115543687A
Authority
CN
China
Prior art keywords
data
file
configmap
service data
target service
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
Application number
CN202211182354.3A
Other languages
Chinese (zh)
Inventor
高松
张晨
黄韬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Network Communication and Security Zijinshan Laboratory
Original Assignee
Network Communication and Security Zijinshan Laboratory
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Network Communication and Security Zijinshan Laboratory filed Critical Network Communication and Security Zijinshan Laboratory
Priority to CN202211182354.3A priority Critical patent/CN115543687A/en
Publication of CN115543687A publication Critical patent/CN115543687A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/142—Reconfiguring to eliminate the error
    • 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
    • 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
    • G06F16/211—Schema design and management
    • 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G06F9/4451—User profiles; Roaming

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The application discloses a method, a device, equipment and a storage medium for recovering ETCD cluster service data, and relates to the technical field of cloud protogenesis. The method comprises the following steps: acquiring target service data in the ETCD cluster; the target service data is data of a service which is recovered according to selection in all services of the ETCD cluster; creating a ConfigMap file by using the target service data; and when the ETCD cluster is restarted, performing data recovery on the target service data by using the ConfigMap file. According to the technical scheme, the ConfigMap is used for achieving recovery of the configuration data of the ETCD from the whole unified recovery to the service level refinement. The user command line operation of the ETCD cluster configuration data recovery is reduced, and the operation difficulty and the error probability of actual operation and maintenance personnel are reduced from a certain degree. In the field of micro-services, a new innovation of autonomous and flexible control of data recovery from a service angle is realized.

Description

ETCD cluster service data recovery method, device, equipment and storage medium
Technical Field
The invention relates to the technical field of cloud-native, in particular to a method, a device, equipment and a storage medium for recovering ETCD cluster service data.
Background
The ETCD is a distributed, highly available, consistent key-value storage database. Based on Go language implementation, the method is mainly used for shared configuration and service discovery. In the distributed system, the ETCD can manage the configuration information in a centralized mode, the server side stores the configuration information in the ETCD, the client side obtains the service configuration information through the ETCD, the ETCD monitors the change of the configuration information, and the client side is informed when the change is found. In conventional ETCD data recovery, it is common practice to backup a DB (database) file on a cluster basis, and then perform recovery using a designated DB when the cluster is recovered. As shown in fig. 1, a conventional DB file recovery method is shown, it can be seen that configuration data recovery of an ETCD includes all data, however, when data recovery is performed by this method, if a subsequent service exits from K8S (kubernets) deployment, a lot of historical useless configuration data will remain in the ETCD, and when the ETCD restarts and recovers data again, the useless data are recovered as a part of a DB, which wastes space resources.
In summary, how to flexibly control data recovery and reduce waste of space resources is a problem to be solved at present.
Disclosure of Invention
In view of this, an object of the present invention is to provide a method, an apparatus, a device and a storage medium for recovering ETCD cluster service data, which can flexibly control data recovery and reduce waste of space resources. The specific scheme is as follows:
in a first aspect, the application discloses an ETCD cluster service data recovery method, which includes:
acquiring target service data in the ETCD cluster; the target service data is data of a service which is recovered according to selection in all services of the ETCD cluster;
creating a ConfigMap file by using the target service data;
and when the ETCD cluster is restarted, performing data recovery on the target service data by using the ConfigMap file.
Optionally, before obtaining the target service data in the ETCD cluster, the method further includes:
and defining a corresponding key value prefix for the target service data so as to obtain the key value data of the target service data through the key value prefix.
Optionally, the creating a ConfigMap file by using the target service data includes:
and writing the target service data into a file according to a preset writing format based on the key value prefix so as to obtain the ConfigMap file.
Optionally, after creating the ConfigMap file by using the target service data, the method further includes:
and storing the ConfigMap file to a specified path of the Pod so as to make the target service data persistent through mounting.
Optionally, the performing data recovery on the target service data by using the ConfigMap file includes:
determining a JSON format file or a YAML format file corresponding to the ConfigMap file based on the file content of the ConfigMap file;
and reading the content of the JSON format file or the YAML format file, and performing data recovery on the target service data by using key value data converted from the read content.
Optionally, the method for recovering ETCD cluster service data further includes:
and performing data recovery on the target service data by using the ConfigMap file based on a Kubernetes mechanism.
In a second aspect, the present application discloses an ETCD cluster service data recovery device, including:
the business data acquisition module is used for acquiring target business data in the ETCD cluster; the target service data is data of a service which is recovered according to selection in all services of the ETCD cluster;
a ConfigMap file creating module, configured to create a ConfigMap file using the target service data;
and the data recovery module is used for performing data recovery on the target service data by using the ConfigMap file when the ETCD cluster is restarted.
Optionally, the data recovery module is specifically configured to determine, based on the file content of the ConfigMap file, a JSON format file corresponding to the ConfigMap file; and reading the content of the JSON format file through the target service data, and converting the read content into key value data of the target service data.
In a third aspect, the present application discloses an electronic device comprising a processor and a memory; wherein the memory is used for storing a computer program, and the computer program is loaded and executed by the processor to realize the ETCD cluster service data recovery method.
In a fourth aspect, the present application discloses a computer readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the ETCD cluster service data recovery method as described above.
In the application, target service data in an ETCD cluster are obtained; the target service data is data of a service which is recovered according to selection in all services of the ETCD cluster; creating a ConfigMap file by using the target business data; and when the ETCD cluster is restarted, performing data recovery on the target service data by using the ConfigMap file. Therefore, the business can selectively recover the data according to the needs, the ConfigMap file is created by using the target business data, the ConfigMap is used for achieving recovery of the ETCD cluster business data, the recovery of the ETCD configuration data is integrally and uniformly recovered, the recovery of the business level is refined, meanwhile, the user command line operation of the recovery of the ETCD cluster configuration data is reduced, and the operation difficulty and the error probability of actual operation and maintenance personnel are reduced on a certain level. In the field of micro-services, a new innovation of autonomous and flexible control of data recovery from a service angle is realized.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
FIG. 1 is a diagram illustrating a conventional DB file recovery method disclosed in the present application;
fig. 2 is a flowchart of an ETCD cluster service data recovery method disclosed in the present application;
FIG. 3 is a schematic diagram of an exemplary selected target business data disclosed herein;
fig. 4 is a schematic diagram illustrating recovery of ETCD cluster service data disclosed in the present application;
fig. 5 is a flowchart of a specific method for recovering ETCD cluster service data disclosed in the present application;
fig. 6 is a schematic structural diagram of an ETCD cluster service data recovery device disclosed in the present application;
fig. 7 is a block diagram of an electronic device disclosed in the present application.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Currently, in the recovery of the ETCD data, a DB file is backed up on the basis of a cluster, and then when the cluster is recovered, a specified DB is used for recovery. However, when data recovery is performed by the method, if a subsequent service exits from the K8S deployment, a lot of historical useless configuration data will remain in the ETCD, and the useless data are recovered as a part of the DB when the ETCD is restarted and data are recovered again, so that space resources are wasted.
Therefore, the application provides an ETCD cluster service data recovery scheme which can flexibly control data recovery and reduce waste of space resources.
The embodiment of the invention discloses an ETCD cluster service data recovery method, which is shown in figure 2 and comprises the following steps:
step S11: acquiring target service data in the ETCD cluster; and the target service data is the data of the service which is recovered according to selection in all the services of the ETCD cluster.
The recovery of configuration data of the ETCD cluster in the prior art contains all data, and when a service exits, the recovery process of restarting the ETCD contains a lot of useless data, so that the waste of space resources is caused. Therefore, in the embodiment of the present application, the service may configure whether the stored data is recovered according to the need, for example, some data, and the service does not need to be recovered, for example, the intermediate information stored in the DB; for example, alarm information temporary data; therefore, data of the service which is selected to be recovered in the ETCD cluster is obtained. As shown in fig. 3, the design idea is given, the service data can be selected for recovery, and for example, only the service a data and the service B data are recovered as provided in fig. 3.
In the embodiment of the application, the business data stored in the ETCD cluster can reasonably arrange the Key value, so that all configuration data of one business can be read from the ETCD completely by using one prefix. Specifically, a corresponding key value prefix is defined for the target service data, so as to obtain the key value data of the target service data through the key value prefix. Such as: the controller has three services, i.e. Service _ a, service _ B, and Service _ C, and in order to make the respective Service data of the three services capable of being queried by using a prefix, the following format is designed, taking Service _ a as an example, and all the prefix of key values is defined as follows:
/key/service/{Service_A}/{subModular}
then, the microservice of the Service _ a can acquire all KVs at one time through the prefix/key/Service/{ Service _ a } of the ETCD, and since KVs is a simple storage and management mode specially used for data storage and retrieval and has high system expandability, the data of all the Service _ a can be queried through KVs, which is a basis.
Step S12: and creating a ConfigMap file by using the target business data.
In the embodiment of the present application, data generated by the ConfigMap is prepared, that is, a ConfigMap file is created by using the target service data.
It can be understood that there are 4 ways to create the ConfigMap: the first is created by specifying the configmap parameter directly in the command line, i.e. -from-execute; the second is creation by specifying a file, i.e. creating a configuration file as a ConfigMap-from-file = < file >; the third is created by specifying directories, that is, creating all configuration files under a directory as a ConfigMap, — from-file = < directory >; the fourth is a yaml file written with standard configmap in advance, and then created with kubecect create-f. In this embodiment of the present application, a second method that creates a ConfigMap by using a specific file is used for introduction, and any other method that creates a ConfigMap to achieve recovery of the ETCD cluster service data may refer to the introduction of the embodiment of the present application, which is not described herein again.
In the embodiment of the present application, since key value prefixes are respectively set for different services, based on the key value prefixes, the target service data is written into a file according to a preset write format, so as to obtain the ConfigMap file. Such as: writing the service KV (key-value/KVs) data read out from the ETCD cluster into a file app
/key/service/{Service_A}/interface＝“eth1”
/key/service/{Service_A}/domain＝“domain1025”。
It can be understood that, in this format, key = "/Key/Service/{ Service _ a }/interface", and Value = "eth1", then the format stored in the configmap file is/Key/Service/{ Service _ a }/interface = "eth1", which means that the interface of the Service _ a Service in the ETCD is eth1; accordingly, in this format, key = "/Key/Service/{ Service _ a }/domain", and Value = "domain1025", which means that the Service _ a Service is set or acquired in the ETCD, and the security domain name is domain1025.
Further, after creating the ConfigMap file by using the target service data, the ConfigMap file is stored in a specified path of the Pod, so that the target service data is persisted by mounting. That is, the ConfigMap file is stored in a specified path in the Pod, and the service data is persisted to a certain path of the host machine in a mount manner. Therefore, after the ConfigMap file is created, user command line operation of ETCD cluster configuration data recovery is reduced, and operation difficulty and error probability of actual operation and maintenance personnel are reduced on a certain level.
Step S13: and when the ETCD cluster is restarted, performing data recovery on the target service data by using the ConfigMap file.
In the embodiment of the present application, the data recovery may be performed on the target service data by using the ConfigMap file based on a kubernets mechanism, and as shown in fig. 4, a specific method for implementing the data recovery method of the etcd trunking service by using the ConfigMap in a K8S environment is illustrated.
In the embodiment of the application, because the ConfigMap is used for realizing the recovery of the ETCD cluster service data, after the ETCD is restarted, only the created ConfigMap file needs to be used for regenerating the ConfigMap, the data conversion is carried out on the content in the file, the database writing operation is completed again after the data conversion is completed, and the recovery of the ETCD cluster service data is realized.
Specifically, the performing data recovery on the target service data by using the ConfigMap file includes: determining a JSON format file or a YAML format file corresponding to the ConfigMap file based on the file content of the ConfigMap file; and reading the content of the JSON format file or the YAML format file, and performing data recovery on the target service data by using key value data converted from the read content. In the embodiment of the present application, a JSON format file is used as an example for introduction, and the YAML format file may refer to the introduction of the embodiment, which is not described herein again.
It should be noted that when the ETCD is restarted or redeployed, the operation and maintenance personnel only need to use the app.properties file to generate a ConfigMap (named etcdstore) in the K8S cluster: a Service which needs data recovery, such as generation of a Service _ a sensing etcdstore json file, reads contents; and reading the content in the etcstore. In addition, since the process is equivalent to re-uninstalling the ETCD program, re-installation, and the configuration within this newly deployed ETCD is empty, maintenance of the previous historical data may not be required.
In the embodiment of the application, target service data in an ETCD cluster are obtained; the target service data is data of a service which is recovered according to selection in all services of the ETCD cluster; creating a ConfigMap file by using the target service data; and when the ETCD cluster is restarted, performing data recovery on the target service data by using the ConfigMap file. Therefore, the service can selectively restore the data according to the needs, the target service data is used for creating the ConfigMap file, the ConfigMap is used for realizing the recovery of the ETCD cluster service data, the recovery of the configuration data of the ETCD is integrally recovered in a unified way, the recovery of the service level is refined, meanwhile, the user command line operation of the recovery of the configuration data of the ETCD cluster is reduced, and the operation difficulty and the error probability of actual operation and maintenance personnel are reduced in a certain level. In the field of micro-services, a new innovation of autonomous and flexible control of data recovery from a service angle is realized.
The embodiment of the application discloses a specific ETCD cluster service data recovery method, which is shown in FIG. 5 and comprises the following steps:
step S21: and defining a corresponding key value prefix for the target service data so as to obtain the key value data of the target service data through the key value prefix.
In the embodiment of the application, key values are reasonably programmed for the service data stored in the ETCD cluster in advance, so that all configuration data of one service can be queried through prefixes. If a key value prefix is defined for the service A data: therefore, all KVs of the Service A data can be queried through the prefix/key/Service/{ Service _ A }/{ subModular }.
Step S22: and acquiring target service data in the ETCD cluster.
The recovery of the configuration data of the ETCD cluster in the prior art contains all data, and when a service exits, the process of restarting and recovering the ETCD contains a lot of useless data, so that the waste of space resources is caused. Therefore, in the embodiment of the present application, the service may configure whether the stored data is recovered according to the need, for example, some data, and the service does not need to be recovered, for example, the intermediate information stored in the DB; such as alarm information temporary data. Therefore, the target service data is data of a service which is recovered according to selection in all services of the ETCD cluster.
Step S23: and writing the target service data into a file according to a preset writing format based on the key value prefix so as to obtain the ConfigMap file.
In the embodiment of the present application, the read service data, that is, the data of the service to be restored according to the selection is written into an app.
/key/service/{Service_A}/interface＝“eth1”
/key/service/{Service_A}/domain＝“domain1025”
As can be appreciated, in an ETCD: key = "/Key/Service/{ Service _ a }/interface"; value = "eth1"; the format stored in the configmap file is/key/Service/{ Service _ a }/interface = "eth1".
Step S24: and storing the ConfigMap file to a specified path of Pod so as to make the target service data persistent by mounting.
In the embodiment of the present application, data generated by the ConfigMap is file app, properties, and therefore, the data is stored in a specified path in the Pod, and the service data is persisted to a certain path of the host in a mount manner, for example:
volumes:
-name:etcdstore
hostPath:
path:/etc/db/serviceA
type:DirectoryOrCreate
configMap:
name:etcdstore
step S25: and determining a JSON format file or a YAML format file corresponding to the ConfigMap file based on the file content of the ConfigMap file.
In the embodiment of the present application, a JSON format file is used as an example for introduction. When the ETCD is redeployed, the operation and maintenance personnel only need to use the app.properties file to generate the ConfigMap (named etcStore) in the K8S cluster: and generating a target service perception etcdstore json file which needs to be restored, and reading content.
Step S26: and reading the content of the JSON format file or the YAML format file, and performing data recovery on the target service data by using key value data converted from the read content.
In the embodiment of the application, a target service perception etcdstore json file which needs to be restored is generated, after content is read, the read content is converted into KV data, and library writing operation is completed again by utilizing the converted KV data, so that data restoration of the target service is completed. Therefore, the configuration data recovery of the ETCD is recovered from the whole in a unified way, and the recovery of the business level is refined. In the field of micro service, the method has certain engineering practice significance. In addition, since the process is equivalent to re-uninstalling the ETCD program, re-installation, and the configuration within this newly deployed ETCD is empty, maintenance of the previous historical data may not be required.
In the embodiment of the application, a corresponding key value prefix is defined for the target service data, so that the key value data of the target service data can be obtained through the key value prefix; acquiring target service data in the ETCD cluster; based on the key value prefix, writing the target service data into a file according to a preset writing format to obtain the ConfigMap file; storing the ConfigMap file to a specified path of Pod so as to make the target service data persistent by mounting; determining a JSON format file or a YAML format file corresponding to the ConfigMap file based on the file content of the ConfigMap file; and reading the content of the JSON format file or the YAML format file, and performing data recovery on the target service data by using key value data converted from the read content. Therefore, the business can selectively recover the data according to the needs, the ConfigMap file is created by using the target business data, the ConfigMap is used for achieving recovery of the ETCD cluster business data, the recovery of the ETCD configuration data is integrally and uniformly recovered, the recovery of the business level is refined, meanwhile, the user command line operation of the recovery of the ETCD cluster configuration data is reduced, and the operation difficulty and the error probability of actual operation and maintenance personnel are reduced on a certain level. In the field of micro-services, a new innovation of autonomous and flexible control of data recovery from a service angle is realized.
Correspondingly, the embodiment of the present application further discloses an ETCD cluster service data recovery device, as shown in FIG. 6, the device includes:
the service data acquisition module 11 is used for acquiring target service data in the ETCD cluster; the target service data is data of a service which is recovered according to selection in all services of the ETCD cluster;
a ConfigMap file creating module 12, configured to create a ConfigMap file using the target service data;
and the data recovery module 13 is configured to perform data recovery on the target service data by using the ConfigMap file when the ETCD cluster is restarted.
For more specific working processes of the modules, reference may be made to corresponding contents disclosed in the foregoing embodiments, and details are not repeated here.
Therefore, by the scheme of the embodiment, the target service data in the ETCD cluster is acquired; the target service data is data of a service which is recovered according to selection in all services of the ETCD cluster; creating a ConfigMap file by using the target service data; and when the ETCD cluster is restarted, performing data recovery on the target service data by using the ConfigMap file. Therefore, the service can selectively restore the data according to the needs, the target service data is used for creating the ConfigMap file, the ConfigMap is used for realizing the recovery of the ETCD cluster service data, the recovery of the configuration data of the ETCD is integrally recovered in a unified way, the recovery of the service level is refined, meanwhile, the user command line operation of the recovery of the configuration data of the ETCD cluster is reduced, and the operation difficulty and the error probability of actual operation and maintenance personnel are reduced in a certain level. In the field of micro-services, a new innovation of autonomous and flexible control of data recovery from a service angle is realized.
In a specific implementation manner, the data recovery module 13 is specifically configured to determine, based on the file content of the ConfigMap file, a JSON format file corresponding to the ConfigMap file; and reading the content of the JSON format file through the target service data, and converting the read content into key value data of the target service data.
In a specific implementation manner, the ETCD cluster service data recovery is further configured to define a corresponding key value prefix for the target service data before the target service data in the ETCD cluster is acquired, so as to acquire the key value data of the target service data through the key value prefix.
In a specific embodiment, the ConfigMap file creating module 12 includes:
and the file writing unit is used for writing the target service data into a file according to a preset writing format based on the key value prefix so as to obtain the ConfigMap file.
In a specific embodiment, the ConfigMap file creating module 12 further includes:
and the target business data persistence unit is used for storing the ConfigMap file to a specified path of the Pod after the ConfigMap file is created by using the target business data so as to persist the target business data through mounting.
In a specific embodiment, the ConfigMap file creating module 12 includes:
the format file determining unit is used for determining a JSON format file or a YAML format file corresponding to the ConfigMap file based on the file content of the ConfigMap file;
a content reading unit, configured to read content of the JSON-format file or the YAML-format file;
and the data recovery unit is used for performing data recovery on the target service data by using the key value data converted from the read content.
In a specific implementation manner, the ETCD cluster service data recovery device is further configured to perform data recovery on the target service data by using the ConfigMap file based on a Kubernets mechanism.
Further, an electronic device is disclosed in the embodiments of the present application, and fig. 7 is a block diagram of an electronic device 20 according to an exemplary embodiment, which should not be construed as limiting the scope of the application.
Fig. 7 is a schematic structural diagram of an electronic device 20 according to an embodiment of the present disclosure. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input output interface 25, and a communication bus 26. Wherein the memory 22 is adapted to store a computer program, which is loaded and executed by the processor 21, to implement the steps of:
acquiring target service data in the ETCD cluster; the target service data is data of a service which is recovered according to selection in all services of the ETCD cluster;
creating a ConfigMap file by using the target service data;
and when the ETCD cluster is restarted, performing data recovery on the target service data by using the ConfigMap file.
In some specific embodiments, before acquiring the target service data in the ETCD cluster, the method may further include the following steps:
and defining a corresponding key value prefix for the target service data so as to obtain the key value data of the target service data through the key value prefix.
In some specific embodiments, the creating a ConfigMap file by using the target service data may specifically implement the following steps:
and writing the target service data into a file according to a preset writing format based on the key value prefix so as to obtain the ConfigMap file.
In some specific embodiments, after creating the ConfigMap file by using the target service data, the method may further include the following steps:
and storing the ConfigMap file to a specified path of the Pod so as to make the target service data persistent through mounting.
In some specific embodiments, the performing data recovery on the target service data by using the ConfigMap file may specifically implement the following steps:
determining a JSON format file or a YAML format file corresponding to the ConfigMap file based on the file content of the ConfigMap file;
and reading the content of the JSON format file or the YAML format file, and performing data recovery on the target service data by using key value data converted from the read content.
In some embodiments, the method may further comprise the following steps:
and performing data recovery on the target service data by using the ConfigMap file based on a Kubernetes mechanism.
In addition, the electronic device 20 in this embodiment may be specifically a server. In this embodiment, the power supply 23 is configured to provide a working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and an external device, and a communication protocol followed by the communication interface is any communication protocol applicable to the technical solution of the present application, and is not specifically limited herein; the input/output interface 25 is configured to obtain external input data or output data to the outside, and a specific interface type thereof may be selected according to specific application requirements, which is not specifically limited herein.
In addition, the memory 22 is used as a carrier for storing resources, and may be a read-only memory, a random access memory, a magnetic disk, an optical disk, or the like, the resources stored thereon may include an operating system 221, a computer program 222, data 223, and the like, and the data 223 may include various data. The storage means may be a transient storage or a permanent storage.
The operating system 221 is used for managing and controlling each hardware device on the electronic device 20 and the computer program 222, and may be Windows Server, netware, unix, linux, or the like. The computer program 222 may further include a computer program that can be used to perform other specific tasks in addition to the computer program that can be used to perform the method for recovering the ETCD cluster service data, which is executed by the electronic device 20 and disclosed in any of the foregoing embodiments.
Further, embodiments of the present application disclose a computer-readable storage medium, where the computer-readable storage medium includes a Random Access Memory (RAM), a Memory, a Read-Only Memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a magnetic disk, or an optical disk, or any other form of storage medium known in the art. The computer program is executed by a processor to realize the ETCD cluster service data recovery method. For the specific steps of the method, reference may be made to the corresponding contents disclosed in the foregoing embodiments, which are not described herein again.
The embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same or similar parts among the embodiments are referred to each other. The device disclosed in the embodiment corresponds to the method disclosed in the embodiment, so that the description is simple, and the relevant points can be referred to the description of the method part.
The steps of the ETCD cluster traffic data recovery or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
Finally, it should also be noted that, in this document, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising a," "8230," "8230," or "comprising" does not exclude the presence of additional like elements in a process, method, article, or apparatus that comprises the element.
The method, the device, the equipment and the storage medium for recovering the ETCD cluster service data provided by the invention are described in detail, specific examples are applied in the text to explain the principle and the implementation mode of the invention, and the description of the above embodiments is only used for helping to understand the method and the core idea of the invention; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.

Claims (10)

1. The ETCD cluster service data recovery method is characterized by comprising the following steps:
acquiring target service data in the ETCD cluster; the target service data is data of a service which is recovered according to selection in all services of the ETCD cluster;
creating a ConfigMap file by using the target business data;
and when the ETCD cluster is restarted, performing data recovery on the target service data by using the ConfigMap file.
2. The ETCD cluster service data recovery method according to claim 1, wherein before obtaining the target service data in the ETCD cluster, the method further comprises:
and defining a corresponding key value prefix for the target service data so as to obtain the key value data of the target service data through the key value prefix.
3. The ETCD cluster service data recovery method according to claim 2, wherein the creating a ConfigMap file using the target service data comprises:
and writing the target service data into a file according to a preset writing format based on the key value prefix so as to obtain the ConfigMap file.
4. The ETCD cluster business data recovery method according to claim 1, wherein after creating the ConfigMap file by using the target business data, the method further comprises:
and storing the ConfigMap file to a specified path of the Pod so as to make the target service data persistent through mounting.
5. The ETCD cluster business data recovery method according to claim 1, wherein the data recovery of the target business data by using the ConfigMap file comprises:
determining a JSON format file or a YAML format file corresponding to the ConfigMap file based on the file content of the ConfigMap file;
and reading the content of the JSON format file or the YAML format file, and performing data recovery on the target service data by using key value data converted from the read content.
6. The ETCD cluster traffic data recovery method according to any one of claims 1 to 5, further comprising:
and performing data recovery on the target service data by using the ConfigMap file based on a Kubernetes mechanism.
7. The utility model provides a ETCD cluster business data recovery unit which characterized in that includes:
the business data acquisition module is used for acquiring target business data in the ETCD cluster; the target service data is data of a service which is recovered according to selection in all services of the ETCD cluster;
a ConfigMap file creation module for creating a ConfigMap file using the target service data;
and the data recovery module is used for performing data recovery on the target service data by using the ConfigMap file when the ETCD cluster is restarted.
8. The ETCD cluster service data recovery device according to claim 7, wherein the data recovery module is specifically configured to determine, based on the file content of the ConfigMap file, a JSON format file corresponding to the ConfigMap file; and reading the content of the JSON format file through the target service data, and converting the read content into key value data of the target service data.
9. An electronic device, wherein the electronic device comprises a processor and a memory; wherein the memory is used for storing a computer program which is loaded and executed by the processor to implement the ETCD cluster traffic data recovery method according to any one of claims 1 to 6.
10. A computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the ETCD cluster traffic data recovery method of any of claims 1 to 6.
CN202211182354.3A 2022-09-27 2022-09-27 ETCD cluster service data recovery method, device, equipment and storage medium Pending CN115543687A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211182354.3A CN115543687A (en) 2022-09-27 2022-09-27 ETCD cluster service data recovery method, device, equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211182354.3A CN115543687A (en) 2022-09-27 2022-09-27 ETCD cluster service data recovery method, device, equipment and storage medium

Publications (1)

Publication Number Publication Date
CN115543687A true CN115543687A (en) 2022-12-30

Family

ID=84729042

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211182354.3A Pending CN115543687A (en) 2022-09-27 2022-09-27 ETCD cluster service data recovery method, device, equipment and storage medium

Country Status (1)

Country Link
CN (1) CN115543687A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117370310A (en) * 2023-10-19 2024-01-09 中电云计算技术有限公司 Distributed file system cross-cluster data increment migration method

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117370310A (en) * 2023-10-19 2024-01-09 中电云计算技术有限公司 Distributed file system cross-cluster data increment migration method
CN117370310B (en) * 2023-10-19 2024-05-28 中电云计算技术有限公司 Distributed file system cross-cluster data increment migration method

Similar Documents

Publication Publication Date Title
US20230015095A1 (en) Database information backup method and recovery method, electronic device, and computer readable storage medium
EP3270298A1 (en) Server and data processing method
CN105320578A (en) Method and apparatus for backing up and recovering APP
CN109165112B (en) Fault recovery method, system and related components of metadata cluster
CN112181720A (en) Virtual data center backup method and device based on cloud management platform
CN110795399A (en) Method, device and system for generating machine ID for application
US11474910B2 (en) Method, device and computer program product to backup data
CN115543687A (en) ETCD cluster service data recovery method, device, equipment and storage medium
CN115517009B (en) Cluster management method, cluster management device, storage medium and electronic equipment
CN112181049B (en) Cluster time synchronization method, device, system, equipment and readable storage medium
CN107193563B (en) Method for managing server stateless firmware version
CN111190878B (en) Method, device, equipment and storage medium for sharing access NAS snapshot
CN109669642B (en) Node joining method, system and device of storage system and readable storage medium
CN108763471B (en) Method and system for deploying HTTP file server in cluster
CN113835625B (en) Data storage method, device, equipment and storage medium based on sub-path
CN111008095A (en) State snapshot generation and recovery method facing edge cloud
CN114328026B (en) Virtual disk backup method, device, equipment and medium
CN113722157B (en) Virtual machine data management method, device, equipment and medium
CN113886352B (en) Metadata recovery method, device, equipment and medium of distributed file system
CN111488117A (en) Method, electronic device, and computer-readable medium for managing metadata
CN113704177B (en) Storage method, system and related components of server firmware upgrade file
CN114995762A (en) Thick backup roll capacity expansion method, device, equipment and storage medium
CN114490189A (en) Cloud platform database backup method and device, electronic equipment and storage medium
CN114817134A (en) Snapshot task monitoring method, device, equipment and medium
CN111385334B (en) Data distribution method, device, equipment and storage medium

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