Disclosure of Invention
The application aims to at least solve one of the technical defects, and the technical scheme provided by the embodiment of the application is as follows:
In a first aspect, an embodiment of the present application provides a database version rollback method, including:
receiving a version rollback request for a target database; the version rollback request comprises a version identifier of a target rollback version of the target database;
determining a first creation time of the target rollback version based on the version identification, and determining at least one reference backup version associated with the first creation time from at least one saved initial backup version for the target database; each initial backup version is obtained by backing up the target database every preset time period;
determining a target backup version from at least one reference backup version based on the first creation time and the second creation time of each reference backup version;
And modifying the target backup version to obtain a target rollback version of the target database.
In an alternative embodiment of the application, the initial backup version is generated by:
if an instruction for generating an initial backup version is received, and any initial backup version does not exist at the current moment, acquiring the data stored at the current moment of the target database, copying the data stored at the current moment, and generating a corresponding target access link; the target access link is used for accessing the stored data at the current moment; taking a target database version corresponding to the target access link as an initial backup version;
If an instruction for generating the initial backup version is received, and at least one initial backup version exists at the current moment, copying key value pairs generated between the current moment and the creation moment of the last initial backup version, and generating the initial backup version at the current moment based on the key value pairs and the last initial backup version.
In an alternative embodiment of the present application, if at least one initial backup version is created after the first creation time;
determining a target backup version from at least one reference backup version based on the first creation time and the second creation time of each reference backup version, specifically including:
Taking a reference backup version which is positioned after the first creation time and corresponds to the second creation time closest to the first creation time as a target backup version;
modifying the target backup version to obtain a target rollback version of the target database, which specifically comprises:
And deleting the data which does not belong to the target rollback version in the target backup version to obtain the target rollback version.
In an alternative embodiment of the present application, deleting data in the target backup version that does not belong to the target rollback version specifically includes:
acquiring a generation time stamp of each key value pair in the target backup version;
The key value pair whose generation timestamp is between the first creation time and the second creation time is deleted.
In an alternative embodiment of the present application, if the second creation time of each of the initial backup versions is before the first creation time;
determining a target backup version from at least one reference backup version based on the first creation time and the second creation time of each reference backup version, specifically including:
Taking a reference backup version corresponding to a second creation time closest to the first creation time as a target backup version;
modifying the target backup version to obtain a target rollback version of the target database, which specifically comprises:
acquiring a modification record aiming at a target database between a first creation time and a second creation time;
And replaying the modified record to the target backup version to obtain the target rollback version.
In an alternative embodiment of the application, the modification record is obtained by:
each time a modification instruction aiming at a target database is received, acquiring a timestamp corresponding to the modification instruction according to the current moment;
Generating a corresponding key value pair based on the modification instruction, and storing the key value pair and a corresponding timestamp into a target database;
and generating a corresponding modification record based on the modification instruction, and storing the modification record.
In an alternative embodiment of the present application, the method further specifically includes:
When any initial backup version is generated, the modification record before the creation time of any initial backup version is deleted.
In a second aspect, an embodiment of the present application provides a database version rollback apparatus, including:
The request receiving module is used for receiving a version rollback request aiming at the target database; the version rollback request comprises a version identifier of a target rollback version of the target database;
The first backup selection module is used for determining a first creation time of the target rollback version based on the version identification, and determining at least one reference backup version associated with the first creation time from at least one saved initial backup version aiming at the target database; each initial backup version is obtained by backing up the target database every preset time period;
The second backup selection module is used for determining a target backup version from at least one reference backup version based on the first creation time and the second creation time of each reference backup version;
and the version rollback module is used for modifying the target backup version to obtain the target rollback version of the target database.
In an optional embodiment of the present application, the apparatus further includes an initial backup version generation module, specifically configured to:
If an instruction for generating a first backup version is received and any initial backup version does not exist at the current moment, acquiring the data stored at the current moment of the target database, copying the data stored at the current moment and generating a corresponding target access link; the target access link is used for accessing the stored data at the current moment; taking a target database version corresponding to the target access link as an initial backup version;
If an instruction for generating the first backup version is received, and at least one initial backup version exists at the current moment, copying key value pairs generated between the current moment and the creation moment of the last initial backup version, and generating the initial backup version at the current moment based on the key value pairs and the last initial backup version.
In an alternative embodiment of the present application, the second backup selection module is specifically configured to:
Taking a reference backup version which is positioned after the first creation time and corresponds to the second creation time closest to the first creation time as a target backup version;
modifying the target backup version to obtain a target rollback version of the target database, which specifically comprises:
And deleting the data which does not belong to the target rollback version in the target backup version to obtain the target rollback version.
In an alternative embodiment of the present application, the second backup selection module is further configured to:
acquiring a generation time stamp of each key value pair in the target backup version;
The key value pair whose generation timestamp is between the first creation time and the second creation time is deleted.
In an alternative embodiment of the present application, the second backup selection module may further be configured to:
Taking a reference backup version corresponding to a second creation time closest to the first creation time as a target backup version;
modifying the target backup version to obtain a target rollback version of the target database, which specifically comprises:
acquiring a modification record aiming at a target database between a first creation time and a second creation time;
And replaying the modified record to the target backup version to obtain the target rollback version.
In an alternative embodiment of the application, the apparatus further comprises a modification record storage module, specifically for:
each time a modification instruction aiming at a target database is received, acquiring a timestamp corresponding to the modification instruction according to the current moment;
Generating a corresponding key value pair based on the modification instruction, and storing the key value pair and a corresponding timestamp into a target database;
and generating a corresponding modification record based on the modification instruction, and storing the modification record.
In an alternative embodiment of the present application, the apparatus further includes a modification record deletion module, specifically configured to:
When any initial backup version is generated, the modification record before the creation time of any initial backup version is deleted.
In a third aspect, an embodiment of the present application provides an electronic device including a memory, a processor, and a computer program stored on the memory;
the processor executes a computer program to implement the method provided in the first aspect embodiment or any alternative embodiment of the first aspect.
In a fourth aspect, embodiments of the present application provide a computer readable storage medium having a computer program stored thereon, which when executed by a processor implements the method provided in the embodiment of the first aspect or any of the alternative embodiments of the first aspect.
The technical scheme provided by the embodiment of the application has the beneficial effects that:
The backup is carried out on the target database at each preset time interval, so that when the target database needs to be backed up, the backup database version can be directly obtained and is directly modified on the backup database version, the data is not required to be written into a new database cluster again for database construction, and the backing efficiency of the database can be obviously improved.
Detailed Description
Embodiments of the present application are described below with reference to the drawings in the present application. It should be understood that the embodiments described below with reference to the drawings are exemplary descriptions for explaining the technical solutions of the embodiments of the present application, and the technical solutions of the embodiments of the present application are not limited.
As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless expressly stated otherwise, as understood by those skilled in the art. It will be further understood that the terms "comprises" and "comprising," when used in this specification, specify the presence of stated features, information, data, steps, operations, elements, and/or components, but do not preclude the presence or addition of other features, information, data, steps, operations, elements, components, and/or groups thereof, all of which may be included in the present specification. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Further, "connected" or "coupled" as used herein may include wirelessly connected or wirelessly coupled. The term "and/or" as used herein indicates that at least one of the items defined by the term, e.g., "a and/or B" may be implemented as "a", or as "B", or as "a and B".
For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail with reference to the accompanying drawings.
The technical solutions of the embodiments of the present application and technical effects produced by the technical solutions of the present application are described below by describing several exemplary embodiments. It should be noted that the following embodiments may be referred to, or combined with each other, and the description will not be repeated for the same terms, similar features, similar implementation steps, and the like in different embodiments.
Fig. 1 is a flowchart of a method for rollback a database version, where an execution subject of the method may be a terminal (e.g., a computer, a mobile phone, etc.), as shown in fig. 1, and the method may include:
Step S101, receiving a version rollback request for a target database; the version rollback request comprises a version identifier of a target rollback version of the target database.
The target database is a database needing version rollback, and the embodiment of the application can support multiple types of databases (such as TiDB, mysql, oracle and the like). The version identification may be used to characterize the generation time of the database.
Specifically, when version rollback is required to be performed on the target database, the version identifier required to be rolled back can be selected based on actual requirements, and after the version identifier is selected, the terminal can receive and process the version rollback request carrying the version identifier.
Step S102, determining a first creation time of a target rollback version based on the version identification, and determining at least one reference backup version associated with the first creation time from at least one saved initial backup version aiming at a target database; each initial backup version is obtained by backing up the target database every preset time period.
The initial backup version is a historical version of the target database which is backed up. The reference backup version may be a base version of the target rollback version, which may be obtained by modifying the reference backup version.
Specifically, when receiving the version rollback request, the terminal may first confirm the version that needs to be rolled back according to the version identifier, then may find the first creation time of the target rollback version from the history record, and after determining the first creation time, may determine, according to the second creation time of each initial backup version (e.g. obtain a plurality of second creation times that are close to the first creation time), a reference backup version corresponding to the plurality of second creation times.
In the embodiment of the application, the terminal will backup the database regularly, and the technical means adopted in the backup process can be snapshot backup. The snapshot backup principle is that a snapshot is created for each disk of each storage node in the target database, and the creation of the disk snapshot can be completed almost instantaneously, and meanwhile, a corresponding hyperlink is generated, so that the history data at the moment can be accessed through the hyperlink, and therefore, the snapshot can be created for the disks of all the storage nodes in extremely short time, namely, the data of the whole database can be backed up in extremely short time.
It should be noted that, in the embodiment of the present application, the point in time when the database is backed up needs to satisfy that the data in each cluster of the target database has consistency, that is, the data in each cluster is synchronized. For example, the user a initiates a transfer to the user B, and the data of the cluster corresponding to the user a is reduced, and the data of the cluster corresponding to the user B is increased at the same time, so that the data in the clusters have consistency.
Step S103, determining a target backup version from at least one reference backup version based on the first creation time and the second creation time of each reference backup version.
Specifically, since only one of the reference backup versions needs to be modified when the target version rollback is performed, a backup version (i.e., the target backup version) that is the basis of the modification needs to be selected from the reference backup versions selected in step S102. Generally, in the embodiment of the present application, a reference backup version corresponding to a second creation time that is after and closest to a first creation time is taken as a target backup version.
Step S104, the target backup version is modified to obtain a target rollback version of the target database.
Specifically, before the target rollback version is obtained, the target backup version needs to be added to the new cluster first, and specifically, as shown in fig. 2, the target backup version includes a scheduling layer (including management nodes PD1, PD2, and PD3, which are used for managing each node of the database), a computing layer (including computing nodes TiDB1, tiDB, and TiDB3, which are used for executing modification instructions), and a storage layer (including storage nodes TiKV1, tiKV2, and TiKV, which are used for storing data, and the data is stored in volume sets volume1, volume2, and volume 3). When backup is needed, the br client backup (Back up & Restore client backup, data backup client) writes the metadata of the current database into the snapshot backup in an EBS (elastic block storage) backup mode, and meanwhile, each storage node respectively creates a corresponding disk snapshot and writes the corresponding disk snapshot into the snapshot backup, so that an initial backup version snapshot at the current moment is obtained; when the initial backup version is determined to be the target backup version, a new empty cluster is created, then br client restore (Back up & Restore client restore, data recovery client) reads metadata in the initial backup version, and pulls each disk snapshot in the initial backup version to the empty cluster, and then pulls each service to obtain the initial backup version.
According to the scheme provided by the application, the target database is backed up at each preset time interval, so that when the target database needs to be backed up, the backed-up database version can be directly obtained, and the backed-up database version is directly modified, so that the data is not required to be written into a new database cluster again to construct the database, and the backing-up efficiency of the database can be obviously improved.
In an alternative embodiment of the application, the initial backup version is generated by:
if an instruction for generating an initial backup version is received, and any initial backup version does not exist at the current moment, acquiring the data stored at the current moment of the target database, copying the data stored at the current moment, and generating a corresponding target access link; the target access link is used for accessing the stored data at the current moment; taking a target database version corresponding to the target access link as an initial backup version;
If an instruction for generating the initial backup version is received, and at least one initial backup version exists at the current moment, copying key value pairs generated between the current moment and the creation moment of the last initial backup version, and generating the initial backup version at the current moment based on the key value pairs and the last initial backup version.
Wherein the key value pair is used to record a modified record of the stored data in the target database. In the embodiment of the present application, each time the data is modified, the data is recorded through the key value pair, and specifically, refer to table 1.
TABLE 1
As shown in table 1, the first column (timer) in table 1 indicates the time when the modification is performed, the second column (operation) indicates the operation type of the current modification, the third column (Value) is a key Value, and the fourth column is a record of the current modification.
The specific writing flow may refer to fig. 3, as shown in fig. 3, a user initiates an instruction for modifying a certain item of data through a database client, a computing node obtains a current time stamp for initiating the modifying instruction through a management node, then the computing node sends a key in a corresponding key value pair to be written in by the modifying instruction to the management module, the management node finds a storage node in the corresponding key value pair according to the key, returns the storage node to the computing node, and finally the node writes the key value pair corresponding to the modifying instruction into the storage node.
It should be noted that, in the embodiment of the present application, generally, the same key (key) has only one corresponding key value at the same time, but there may be multiple modification records for the key in the disk record of the database, and at this time, the key value corresponding to the key at the current time will be determined according to the modification time of each modification record. For example, the operation of writing the key value V1 is performed on the key K at time T1, and the record < k_t1, V1> is generated in the disk; then, a delete operation is performed on the key K at the time T2, and a record < K_T2, D > is generated in the disk; since the time T2 is after the time T1, the value corresponding to the key K at this time is null.
Specifically, when the initial backup version needs to be generated, the terminal detects whether there is an initial backup version that has been backed up. If the data does not exist, copying and backing up the data in the current target database and generating a target access link, wherein the backup can be performed by creating an EBS disk full snapshot in an exemplary manner; if the data exists, the data in the current target database is not required to be copied any more, only a modification record (namely a key value pair) between the current moment and the generation moment of the last initial backup version is required to be obtained, then the modification record is added into the last initial backup version to obtain the initial backup version of the current moment, and the record of the key value pair can be exemplarily carried out in an EBS disk increment snapshot mode and added into the last initial backup version.
The following briefly describes the "EBS disk full snapshot and disk incremental snapshot": disk full snapshot refers to creating a complete copy of a storage volume. When a snapshot is first taken of an EBS volume, the system captures the state of all data on the volume at that time and stores it in the cloud (cloud has a corresponding target access connection). This snapshot contains the complete data for all the blocks on the volume.
A disk delta snapshot is a block of data that has only been recorded as changed since the last snapshot. The first time a snapshot is created it is actually full, but the subsequent snapshots will only save the changed part. This means that each new incremental snapshot contains only blocks of data that have changed since the last snapshot. The advantages are that: saving memory space and costs because only the changed parts need to be saved.
The skilled use of these two snapshot techniques can help users manage cloud storage resources more efficiently, reduce costs, and ensure data security and recoverability.
In an alternative embodiment of the present application, if at least one initial backup version is created after the first creation time;
determining a target backup version from at least one reference backup version based on the first creation time and the second creation time of each reference backup version, specifically including:
Taking a reference backup version which is positioned after the first creation time and corresponds to the second creation time closest to the first creation time as a target backup version;
modifying the target backup version to obtain a target rollback version of the target database, which specifically comprises:
And deleting the data which does not belong to the target rollback version in the target backup version to obtain the target rollback version.
Specifically, when the terminal detects that the generated initial backup version exists after the first creation time of the target rollback version, the reference backup version corresponding to the second creation time which is after the first creation time and is closest to the first creation time may be directly used as the target backup version. Since the second creation time of the target backup version is after the first creation time of the target rollback version, the number of key value pairs (modification records) existing in the target backup version is greater than the number of key value pairs in the target rollback version, and the number of the key value pairs that are not included in the target rollback version is greater than the number of key value pairs in the target rollback version, so that only the key value pairs whose creation time is between the first creation time and the second creation time need to be deleted (the process may also be referred to as flashback, namely, data flashback), and the deleted version is the target rollback version.
Referring to fig. 4, the overall flow of the database version rollback of the present application is described below, as shown in fig. 4, when version rollback is required, a first creation time (denoted by ts_restore herein) of the restored target database version is designated to PITR, then whether there is an initial backup version that has been backed up after the first creation time is queried, if there is an initial backup version that is the latest after the first creation time is found, after the initial backup version is restored to an empty cluster, a key value pair generated between the first creation time and the second creation time is deleted, and the target rollback version can be obtained; if the initial backup version does not exist, the latest initial backup version before the first creation time is found, after the initial backup version is restored to the empty cluster, the modification record log between the first creation time and the second creation time is replayed, and the target rollback version can be obtained.
In the following description, with reference to the examples, fig. 5 is a diagram illustrating an example of a database version rollback interaction flow provided by an embodiment of the present application, and as shown in fig. 5, a backup recovery client (i.e. BR client in the diagram) of a target database initiates a data recovery (i.e. data is recovered to a target version) request. First, a request for querying whether a disk snapshot set (i.e., an initial backup version) exists after the first creation time is initiated to the remote end S3, and the remote end S3 returns a query result to the BR client. If a disk snapshot set exists after the first creation time, a snapshot set which is located after the second creation time (i.e. ts_snapshot_b) and is closest to the first creation time is found, the snapshot set is restored to an empty cluster, a message of successful restoration is returned when the restoration is completed TiKV, then TiKV pulls the snapshot set to a remote end S3, data is restored to the empty cluster, then data is sorted, namely inconsistent data is deleted to ensure the data consistency of the whole cluster of the database, and finally data (key value pair) generated between the first creation time and the second creation time is deleted, so that successful data flashback (i.e. rollback to a target version) is realized.
If there is no disk snapshot set after the first creation time, a snapshot set with the second creation time (i.e., ts_snapshot_b) before and closest to the first creation time is found, and restored to the empty cluster, and a message of successful restoration is returned after the restoration is completed TiKV, then TiKV pulls the snapshot set to the remote end S3, and restores the data to the empty cluster, and then sorts the data, namely deletes the inconsistent data to ensure the data consistency of the whole cluster of the database, finally obtains and replays the modification record (i.e., MVCC ((Multiversion Concurrency Control, multi-version concurrency control) transaction log) between the first creation time and the second creation time, and realizes successful data flashback (i.e., rolls back to the target version) after the replay is successful.
Turning briefly to the MVCC technique, after data backup, the target database may directly and continuously backup row record data (i.e., modification records) in the storage node TiKV as a transaction log, and the backup log may refer to fig. 6. The MVCC technology has the advantage that the transaction log is replayed during recovery, the backed-up key value pair data can be written into the corresponding storage node, the log is replayed orderly according to the writing sequence, and the records are directly written into the corresponding storage node in an out-of-order/parallel manner. Because the record in the storage layer is searched according to the corresponding time stamp after the record is completely written regardless of the writing sequence of the record, the consistency of the recovered data is not affected. In addition, the problem of mutual exclusion of locks when SQL (database instructions) is executed is avoided during replay, so that the speed of replaying logs can be greatly improved, and the recovery time is shortened.
In an alternative embodiment of the present application, deleting data in the target backup version that does not belong to the target rollback version specifically includes:
acquiring a generation time stamp of each key value pair in the target backup version;
The key value pair whose generation timestamp is between the first creation time and the second creation time is deleted.
Specifically, since the corresponding generation time (i.e., timestamp) is recorded in each key value pair, the purpose of deleting the data which does not belong to the target rollback version in the target backup version can be achieved only by deleting the key value pair with the generation time between the first creation time and the second creation time.
In an alternative embodiment of the present application, if the second creation time of each of the initial backup versions is before the first creation time;
determining a target backup version from at least one reference backup version based on the first creation time and the second creation time of each reference backup version, specifically including:
Taking a reference backup version corresponding to a second creation time closest to the first creation time as a target backup version;
modifying the target backup version to obtain a target rollback version of the target database, which specifically comprises:
acquiring a modification record aiming at a target database between a first creation time and a second creation time;
And replaying the modified record to the target backup version to obtain the target rollback version.
The modification record may be a data log of the database, and the data log may include an add-delete-change record of the data.
Specifically, when the terminal detects that the generated initial backup version does not exist after the first creation time of the target rollback version, the terminal can only modify the initial backup version before the first creation time of the second creation time as the target backup version. At this Time, a reference backup version corresponding to a second creation Time closest to the first creation Time is required to be obtained as a target backup version, all modification records for the target database between the second creation Time and the first creation Time are obtained, and then all modification records In the period can be replayed on the basis of the target backup version through PITR (Point-In-Time Recovery) technology, so that the target rollback version can be obtained.
It should be noted that, since the playback record is essentially a pair of key values rewritten to the database, in actual operation, the efficiency of deleting the pair of key values in the database tends to be higher than writing the pair of key values to the database, and therefore, if the condition allows, it is generally preferable to select the initial backup version having the second creation time after the first creation time as the target backup version.
In an alternative embodiment of the application, the modification record is obtained by:
each time a modification instruction aiming at a target database is received, acquiring a timestamp corresponding to the modification instruction according to the current moment;
Generating a corresponding key value pair based on the modification instruction, and storing the key value pair and a corresponding timestamp into a target database;
and generating a corresponding modification record based on the modification instruction, and storing the modification record.
Specifically, since in the above embodiment, the modification record between the first creation time and the second creation time needs to be replayed to the target backup version to obtain the target backup version, the modification record in this period is stored. Specifically, each time a modification instruction for the target database is received, a timestamp (i.e. an issue time) and a specific modification record (key value pair) when the modification instruction is issued are recorded, and then the record is stored in the target database, and the target database can read the modification records when version rollback or other necessary scenes are required.
In an alternative embodiment of the present application, the method further specifically includes:
When any initial backup version is generated, the modification record before the creation time of any initial backup version is deleted.
Specifically, in the embodiment of the present application, after any initial backup version is generated, if the first creation time of the target rollback version corresponding to a certain version rollback request is received again and is after the second creation time of the initial backup version, the initial backup version may be directly used as the target backup version, so that the modification record before the initial backup version does not need to be replayed any more, and at this time, in order to save the storage space of the target database, the modification record before the initial backup version may be deleted entirely.
Referring to fig. 7, the overall flow of the data backup of the present application is described below, and as shown in fig. 7, when the data needs to be backed up, the storage backup function of the modification record is started at this time, meanwhile, the backup time interval t is set, when the backup time point is reached, a disk snapshot of each storage node is created first, and all the modification records before the creation time point of the disk snapshot are deleted. If a backup stop instruction is received, the data is not backed up later; if the instruction of stopping the backup is not received, the time t passes after the backup is finished, and the steps are repeated again.
In the following description, with reference to the examples, fig. 8 is a diagram illustrating an example of a data backup interaction flow provided by an embodiment of the present application, and as shown in fig. 8, a backup recovery client (i.e. BR client in the diagram) of a target database initiates a data backup request. Firstly, initiating a request for creating a log backup task to a PD (management node), and returning a message for starting log backup to a BR client by the PD; then the BR client initiates setting GC (memory) recovery time (i.e. backup time interval) to the PD, wherein 48 hours are taken as an example, and the PD returns a message of successful setting to the BR client again; a Loop (Loop) operation may then be performed according to the settings: 1. TiKV (storage node) backups the data modification log of the node to a remote S3 for storage when monitoring that the log backup task is started, so as to prevent the modification log from being lost locally; 2. when the interval between the computing cluster consistency points of the target database exceeds 48 hours, the BR client initiates an instruction for creating a disk snapshot backup once to TiKV, tiKV returns a message of successful creation to the BR client, and simultaneously stores the snapshot created at the time on a remote end S3, and S3 returns a message of successful storage to TiKV after the snapshot is stored successfully; and then the BR client initiates a modification record log instruction before the moment of creating the disk snapshot to S3, and S3 returns a successful deleting message to the BR client after deleting.
Fig. 9 is a block diagram of a database version rollback apparatus according to an embodiment of the present application, and as shown in fig. 9, the database version apparatus 900 may include: a request receiving module 901, a first backup selection module 902, a second backup selection module 903, and a version rollback module 904, wherein,
The request receiving module 901 is configured to receive a version rollback request for a target database; the version rollback request comprises a version identifier of a target rollback version of the target database;
The first backup selection module 902 is configured to determine, based on the version identifier, a first creation time of the target rollback version, and determine, from at least one saved initial backup version for the target database, at least one reference backup version associated with the first creation time; each initial backup version is obtained by backing up the target database every preset time period;
The second backup selection module 903 is configured to determine a target backup version from at least one reference backup version based on the first creation time and the second creation time of each reference backup version;
The version rollback module 904 is configured to modify the target backup version to obtain a target rollback version of the target database.
According to the scheme provided by the application, the target database is backed up at each preset time interval, so that when the target database needs to be backed up, the backed-up database version can be directly obtained, and the backed-up database version is directly modified, so that the data is not required to be written into a new database cluster again to construct the database, and the backing-up efficiency of the database can be obviously improved.
In an optional embodiment of the present application, the apparatus further includes an initial backup version generation module, specifically configured to:
If an instruction for generating a first backup version is received and any initial backup version does not exist at the current moment, acquiring the data stored at the current moment of the target database, copying the data stored at the current moment and generating a corresponding target access link; the target access link is used for accessing the stored data at the current moment; taking a target database version corresponding to the target access link as an initial backup version;
If an instruction for generating the first backup version is received, and at least one initial backup version exists at the current moment, copying key value pairs generated between the current moment and the creation moment of the last initial backup version, and generating the initial backup version at the current moment based on the key value pairs and the last initial backup version.
In an alternative embodiment of the present application, the second backup selection module is specifically configured to:
Taking a reference backup version which is positioned after the first creation time and corresponds to the second creation time closest to the first creation time as a target backup version;
modifying the target backup version to obtain a target rollback version of the target database, which specifically comprises:
And deleting the data which does not belong to the target rollback version in the target backup version to obtain the target rollback version.
In an alternative embodiment of the present application, the second backup selection module is further configured to:
acquiring a generation time stamp of each key value pair in the target backup version;
The key value pair whose generation timestamp is between the first creation time and the second creation time is deleted.
In an alternative embodiment of the present application, the second backup selection module may further be configured to:
Taking a reference backup version corresponding to a second creation time closest to the first creation time as a target backup version;
modifying the target backup version to obtain a target rollback version of the target database, which specifically comprises:
acquiring a modification record aiming at a target database between a first creation time and a second creation time;
And replaying the modified record to the target backup version to obtain the target rollback version.
In an alternative embodiment of the application, the apparatus further comprises a modification record storage module, specifically for:
each time a modification instruction aiming at a target database is received, acquiring a timestamp corresponding to the modification instruction according to the current moment;
Generating a corresponding key value pair based on the modification instruction, and storing the key value pair and a corresponding timestamp into a target database;
and generating a corresponding modification record based on the modification instruction, and storing the modification record.
In an alternative embodiment of the present application, the apparatus further includes a modification record deletion module, specifically configured to:
When any initial backup version is generated, the modification record before the creation time of any initial backup version is deleted.
Referring now to fig. 10, there is illustrated a schematic diagram of an electronic device (e.g., a terminal device or server performing the method illustrated in fig. 1) 1000 suitable for use in implementing embodiments of the present application. The electronic device in the embodiment of the present application may include, but is not limited to, a mobile terminal such as a mobile phone, a notebook computer, a digital broadcast receiver, a PDA (personal digital assistant), a PAD (tablet computer), a PMP (portable multimedia player), a car-mounted terminal (e.g., car navigation terminal), a wearable device, etc., and a fixed terminal such as a digital TV, a desktop computer, etc. The electronic device shown in fig. 10 is merely an example, and should not impose any limitation on the functionality and scope of use of embodiments of the present application.
An electronic device includes: the memory is used for storing programs for executing the methods according to the method embodiments; the processor is configured to execute a program stored in the memory. Herein, the processor may be referred to as a processing device 1001, which is described below, and the memory may include at least one of a Read Only Memory (ROM) 1002, a Random Access Memory (RAM) 1003, and a storage device 1008, which are described below, in detail:
as shown in fig. 10, the electronic device 1000 may include a processing means (e.g., a central processing unit, a graphics processor, etc.) 1001 that may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 1002 or a program loaded from a storage means 1008 into a Random Access Memory (RAM) 1003. In the RAM1003, various programs and data necessary for the operation of the electronic apparatus 1000 are also stored. The processing device 1001, the ROM 1002, and the RAM1003 are connected to each other by a bus 1004. An input/output (I/O) interface 1005 is also connected to bus 1004.
In general, the following devices may be connected to the I/O interface 1005: input devices 1006 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, and the like; an output device 1007 including, for example, a Liquid Crystal Display (LCD), speaker, vibrator, etc.; storage 1008 including, for example, magnetic tape, hard disk, etc.; and communication means 1009. The communication means 1009 may allow the electronic device 1000 to communicate wirelessly or by wire with other devices to exchange data. While fig. 10 shows an electronic device having various means, it is to be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead.
In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a non-transitory computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication device 1009, or installed from the storage device 1008, or installed from the ROM 1002. When being executed by the processing means 1001, performs the above-described functions defined in the method of the embodiment of the present application.
The computer readable storage medium of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.
In some embodiments, the clients, servers may communicate using any currently known or future developed network protocol, such as HTTP (HyperText Transfer Protocol ), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the internet (e.g., the internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future developed networks.
The computer readable medium may be contained in the electronic device; or may exist alone without being incorporated into the electronic device.
The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to:
receiving a version rollback request for a target database; the version rollback request comprises a version identifier of a target rollback version of the target database; determining a first creation time of the target rollback version based on the version identification, and determining at least one reference backup version associated with the first creation time from at least one saved initial backup version for the target database; each initial backup version is obtained by backing up the target database every preset time period; determining a target backup version from at least one reference backup version based on the first creation time and the second creation time of each reference backup version; and modifying the target backup version to obtain a target rollback version of the target database.
Computer program code for carrying out operations of the present application may be written in one or more programming languages, including, but not limited to, an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The modules or units involved in the embodiments of the present application may be implemented in software or in hardware. Where the name of the module or unit does not constitute a limitation of the unit itself in some cases, for example, the first constraint acquisition module may also be described as "a module that acquires the first constraint".
The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a Complex Programmable Logic Device (CPLD), and the like.
In the context of the present application, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
It should be understood that, although the steps in the flowcharts of the figures are shown in order as indicated by the arrows, these steps are not necessarily performed in order as indicated by the arrows. The steps are not strictly limited in order and may be performed in other orders, unless explicitly stated herein. Moreover, at least some of the steps in the flowcharts of the figures may include a plurality of sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, the order of their execution not necessarily being sequential, but may be performed in turn or alternately with other steps or at least a portion of the other steps or stages.
The foregoing is only a partial embodiment of the present invention, and it should be noted that it will be apparent to those skilled in the art that modifications and adaptations can be made without departing from the principles of the present invention, and such modifications and adaptations are intended to be comprehended within the scope of the present invention.