CN113590380A - Database recovery method and system - Google Patents
Database recovery method and system Download PDFInfo
- Publication number
- CN113590380A CN113590380A CN202110714344.9A CN202110714344A CN113590380A CN 113590380 A CN113590380 A CN 113590380A CN 202110714344 A CN202110714344 A CN 202110714344A CN 113590380 A CN113590380 A CN 113590380A
- Authority
- CN
- China
- Prior art keywords
- database
- slave
- storage device
- master
- writing
- 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
- 238000011084 recovery Methods 0.000 title claims abstract description 70
- 238000000034 method Methods 0.000 title claims abstract description 67
- 230000004044 response Effects 0.000 claims abstract description 27
- 238000005192 partition Methods 0.000 claims description 64
- 230000008569 process Effects 0.000 claims description 27
- 238000010586 diagram Methods 0.000 description 8
- 238000004590 computer program Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 239000007787 solid Substances 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 238000013500 data storage Methods 0.000 description 2
- 230000014509 gene expression Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
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/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
-
- 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
- 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
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)
- Quality & Reliability (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention provides a database recovery method and a system, wherein the method comprises the following steps: acquiring metadata, writing the metadata into a master database of the first master storage device and a slave database of the first slave storage device respectively, and judging whether the writing is successful; in response to the failure of writing to the master database or the slave database, recognizing that a first master storage device where the master database is located or a first slave storage device where the slave database is located is damaged, and recording a failure mark corresponding to the master database or the slave database into a recovery file of a second storage device based on the writing failure result; and in response to the damaged first master storage device or first slave storage device being replaced, reading the failure mark in the recovery file, taking the corresponding database as a destination database and taking the other database as a source database, and recovering the destination database through the source database. The invention improves the convenience of database recovery and ensures the data security.
Description
Technical Field
The invention relates to the technical field of storage, in particular to a database recovery method and a database recovery system.
Background
For a distributed storage cluster, after a new generation of storage engine bluestore is used, in order to improve cluster performance, a database partition is deployed on an SSD (solid state disk), a data partition is deployed on an HDD (hard disk drive), and one OSD process uses two physical media, so that a higher requirement is imposed on reliability of the physical media.
The normal operation of OSD needs database partition and data partition normal can normal operating, owing to the database partition that has a plurality of OSD of deployment on an SSD, when an SSD destroys, can bring the following problem: if one SSD is broken, the plurality of OSD can not work normally; moreover, when the SSD is replaced, the SSD needs to be replaced, and the OSD associated with the SSD needs to be completely formatted and redo the OSD, a considerable amount of data related to the database is reconstructed, which not only affects the front-end service, but also temporarily reduces the redundancy of the cluster.
Disclosure of Invention
In view of the above, an object of the present invention is to provide a database recovery method and system, so as to solve the problem that in the prior art, a storage device in which a database is located is damaged, which causes inconvenience in database recovery.
Based on the above purpose, the present invention provides a database recovery method, which comprises the following steps:
acquiring metadata, writing the metadata into a master database of the first master storage device and a slave database of the first slave storage device respectively, and judging whether the writing is successful;
in response to the failure of writing to the master database or the slave database, recognizing that a first master storage device where the master database is located or a first slave storage device where the slave database is located is damaged, and recording a failure mark corresponding to the master database or the slave database into a recovery file of a second storage device based on the writing failure result;
and in response to the damaged first master storage device or first slave storage device being replaced, reading the failure mark in the recovery file, taking the corresponding database as a destination database and taking the other database as a source database, and recovering the destination database through the source database.
In some embodiments, writing metadata to the master database of the first master storage device and the slave database of the first slave storage device, respectively, comprises:
and storing the master database into a first master storage partition of the first master storage device, storing the slave database into a first slave storage partition of the first slave storage device corresponding to the first master storage partition, and writing the metadata into the master database and the slave database respectively.
In some embodiments, storing the master database in a first master storage partition of a first master storage device, and storing the slave database in a first slave storage partition of a first slave storage device corresponding to the first master storage partition comprises:
dividing a plurality of main storage partitions for a first main storage device and dividing a plurality of auxiliary storage partitions corresponding to the first auxiliary storage device one by one for the first auxiliary storage device;
the master database is stored in a first master storage partition of a first master storage device, and the slave database is stored in a first slave storage partition of a first slave storage device corresponding to the first master storage partition.
In some embodiments, the method further comprises:
and clearing the failure marks corresponding to the destination database in response to the recovery of the destination database.
In some embodiments, obtaining the metadata and writing the metadata to the master database of the first master storage device and the slave database of the first slave storage device, respectively, comprises:
and starting an OSD process, acquiring the metadata, and writing the metadata into the master database of the first master storage device and the slave database of the first slave storage device respectively.
In some embodiments, the method further comprises:
and exiting the OSD process in response to the failure of writing the metadata into the main database and the metadata into the slave database.
In some embodiments, restoring the destination database from the source database comprises:
stopping the OSD process, and calling the encapsulated command to recover the target database through the source database;
in response to the completion of the recovery, the OSD process is restarted.
In some embodiments, the method further comprises:
and acquiring data corresponding to the metadata and storing the data into the second storage device.
In some embodiments, recording the corresponding failure flag of the master database or the slave database to the recovery file of the second storage device based on the result of the write failure comprises:
and recording a failure mark corresponding to the master database or the slave database into a recovery file under a data directory corresponding to the data of the second storage device based on the writing failure result.
In another aspect of the present invention, there is also provided a database recovery system, including:
the judging module is configured to acquire the metadata, write the metadata into the master database of the first master storage device and the slave database of the first slave storage device respectively, and judge whether the writing is successful;
the failure mark recording module is configured to respond to the writing failure of the master database or the slave database, determine that a first master storage device where the master database is located or a first slave storage device where the slave database is located is damaged, and record a failure mark corresponding to the master database or the slave database into a recovery file of a second storage device based on the writing failure result; and
and the database recovery module is configured to respond to the replacement of the damaged first master storage device or the first slave storage device, read the failure mark in the recovery file, take the corresponding database as a target database and take the other database as a source database, and recover the target database through the source database.
In yet another aspect of the present invention, there is also provided a computer readable storage medium storing computer program instructions which, when executed, implement any one of the methods described above.
In yet another aspect of the present invention, a computer device is provided, which includes a memory and a processor, the memory storing a computer program, the computer program executing any one of the above methods when executed by the processor.
The invention has at least the following beneficial technical effects:
the invention sets the master database and the slave database, and the master database and the slave database belong to different storage devices, when one of the storage devices is damaged, the database of the storage device which normally works can be used as backup, so that the database can be quickly restored after disk replacement; by recording the failure marks in the other storage device, the database which fails to be written can be known by reading the failure marks after the disk is changed, and the database which fails to be written is used as a target database and the database which succeeds to be written is used as a source database, so that the target database is recovered through the source database; even if the slave database is used as the target database, the master database still needs to be recovered for the slave database, so that the master database cannot be written but cannot be recovered, and convenience in database recovery and data security are better guaranteed.
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, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other embodiments can be obtained by using the drawings without creative efforts.
FIG. 1 is a diagram illustrating a database recovery method according to an embodiment of the present invention;
FIG. 2 is a schematic diagram of a database recovery system provided in accordance with an embodiment of the present invention;
FIG. 3 is a schematic diagram of a computer-readable storage medium for implementing a database recovery method according to an embodiment of the present invention;
fig. 4 is a schematic diagram of a hardware structure of a computer device executing a database recovery method according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the following embodiments of the present invention are described in further detail with reference to the accompanying drawings.
It should be noted that all expressions using "first" and "second" in the embodiments of the present invention are used for distinguishing two non-identical entities with the same name or different parameters, and it is understood that "first" and "second" are only used for convenience of expression and should not be construed as limiting the embodiments of the present invention. Furthermore, the terms "comprises" and "comprising," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements does not include all of the other steps or elements inherent in the list.
In view of the above object, a first aspect of the embodiments of the present invention provides an embodiment of a database recovery method. Fig. 1 is a schematic diagram illustrating an embodiment of a database recovery method provided by the present invention. As shown in fig. 1, the embodiment of the present invention includes the following steps:
step S10, obtaining metadata, writing the metadata into the master database of the first master storage device and the slave database of the first slave storage device respectively, and judging whether the writing is successful;
step S20, in response to the write failure to the master database or the slave database, recognizing that the first master storage device where the master database is located or the first slave storage device where the slave database is located is damaged, and recording the corresponding failure mark of the master database or the slave database into the recovery file of the second storage device based on the write failure result;
and step S30, responding to the replacement of the damaged first main storage device or the first auxiliary storage device, reading the failure mark in the recovery file, taking the corresponding database as a target database and taking the other database as a source database, and recovering the target database through the source database.
The embodiment of the invention sets the master database and the slave database, and divides the master database and the slave database into different storage devices, so that when one of the storage devices is damaged, the database of the normally working storage device is used as a backup, thereby being capable of rapidly recovering the database after disk replacement; by recording the failure marks in the other storage device, the database which fails to be written can be known by reading the failure marks after the disk is changed, and the database which fails to be written is used as a target database and the database which succeeds to be written is used as a source database, so that the target database is recovered through the source database; even if the slave database is used as the target database, the master database still needs to be recovered for the slave database, so that the master database cannot be written but cannot be recovered, and convenience in database recovery and data security are better guaranteed.
In this embodiment, the first master storage device and the first slave storage device may be solid state disks, and the second storage device may be a mechanical hard disk. Metadata (metadata) is data describing data (data) and is data describing objects such as information resources or data; the method mainly describes data attribute information and is used for supporting functions such as indicating data storage positions, historical data, resource searching, file recording and the like.
In another embodiment, in response to the metadata being successfully written to both the master database and the slave database, a message is sent to the client that the writing was successful by calling a callback function.
In some embodiments, writing metadata to the master database of the first master storage device and the slave database of the first slave storage device, respectively, comprises: and storing the master database into a first master storage partition of the first master storage device, storing the slave database into a first slave storage partition of the first slave storage device corresponding to the first master storage partition, and writing the metadata into the master database and the slave database respectively.
In some embodiments, storing the master database in a first master storage partition of a first master storage device, and storing the slave database in a first slave storage partition of a first slave storage device corresponding to the first master storage partition comprises: dividing a plurality of main storage partitions for a first main storage device and dividing a plurality of auxiliary storage partitions corresponding to the first auxiliary storage device one by one for the first auxiliary storage device; the master database is stored in a first master storage partition of a first master storage device, and the slave database is stored in a first slave storage partition of a first slave storage device corresponding to the first master storage partition.
In the above embodiment, the first master storage device may include a plurality of master databases, the plurality of master databases are respectively located on different storage partitions, and correspondingly, the first slave storage device also has one-to-one corresponding storage partitions for respectively storing slave databases corresponding to the master databases; and the position of the storage partition where the slave database is located is the same as that of the storage partition where the corresponding database is located, so that the database is restored more orderly and conveniently.
In some embodiments, the method further comprises: and clearing the failure marks corresponding to the destination database in response to the recovery of the destination database.
In this embodiment, when the failure flag is recorded in the database that fails to be written, the metadata is not written into the database subsequently; only after the database is restored, the failure flag is cleared, and the metadata continues to be written thereto.
In some embodiments, obtaining the metadata and writing the metadata to the master database of the first master storage device and the slave database of the first slave storage device, respectively, comprises: and starting an OSD process, acquiring the metadata, and writing the metadata into the master database of the first master storage device and the slave database of the first slave storage device respectively.
In some embodiments, the method further comprises: and exiting the OSD process in response to the failure of writing the metadata into the main database and the metadata into the slave database.
In some embodiments, restoring the destination database from the source database comprises: stopping the OSD process, and calling the encapsulated command to recover the target database through the source database; in response to the completion of the recovery, the OSD process is restarted.
In the above embodiments, the OSD (Object-based Storage Device) represents an Object Storage Device, and is a new network Storage architecture, which is a Device based on an Object Storage technology. The OSD has certain intelligence, has its own CPU, memory, network and disk system, and its main functions include data storage and secure access for managing data distribution thereon. Each OSD process is responsible for a master database and a corresponding slave database and data (referring to data corresponding to metadata), and when one of the first master storage device or the first slave storage device fails, the OSD associated with the master database and the corresponding slave database can still work normally. In another embodiment, when the OSD process is started, two BlueFS file systems are also created, and the two BlueFS file systems are respectively bound with a first main storage partition where the main database is located and a first slave storage partition where the slave database is located. The BlueFS is a small file system, has simple functions, does not support the covering write operation of files, only supports the additional write, is internally provided with a tree-shaped hierarchical structure of a local file system, and only has the mapping relation from a flat directory to the files. After a disc change, the corresponding two blue FS file systems also need to be restored.
In some embodiments, the method further comprises: and acquiring data corresponding to the metadata and storing the data into the second storage device.
In some embodiments, recording the corresponding failure flag of the master database or the slave database to the recovery file of the second storage device based on the result of the write failure comprises: and recording a failure mark corresponding to the master database or the slave database into a recovery file under a data directory corresponding to the data of the second storage device based on the writing failure result.
In the above embodiment, the OSD directory includes three directories, which are a directory of the master database, a directory of the slave database, and a data directory of the data.
In a second aspect of the embodiments of the present invention, a database recovery system is further provided. Fig. 2 is a schematic diagram of an embodiment of a database recovery system provided by the present invention. As shown in fig. 2, a database recovery system includes: the judging module 10 is configured to acquire metadata, write the metadata into the master database of the first master storage device and the slave database of the first slave storage device respectively, and judge whether the writing is successful; a failure mark recording module 20 configured to identify that a first master storage device in which the master database is located or a first slave storage device in which the slave database is located is damaged in response to a write failure to the master database or the slave database, and record a failure mark corresponding to the master database or the slave database in a recovery file of a second storage device based on a result of the write failure; and a database recovery module 30 configured to, in response to replacement of the damaged first master storage device or the first slave storage device, read the failure flag in the recovery file and take the corresponding database as a destination database and the other database as a source database, and recover the destination database from the source database.
In some embodiments, the determination module 10 includes a metadata writing module configured to store the master database in a first master storage partition of a first master storage device, and store the slave database in a first slave storage partition of the first slave storage device corresponding to the first master storage partition, and write metadata to the master database and the slave database, respectively.
In some embodiments, the metadata writing module includes a storage partition storing module configured to divide a number of master storage partitions for a first master storage device and divide a number of slave storage partitions in one-to-one correspondence with the first slave storage device for the first slave storage device; the master database is stored in a first master storage partition of a first master storage device, and the slave database is stored in a first slave storage partition of a first slave storage device corresponding to the first master storage partition.
In some embodiments, the system further includes a failure flag clearing module configured to clear a corresponding failure flag of the destination database in response to the destination database recovering.
In some embodiments, the determining module 10 further includes an OSD process starting module configured to start the OSD process, obtain the metadata, and write the metadata into the master database of the first master storage device and the slave database of the first slave storage device, respectively.
In some embodiments, the system further comprises an OSD process exit module configured to exit the OSD process in response to a write failure to both write metadata to the master database and to write metadata from the slave database.
In some embodiments, the database recovery module 30 includes an OSD process stopping module configured to stop the OSD process and call the encapsulated command to recover the destination database through the source database; in response to the completion of the recovery, the OSD process is restarted.
In some embodiments, the system further includes a data acquisition module configured to acquire data corresponding to the metadata and store the data in the second storage device.
In some embodiments, the failure flag recording module 20 includes a recovery file module configured to record the failure flag corresponding to the master database or the slave database into a recovery file under a data directory corresponding to the data of the second storage device based on the result of the write failure.
In a third aspect of the embodiment of the present invention, a computer-readable storage medium is further provided, and fig. 3 is a schematic diagram of a computer-readable storage medium implementing a database recovery method according to an embodiment of the present invention. As shown in fig. 3, the computer-readable storage medium 3 stores computer program instructions 31, the computer program instructions 31 when executed by the processor implement the steps of:
acquiring metadata, writing the metadata into a master database of the first master storage device and a slave database of the first slave storage device respectively, and judging whether the writing is successful;
in response to the failure of writing to the master database or the slave database, recognizing that a first master storage device where the master database is located or a first slave storage device where the slave database is located is damaged, and recording a failure mark corresponding to the master database or the slave database into a recovery file of a second storage device based on the writing failure result;
and in response to the damaged first master storage device or first slave storage device being replaced, reading the failure mark in the recovery file, taking the corresponding database as a destination database and taking the other database as a source database, and recovering the destination database through the source database.
In some embodiments, writing metadata to the master database of the first master storage device and the slave database of the first slave storage device, respectively, comprises: and storing the master database into a first master storage partition of the first master storage device, storing the slave database into a first slave storage partition of the first slave storage device corresponding to the first master storage partition, and writing the metadata into the master database and the slave database respectively.
In some embodiments, storing the master database in a first master storage partition of a first master storage device, and storing the slave database in a first slave storage partition of a first slave storage device corresponding to the first master storage partition comprises: dividing a plurality of main storage partitions for a first main storage device and dividing a plurality of auxiliary storage partitions corresponding to the first auxiliary storage device one by one for the first auxiliary storage device; the master database is stored in a first master storage partition of a first master storage device, and the slave database is stored in a first slave storage partition of a first slave storage device corresponding to the first master storage partition.
In some embodiments, the steps further comprise: and clearing the failure marks corresponding to the destination database in response to the recovery of the destination database.
In some embodiments, obtaining the metadata and writing the metadata to the master database of the first master storage device and the slave database of the first slave storage device, respectively, comprises: and starting an OSD process, acquiring the metadata, and writing the metadata into the master database of the first master storage device and the slave database of the first slave storage device respectively.
In some embodiments, the steps further comprise: and exiting the OSD process in response to the failure of writing the metadata into the main database and the metadata into the slave database.
In some embodiments, restoring the destination database from the source database comprises: stopping the OSD process, and calling the encapsulated command to recover the target database through the source database; in response to the completion of the recovery, the OSD process is restarted.
In some embodiments, the steps further comprise: and acquiring data corresponding to the metadata and storing the data into the second storage device.
In some embodiments, recording the corresponding failure flag of the master database or the slave database to the recovery file of the second storage device based on the result of the write failure comprises: and recording a failure mark corresponding to the master database or the slave database into a recovery file under a data directory corresponding to the data of the second storage device based on the writing failure result.
It is to be understood that all embodiments, features and advantages set forth above with respect to the database recovery method according to the present invention apply equally, without conflict therewith, to the database recovery system and the storage medium according to the present invention.
In a fourth aspect of the embodiments of the present invention, there is further provided a computer device, including a memory 402 and a processor 401, where the memory stores a computer program, and the computer program, when executed by the processor, implements the method of any one of the above embodiments.
Fig. 4 is a schematic hardware configuration diagram of an embodiment of a computer device for executing a database recovery method according to the present invention. Taking the computer device shown in fig. 4 as an example, the computer device includes a processor 401 and a memory 402, and may further include: an input device 403 and an output device 404. The processor 401, the memory 402, the input device 403 and the output device 404 may be connected by a bus or other means, and fig. 4 illustrates an example of a connection by a bus. The input device 403 may receive input numeric or character information and generate key signal inputs related to user settings and function control of the database recovery system. The output device 404 may include a display device such as a display screen.
The memory 402, which is a non-volatile computer-readable storage medium, may be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as program instructions/modules corresponding to the database recovery method in the embodiment of the present application. The memory 402 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created by use of a database recovery method, and the like. Further, the memory 402 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, memory 402 may optionally include memory located remotely from processor 401, which may be connected to local modules via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The processor 401 executes various functional applications of the server and data processing by running nonvolatile software programs, instructions, and modules stored in the memory 402, that is, implements the database recovery method of the above-described method embodiment.
Finally, it should be noted that the computer-readable storage medium (e.g., memory) herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of example, and not limitation, nonvolatile memory can include Read Only Memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM), which can act as external cache memory. By way of example and not limitation, RAM is available in a variety of forms such as synchronous RAM (DRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The storage devices of the disclosed aspects are intended to comprise, without being limited to, these and other suitable types of memory.
Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as software or hardware depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosed embodiments of the present invention.
The foregoing is an exemplary embodiment of the present disclosure, but it should be noted that various changes and modifications could be made herein without departing from the scope of the present disclosure as defined by the appended claims. The functions, steps and/or actions of the method claims in accordance with the disclosed embodiments described herein need not be performed in any particular order. Furthermore, although elements of the disclosed embodiments of the invention may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.
It should be understood that, as used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly supports the exception. It should also be understood that "and/or" as used herein is meant to include any and all possible combinations of one or more of the associated listed items. The numbers of the embodiments disclosed in the embodiments of the present invention are merely for description, and do not represent the merits of the embodiments.
Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, of embodiments of the invention is limited to these examples; within the idea of an embodiment of the invention, also technical features in the above embodiment or in different embodiments may be combined and there are many other variations of the different aspects of the embodiments of the invention as described above, which are not provided in detail for the sake of brevity. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of the embodiments of the present invention are intended to be included within the scope of the embodiments of the present invention.
Claims (10)
1. A database recovery method, comprising the steps of:
acquiring metadata, writing the metadata into a master database of a first master storage device and a slave database of a first slave storage device respectively, and judging whether the writing is successful;
in response to the failure of writing to the master database or the slave database, recognizing that a first master storage device in which the master database is located or a first slave storage device in which the slave database is located is damaged, and recording a failure mark corresponding to the master database or the slave database into a recovery file of a second storage device based on the result of the failure of writing;
and in response to the damaged first master storage device or first slave storage device being replaced, reading the failure mark in the recovery file, taking the corresponding database as a destination database and taking the other database as a source database, and recovering the destination database through the source database.
2. The method of claim 1, wherein writing the metadata to the master database of the first master storage device and the slave database of the first slave storage device, respectively, comprises:
and storing the master database into a first master storage partition of the first master storage device, storing the slave database into a first slave storage partition of the first slave storage device corresponding to the first master storage partition, and writing the metadata into the master database and the slave database respectively.
3. The method of claim 2, wherein storing the master database in a first master storage partition of the first master storage device, and storing the slave database in a first slave storage partition of the first slave storage device corresponding to the first master storage partition comprises:
dividing a plurality of main storage partitions for the first main storage device and dividing a plurality of slave storage partitions corresponding to the first slave storage device one by one for the first slave storage device;
the master database is stored in a first master storage partition of the first master storage device, and the slave database is stored in a first slave storage partition of the first slave storage device corresponding to the first master storage partition.
4. The method of claim 1, further comprising:
and responding to the recovery of the target database, and clearing the failure mark corresponding to the target database.
5. The method of claim 1, wherein obtaining metadata and writing the metadata to the master database of the first master storage device and the slave database of the first slave storage device, respectively, comprises:
and starting an OSD process, acquiring metadata, and writing the metadata into a master database of the first master storage device and a slave database of the first slave storage device respectively.
6. The method of claim 5, further comprising:
and exiting the OSD process in response to the failure of writing the metadata into the main database and the slave database.
7. The method of claim 5, wherein restoring the destination database via the source database comprises:
stopping the OSD process, and calling a packaged command to recover the target database through the source database;
in response to completion of the recovery, restarting the OSD process.
8. The method of claim 1, further comprising:
and acquiring data corresponding to the metadata, and storing the data into the second storage device.
9. The method of claim 8, wherein recording the corresponding failure flag of the master database or the slave database into the recovery file of the second storage device based on the result of the write failure comprises:
and recording a failure mark corresponding to the master database or the slave database into a recovery file under a data directory corresponding to the data of the second storage device based on the writing failure result.
10. A database recovery system, comprising:
the judging module is configured to acquire metadata, write the metadata into a master database of the first master storage device and a slave database of the first slave storage device respectively, and judge whether the writing is successful;
the failure mark recording module is configured to identify that a first master storage device where the master database is located or a first slave storage device where the slave database is located is damaged in response to the writing failure of the master database or the slave database, and record a failure mark corresponding to the master database or the slave database into a recovery file of a second storage device based on the writing failure result; and
and the database recovery module is configured to respond to the replacement of the damaged first master storage device or first slave storage device, read the failure flag in the recovery file, take the corresponding database as a destination database and take the other database as a source database, and recover the destination database through the source database.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110714344.9A CN113590380A (en) | 2021-06-25 | 2021-06-25 | Database recovery method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110714344.9A CN113590380A (en) | 2021-06-25 | 2021-06-25 | Database recovery method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113590380A true CN113590380A (en) | 2021-11-02 |
Family
ID=78244662
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110714344.9A Pending CN113590380A (en) | 2021-06-25 | 2021-06-25 | Database recovery method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113590380A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114722029A (en) * | 2022-04-18 | 2022-07-08 | 苏州浪潮智能科技有限公司 | Method, system, device and storage medium for repairing monitor database |
-
2021
- 2021-06-25 CN CN202110714344.9A patent/CN113590380A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114722029A (en) * | 2022-04-18 | 2022-07-08 | 苏州浪潮智能科技有限公司 | Method, system, device and storage medium for repairing monitor database |
| CN114722029B (en) * | 2022-04-18 | 2024-01-09 | 苏州浪潮智能科技有限公司 | Method, system, equipment and storage medium for repairing monitor database |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10795788B2 (en) | Remote data replication method and system | |
| US8782005B2 (en) | Pruning previously-allocated free blocks from a synthetic backup | |
| CN106776130B (en) | Log recovery method, storage device and storage node | |
| JP6404907B2 (en) | Efficient read replica | |
| US10126946B1 (en) | Data protection object store | |
| US9996421B2 (en) | Data storage method, data storage apparatus, and storage device | |
| JP2019135637A (en) | Information processing method, information processing device, server, and computer-readable recording medium | |
| US20110010496A1 (en) | Method for management of data objects | |
| EP3786802B1 (en) | Method and device for failover in hbase system | |
| CN108255638B (en) | Snapshot rollback method and device | |
| CN109284066B (en) | Data processing method, device, equipment and system | |
| CN106528338B (en) | Remote data copying method, storage device and storage system | |
| CN111506253A (en) | Distributed storage system and storage method thereof | |
| RU2643642C2 (en) | Use of cache memory and another type of memory in distributed memory system | |
| CN114003439A (en) | Data backup method, device, equipment and storage medium | |
| CN106502830B (en) | A kind of method for restoring system backup based on Btrfs file system | |
| CN116048874A (en) | Data backup method and system based on cloud environment | |
| CN113590380A (en) | Database recovery method and system | |
| CN110018986B (en) | Abnormal snapshot identification method and device | |
| CN113687797B (en) | Disk management method, system, storage medium and equipment | |
| JP6376626B2 (en) | Data storage method, data storage device, and storage device | |
| CN108271420B (en) | Method for managing files, file system and server system | |
| CN113886352A (en) | Metadata recovery method, device, equipment and medium for distributed file system | |
| CN109241011B (en) | Virtual machine file processing method and device | |
| CN113342751B (en) | Metadata processing method, device, equipment and readable 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 |