CN112579363B - MySQL data protection system and backup and recovery method thereof - Google Patents
MySQL data protection system and backup and recovery method thereof Download PDFInfo
- Publication number
- CN112579363B CN112579363B CN202011604865.0A CN202011604865A CN112579363B CN 112579363 B CN112579363 B CN 112579363B CN 202011604865 A CN202011604865 A CN 202011604865A CN 112579363 B CN112579363 B CN 112579363B
- Authority
- CN
- China
- Prior art keywords
- data
- backup
- log
- recovery
- mysql
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/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
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
-
- 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/25—Integrating or interfacing systems involving database management systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- 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/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention relates to a MySQL data protection system and a backup and recovery method thereof, wherein the system comprises a client and a server which are in communication connection with each other, the client is connected with a MySQL database, the server is connected with a storage medium, and the server is used for issuing a backup recovery instruction and data to the client, receiving the data and execution results returned by the client and performing data interaction with the storage medium; the client is used for carrying out data interaction with the MySQL database, monitoring the log change of the MySQL database in real time, capturing the log data, and transmitting the captured log data and the physical data file copied from the MySQL database to the server; the storage medium is used for storing physical data files to be backed up of the MySQL database and log data. Compared with the prior art, the method and the system can safely, reliably and quickly perform hot backup under the conditions that the MySQL server is not closed and the external service of MySQL is not influenced, and can appoint any time point for recovery.
Description
Technical Field
The invention relates to the technical field of data protection, in particular to a MySQL data protection system and a backup and recovery method thereof.
Background
Backup is the last line of defense in data security, and for any scenario where data is lost, backup will at least minimize the loss, although not necessarily recover one hundred percent of the data (depending on the backup period). MySQL is a popular relational database management system for the moment because of its speed, reliability and adaptability.
The simplest backup mode of MySQL is to close the MySQL server, copy and store all files under the data directory, copy the data files to the machine needing to be restored when the data files need to be restored, and restart the MySQL server. However, in an actual production environment, the backup and recovery mode has little effect, and because all machines need to provide services, even the Slave sometimes needs to provide read-only services, the MySQL service backup is unrealistic.
MySQL also provides a hot-standby technology, namely snapshot backup, which refers to backup of a database through a snapshot function supported by a file system. The principle of backup is to put all database files in the same partition, and then perform snapshot work on the partition, which for Linux needs to be implemented by LVM (Logical volume Manager). The LVM uses copy-on-write (copy-on-write) techniques to create snapshots, e.g., a logical copy of an entire volume at a certain instant, similar to the MVCC (Multiple Version Concurrency Control) of the InnoDB storage engine in a database, except that the snapshots of the LVM are at the file system level, the MVCC is at the database level, and only the InnoDB storage engine is supported. The LVM has a snapshot reservation, and if there is a change to the original volume data, the LVM ensures that the affected blocks are copied to the snapshot reservation before any changes are written. In short, all old data consistent at the beginning of the snapshot point is retained in the snapshot area, and the snapshot is also very small for a database with few updates.
For MySQL, to use snapshot backup, it is necessary to put the data files, log files, in a logical volume and then snapshot backup the volume. Because snapshot backup can be performed only locally, if a local disk is damaged, a snapshot is damaged, the snapshot backup is more biased to prevent misoperation, a database can be quickly restored to a time Point when the snapshot is generated, and then a log can be restored to a specified time Point in combination, so that restoration at any time Point cannot be really realized, and the requirement of low RPO (Recovery Point Objective, which means from the aspects of system and application data, to a time Point when Recovery is required to be realized, which can support business operations of various departments and corresponds to the restored data) cannot be met.
Cold backup and snapshot backup are rarely used in a production environment due to the defects, a logical backup tool of MySQL is used at present, the MySQL officer provides a Mysqldump logical backup tool, and the problem of slow single-thread backup exists in practical application.
Disclosure of Invention
The invention aims to overcome the defects of the prior art and provide a MySQL data protection system and a backup and recovery method thereof, so that under the conditions that a MySQL server is not closed and the external service of MySQL is not influenced, hot backup can be safely, reliably and quickly carried out, and recovery at any time point can be appointed.
The purpose of the invention can be realized by the following technical scheme: a MySQL data protection system comprises a client and a server which are in communication connection with each other, wherein the client is connected with a MySQL database, the server is connected with a storage medium, and the server is used for issuing a backup recovery instruction and data to the client, receiving the data and execution results returned by the client and performing data interaction with the storage medium;
the client is used for carrying out data interaction with the MySQL database, monitoring the log change of the MySQL database in real time, capturing the log data, and transmitting the captured log data and the physical data file copied from the MySQL database to the server;
the storage medium is used for storing physical data files to be backed up and log data of the MySQL database.
Further, a MySQL database server is arranged in the MySQL database, and the MySQL database server is used for receiving and analyzing the backup recovery instruction.
Further, the log data is used for storing all operation records for the MySQL database change.
Furthermore, the log data comprises a redo log file and an archived log file, and the redo log file writes data in a cyclic duplication mode.
Further, the physical data file is specifically a disk file of a MySQL instance for storing the table data.
Further, the storage medium is provided with a data reading and writing interface, and the storage medium is used as a logical unit for storing data and is used for managing underlying storage, such as storage units of a disk, an object storage, a cloud storage, a tape and the like.
A backup method of a MySQL data protection system comprises the following steps:
a1, creating and starting a corresponding backup task according to a database instance needing to be protected selected by a user;
a2, initializing a backup task option, then creating a time point, and starting a backup process;
a3, starting a backup auxiliary process and a log monitoring thread in sequence, copying log data from the MySQL database by a client after the start is successful, and storing the log data in a local cache file in sequence;
copying the physical data files at the same time, and backing up the copied physical data files to a storage medium through a server;
a4, judging whether the physical data file is successfully backed up to a storage medium, if so, executing the step A5, otherwise, executing the step A6;
a5, stopping log monitoring and log data copying, wherein the client side backs up locally cached log data to a storage medium through the server side, then judges whether the log data are backed up to the storage medium successfully or not, if the backup is successful, the backup process is ended, otherwise, the step A6 is executed;
and A6, deleting the time point, stopping the backup and ending the backup process.
Further, the step A3 specifically includes the following steps:
a31, starting the backup auxiliary process, if the starting is successful, executing the step A32, otherwise, returning to continue to start the backup auxiliary process;
a32, starting a log monitoring thread, executing the step A33 if the starting is successful, and otherwise, returning to continue to start the log monitoring thread;
and A33, copying log data from the MySQL database by the client, sequentially storing the log data in a local cache, copying a physical data file from the MySQL database, and backing up the copied physical data file to a storage medium through the server.
A recovery method of a MySQL data protection system comprises the following steps:
b1, creating and starting a corresponding recovery task according to a database instance needing to be recovered selected by a user;
b2, initializing a recovery task option, creating a recovery process, obtaining backed-up physical data files and log data from the storage medium in parallel by the client through the server, and executing the step B3 if the backup physical data files and the log data are obtained successfully, or executing the step B5 if the backup physical data files and the log data are not obtained successfully;
b3, starting a recovery auxiliary process, applying the acquired physical data file to the MySQL database, if the application is successful, ending the recovery auxiliary process, and executing the step B4, otherwise executing the step B5;
b4, according to the recovery time point appointed by the user, combining the acquired log data, applying corresponding log data to the MySQL database to recover the data to the appointed time point, if the recovery is successful, executing the step B6, otherwise executing the step B5;
b5, stopping the recovery task, and then executing the step B6;
and B6, clearing resources and finishing the recovery process.
Further, the step B2 specifically includes the following steps:
b21, initializing a recovery task option and creating a recovery process;
b22, creating a multi-path recovery channel according to the configured number of the channels to realize parallel recovery;
and B23, based on the multi-path recovery channel, the client side obtains the backed-up physical data files and the log data from the storage medium in parallel through the server side, and recovers the obtained physical data files and the log data to a data file directory of the local database, if all the physical data files and the log data are obtained successfully, the step B3 is executed, and otherwise, the step B5 is executed.
Compared with the prior art, the MySQL data protection system and the backup and recovery method thereof provided by the invention have the advantages that the client is in communication connection with the server, meanwhile, the client is connected with the MySQL database for data interaction, and the server is connected with the storage medium for data interaction, so that the MySQL server does not need to be closed during data backup, the client can directly copy physical data files, monitor the MySQL log changes and capture log data in real time while not influencing the MySQL database service and pressure, and then transmit the log data to the storage medium through the server, and finally generate time points through configured time intervals, so that the data heat protection is reliably realized, and the backup speed is accelerated;
during the data recovery period, due to the fact that changed physical data and logs are captured and stored in real time, subsequent recovery operation can be achieved at any appointed time point through log analysis and application technology, so that not only can physical files be recovered quickly, but also data before shutdown can be recovered as much as possible, and the problem of high RPO of traditional timing backup is effectively solved.
Drawings
FIG. 1 is a schematic diagram of the system of the present invention;
FIG. 2 is a block diagram of the architecture of the MySQL data protection system in implementation;
FIG. 3 is a diagram illustrating a data backup process according to an embodiment;
FIG. 4 is a diagram illustrating an exemplary data recovery process;
the symbols in the figure illustrate: 1. client side, 2, server side, 3, mySQL database, 4, storage medium.
Detailed Description
The invention is described in detail below with reference to the figures and specific embodiments.
Examples
A MySQL data protection system comprises a client 1 and a server 2 which are in communication connection with each other, wherein the client 1 is connected with a MySQL database 3, the server 2 is connected with a storage medium 4, and the server 2 is used for outputting backup recovery instructions and data to the client 1, receiving the data and execution results returned by the client 1 and performing data interaction with the storage medium 4;
the client 1 is used for performing data interaction with the MySQL database 3, monitoring log changes of the MySQL database 3 in real time, capturing log data, and transmitting the captured log data and a physical data file copied from the MySQL database 3 to the server 2, wherein the log data is used for storing all operation records and change data for changing the MySQL database 3, the log data comprises a redo log file and a filing log file, and the redo log file writes data in a circular duplication mode;
the physical data file is a disk file of a MySQL example for storing the table data;
a MySQL database server is arranged in the MySQL database 3 and used for receiving and analyzing a backup recovery instruction;
the storage medium 4 is used for storing physical data files to be backed up and log data of the MySQL database 3, the storage medium 4 is provided with a data reading and writing interface, and the storage medium is used as a logical unit for storing data and is used for managing underlying storage, such as storage units of a magnetic disk, an object storage, a cloud storage, a magnetic tape and the like.
The system is applied to practice, and the specific data backup process comprises the following steps:
a1, creating and starting a corresponding backup task according to a database instance needing to be protected selected by a user;
a2, initializing a backup task option, then creating a time point, and starting a backup process;
a3, starting a backup auxiliary process and a log monitoring thread in sequence, copying log data from the MySQL database by a client after the start is successful, and storing the log data in a local cache file in sequence;
copying the physical data files at the same time, and backing up the copied physical data files to a storage medium through a server;
specifically, the method comprises the following steps: starting a backup auxiliary process, if the starting is successful, continuing to start a log monitoring thread, otherwise, returning to continue to start the backup auxiliary process;
if the log monitoring thread is started successfully, the client copies log data from the MySQL database and stores the log data in a local cache in sequence, and copies physical data files from the MySQL database and backs up the copied physical data files to a storage medium through the server;
otherwise, returning to continue starting the log monitoring thread;
a4, judging whether the physical data file is successfully backed up to a storage medium, if so, executing the step A5, otherwise, executing the step A6;
a5, stopping log monitoring and log data copying, backing up locally cached log data to a storage medium through a server by a client, then judging whether the log data is successfully backed up to the storage medium, if the log data is successfully backed up, ending the backup process, otherwise, executing the step A6;
and A6, deleting the time point, stopping the backup and ending the backup process.
The specific data recovery process comprises the following steps:
b1, creating and starting a corresponding recovery task according to a database instance needing to be recovered selected by a user;
b2, initializing a recovery task option, creating a recovery process, obtaining the backed-up physical data file and log data from the storage medium in parallel by the client through the server, if the backup physical data file and the log data are obtained successfully, executing the step B3, otherwise, executing the step B5, specifically:
firstly, creating a plurality of recovery channels according to the configured number of the channels to realize parallel recovery;
then based on the multi-path recovery channel, the client side obtains the backed-up physical data files and the log data from the storage medium in parallel through the server side, and recovers the obtained physical data files and the log data to a data file directory of a local database, if all the physical data files and the log data are obtained successfully, the step B3 is executed, otherwise, the step B5 is executed;
b3, starting a recovery auxiliary process, applying the acquired physical data file to the MySQL database, if the application is successful, ending the recovery auxiliary process, and executing the step B4, otherwise executing the step B5;
b4, according to the recovery time point appointed by the user, combining the acquired log data, applying corresponding log data to the MySQL database to recover the data to the appointed time point, if the recovery is successful, executing the step B6, otherwise executing the step B5;
b5, stopping the recovery task, and then executing the step B6;
and B6, clearing resources and finishing the recovery process.
In the present invention, the MySQL data is subjected to hot copy and log capture, and the MySQL data can be subjected to hot backup, so as to simultaneously, safely and reliably meet the requirement scenario that a client has low RPO and is restored at a specified time point and that historical data is restored, as shown in fig. 2, in the present embodiment, a storage medium is used as a logical unit for storing backup data, and is responsible for managing all underlying storage units, such as storage units of a disk, object storage, cloud storage, and a tape, and planning the storage units into logical volumes, and providing a data reading and writing interface, so as to meet the access management requirements of the data.
The server serves as a backup management console, is responsible for tasks interacting with users, and simultaneously manages all resources in a comprehensive mode, wherein the server comprises a storage agent and a client agent, and is responsible for issuing backup recovery instructions and data to the corresponding client agent and receiving data and execution results returned by the client agent. And is also responsible for interacting with the storage medium and for reading and writing data. In the backup stage, the client agent starts a process, the process starting thread monitors the change of the redo in real time and captures the changed data in real time to be cached locally, the process is used for backing up the physical files of the database, and after the physical data files are backed up, the local cached log data are sent to the Server end for backup. In the recovery stage, a client-side agent starts a process, the process starts multiple threads, backup data and logs in a storage medium are acquired in parallel, a database is applied to the data, and the logs are analyzed to finish recovery within a specified time. The database data file is a disk file of a MySQL example, and is used for storing table data, and the backup physical file is mainly derived from the disk file.
The MySQL database server is a core component of the MySQL database and is responsible for receiving external SQL instructions, analyzing and executing the instructions and then returning execution results to finish normal service access.
And the client side agent is used as an agent of the backup software on the client side, is responsible for interacting with the server side, receives the command issued by the server side, performs corresponding processing aiming at the command, and returns the execution result to the server side. The processing here includes interacting with the MySQL database, loading the database, obtaining relevant information, and the like.
Redo/Arch represents a Redo log file and an archive log of the MySQL database and is responsible for storing all operation records and changed data for changing the database, the number and the space size of the Redo files are specified by the database, and the data are written in by adopting a circular duplication mode.
As shown in fig. 3, the process of performing data backup in this embodiment includes:
1. the operator selects a database instance needing to be protected, establishes a backup task, initiates the task and executes the step 2;
2. after the backup task is started, establishing a time point in advance and executing the step 3 after the initialization is completed according to the task option;
3. the backup process starts a mysql glyproc process and executes the step 4:
the mysqlphyproc process is mainly used for copying a physical file, and before copying, a log needs to be copied firstly, so that after starting, the subsequent operation can be performed only by waiting for the completion of the execution of the step 4;
in the process execution process, log monitoring and copying are also carried out all the time;
and 4, starting a log monitoring thread by the mysqlphyproc process, and executing the step 6:
after the log monitoring thread is started, the log starts to be copied, meanwhile, the mysqlphyproc process is informed to start to copy the physical file, and the step 5 is executed;
recording Redo logs in a circulating duplication mode, monitoring changes, copying from time to time and storing in sequence;
5. backing up a physical file in a backup process, sending an agent client data sending interface, backing up data in a remote storage medium, executing a step 8 after backup failure, finishing backup, and otherwise, executing a step 7;
6. copying a Redo log by the log monitoring thread, and sequentially storing the Redo log in a local cache file;
the mysqlphyproc process informs the log monitoring thread, stops the monitoring and copying of the Redo log, backups the local cache Redo log and the Binlog filing log by the backup process, and ends the backup;
8. and deleting the time point by the backup process, and finishing the backup.
The process of performing data recovery in this embodiment is shown in fig. 4, and includes:
1. the operator selects the database instance needing to be recovered, establishes a recovery task, initiates the task and executes the step 2;
2. after the recovery task is started, after initialization is completed according to the task option, a recovery process is created, and step 3 is executed;
3. and (4) starting a data acquisition thread by the recovery process, and executing the step 4:
restoring the backup data and the log to a data file directory of the local database, and executing the step 4 if all the backup data and the log are successfully acquired, or executing the step 7 if not;
creating a multi-path recovery channel according to the configured number of the channels, and recovering in parallel;
4. and (5) the recovery process starts a mysqlphyproc process, and the step 5 is executed:
the mysqlphyproc process is mainly used for applying physical data, so that the data consistency is ensured, before application, subsequent operation can be performed only after the step 4 is executed, the application successfully executes the step 5, and otherwise, the step 7 is executed;
recovering process blocking waiting during process execution;
5, the mysqlphyproc process exits, and the step 6 is executed;
6. the recovery process applies corresponding logs to the database according to the recovery time point specified by the client, recovers the data to the specified time point, and successfully executes the step 8 if the recovery is successful, otherwise executes the step 7;
7. the recovery process stops recovering the task and executes the step 8;
8. and the recovery process cleans the resources and the recovery is finished.
In this embodiment, the MySQL glyproc process is used as an auxiliary process in a backup process and a recovery process, and is used for copying the physical data file from the MySQL database during data backup, and is used for applying the acquired physical data file to the MySQL database during data recovery, so that data consistency is ensured, and the MySQL database can read and apply the recovery data. In practical application, in order to ensure the reliability of data backup and recovery, a client agent and a server must be in the same network and have mutual access rights; the operator must have the corresponding storage medium usage rights; the operator must configure the correct user name and password information for the instance to be backed up; the operator must confirm that the recovery path has the corresponding operation authority of the database user; the operator must configure the correct database profile path for the instance that needs to be self-started after recovery.
In summary, by adopting the technical scheme provided by the invention, the backup speed can be greatly increased by directly copying the physical file during data backup, and the method is safe and reliable; the affairs executed in the backup period are not interrupted, and the backup InNODB data does not influence the service; furthermore, the performance pressure of the database is not increased during backup.
When the data is recovered, the physical file is recovered firstly, so that the recovery speed can be increased, and the downtime of the MySQL service is reduced; and then, by recovering the MySQL log, any time point can be specified for recovery, so that the low RPO requirement scene of the user is met.
Claims (6)
1. A data backup and recovery method of a MySQL data protection system is applied to the MySQL data protection system and is characterized in that the MySQL data protection system comprises a client (1) and a server (2) which are in communication connection with each other, the client (1) is connected with a MySQL database (3), the server (2) is connected with a storage medium (4), and the server (2) is used for issuing a backup recovery instruction and data to the client (1), receiving the data and an execution result returned by the client (1) and performing data interaction with the storage medium (4);
the client (1) is used for performing data interaction with the MySQL database (3), monitoring log changes of the MySQL database (3) in real time, capturing log data, and transmitting the captured log data and a physical data file copied from the MySQL database (3) to the server (2);
the storage medium (4) is used for storing physical data files to be backed up and log data of the MySQL database (3);
the data backup method comprises the following steps:
a1, creating and starting a corresponding backup task according to a database instance needing to be protected selected by a user;
a2, initializing a backup task option, then creating a time point, and starting a backup process;
a3, starting a backup auxiliary process and a log monitoring thread in sequence, copying log data from the MySQL database by a client after the start is successful, and storing the log data in a local cache file in sequence;
copying the physical data files at the same time, and backing up the copied physical data files to a storage medium through a server;
a4, judging whether the physical data file is successfully backed up to a storage medium, if so, executing the step A5, otherwise, executing the step A6;
a5, stopping log monitoring and log data copying, wherein the client side backs up locally cached log data to a storage medium through the server side, then judges whether the log data are backed up to the storage medium successfully or not, if the backup is successful, the backup process is ended, otherwise, the step A6 is executed;
a6, deleting the time point, stopping the backup and ending the backup process;
the step A3 specifically includes the following steps:
a31, starting the backup auxiliary process, if the starting is successful, executing the step A32, otherwise, returning to continue to start the backup auxiliary process;
a32, starting a log monitoring thread, executing the step A33 if the starting is successful, and otherwise, returning to continue to start the log monitoring thread;
a33, the client copies log data from the MySQL database and stores the log data in a local cache in sequence, and copies physical data files from the MySQL database and backs up the copied physical data files to a storage medium through the server;
the data recovery method comprises the following steps:
b1, creating and starting a corresponding recovery task according to a database instance needing to be recovered selected by a user;
b2, initializing a recovery task option, creating a recovery process, obtaining backed-up physical data files and log data from the storage medium in parallel by the client through the server, and executing the step B3 if the backup physical data files and the log data are obtained successfully, or executing the step B5 if the backup physical data files and the log data are not obtained successfully;
b3, starting a recovery auxiliary process, applying the acquired physical data file to the MySQL database, if the application is successful, ending the recovery auxiliary process, and executing the step B4, otherwise executing the step B5;
b4, according to the recovery time point appointed by the user, combining the acquired log data, applying corresponding log data to the MySQL database to recover the data to the appointed time point, if the recovery is successful, executing the step B6, otherwise executing the step B5;
b5, stopping the recovery task, and then executing the step B6;
b6, clearing resources and ending the recovery process;
the step B2 specifically includes the steps of:
b21, initializing a recovery task option and creating a recovery process;
b22, creating a multi-channel recovery channel according to the configured channel number to realize parallel recovery;
and B23, based on the multi-path recovery channel, the client side obtains the backed-up physical data files and the log data from the storage medium in parallel through the server side, and recovers the obtained physical data files and the log data to a data file directory of the local database, if all the physical data files and the log data are obtained successfully, the step B3 is executed, and otherwise, the step B5 is executed.
2. The MySQL data protection system data backup and recovery method according to claim 1, wherein a MySQL database server is arranged in the MySQL database (3) and used for receiving and analyzing backup and recovery instructions.
3. The MySQL data protection system data backup and recovery method according to claim 1, wherein the log data is used to store all operation records for MySQL database (3) changes.
4. The MySQL data protection system data backup and recovery method according to claim 3, wherein the log data includes a redo log file and an archive log file, and the redo log file writes data in a circular duplication manner.
5. The MySQL data protection system data backup and recovery method according to claim 1, wherein the physical data file is a disk file of a MySQL instance used for storing table data.
6. The MySQL data protection system data backup and recovery method according to claim 1, wherein the storage medium (4) is provided with a data reading and writing interface.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011604865.0A CN112579363B (en) | 2020-12-30 | 2020-12-30 | MySQL data protection system and backup and recovery method thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011604865.0A CN112579363B (en) | 2020-12-30 | 2020-12-30 | MySQL data protection system and backup and recovery method thereof |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112579363A CN112579363A (en) | 2021-03-30 |
| CN112579363B true CN112579363B (en) | 2023-02-03 |
Family
ID=75144233
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011604865.0A Active CN112579363B (en) | 2020-12-30 | 2020-12-30 | MySQL data protection system and backup and recovery method thereof |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112579363B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113297008B (en) * | 2021-05-19 | 2023-12-12 | 阿里巴巴新加坡控股有限公司 | Data processing method and system |
| CN113434339B (en) * | 2021-06-29 | 2023-07-18 | 方心科技股份有限公司 | Data encryption transmission system and method based on combined cyclic backup for intelligent computing center |
| CN114116322B (en) * | 2022-01-27 | 2022-05-24 | 深圳市科力锐科技有限公司 | Data recovery method, device, equipment and storage medium |
| CN114637633A (en) * | 2022-04-01 | 2022-06-17 | 南京壹进制信息科技有限公司 | Backup recovery method based on domestic dream database |
| CN115202929B (en) * | 2022-06-22 | 2023-04-07 | 广州鼎甲计算机科技有限公司 | Database cluster backup system |
| CN116055325B (en) * | 2022-12-22 | 2024-04-09 | 天翼阅读文化传播有限公司 | Data information management system for interconnection communication |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105045681A (en) * | 2015-07-10 | 2015-11-11 | 上海爱数软件有限公司 | Oracle multichannel parallel backup and recovery method |
| CN106844363A (en) * | 2015-12-03 | 2017-06-13 | 阿里巴巴集团控股有限公司 | Carry out that physical thermal is standby and method and apparatus of data recovery for database |
| CN107256182A (en) * | 2017-05-03 | 2017-10-17 | 上海上讯信息技术股份有限公司 | A kind of method and apparatus of database restoration |
| CN109656911A (en) * | 2018-12-11 | 2019-04-19 | 江苏瑞中数据股份有限公司 | Distributed variable-frequencypump Database Systems and its data processing method |
| CN110704242A (en) * | 2019-09-24 | 2020-01-17 | 上海爱数信息技术股份有限公司 | Continuous data protection system and method based on Oracle log capture |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107169108B (en) * | 2017-05-19 | 2020-10-20 | 苏州浪潮智能科技有限公司 | Method and device for realizing MySQL data quick recovery based on Oracle |
| CN107797887B (en) * | 2017-10-26 | 2021-03-23 | 医渡云（北京）技术有限公司 | Data backup and recovery method and device, storage medium and electronic equipment |
-
2020
- 2020-12-30 CN CN202011604865.0A patent/CN112579363B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105045681A (en) * | 2015-07-10 | 2015-11-11 | 上海爱数软件有限公司 | Oracle multichannel parallel backup and recovery method |
| CN106844363A (en) * | 2015-12-03 | 2017-06-13 | 阿里巴巴集团控股有限公司 | Carry out that physical thermal is standby and method and apparatus of data recovery for database |
| CN107256182A (en) * | 2017-05-03 | 2017-10-17 | 上海上讯信息技术股份有限公司 | A kind of method and apparatus of database restoration |
| CN109656911A (en) * | 2018-12-11 | 2019-04-19 | 江苏瑞中数据股份有限公司 | Distributed variable-frequencypump Database Systems and its data processing method |
| CN110704242A (en) * | 2019-09-24 | 2020-01-17 | 上海爱数信息技术股份有限公司 | Continuous data protection system and method based on Oracle log capture |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112579363A (en) | 2021-03-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112579363B (en) | MySQL data protection system and backup and recovery method thereof | |
| EP1455275B1 (en) | Data restoring apparatus using journal data and identification information | |
| US9940067B2 (en) | Performing a data write on a storage device | |
| CN110704242B (en) | Continuous data protection system and method | |
| US8285679B2 (en) | Creating a buffer point-in-time copy relationship for a point-in-time copy function executed to create a point-in-time copy relationship | |
| US7698320B2 (en) | Database management system to reduce capacity of storage volume | |
| US8261035B1 (en) | System and method for online data migration | |
| EP1999586B1 (en) | System, method and computer program product for storing multiple types of information | |
| US7185048B2 (en) | Backup processing method | |
| WO2021184679A1 (en) | Continuous data protection system and method | |
| WO2011083507A1 (en) | Replication system and its control method | |
| US20070294568A1 (en) | Storage system and method of managing data using the same | |
| WO2010089003A1 (en) | Method and system for multi-server application synchronization without stopping i/o | |
| CN110825562B (en) | Data backup method, device, system and storage medium | |
| US8832027B1 (en) | Change tracking between snapshots of a source storage | |
| US20230401128A1 (en) | Backup recovery system and method for oracle database | |
| CN115729749A (en) | Data backup method and system | |
| US10671567B2 (en) | System and method for optimized lock detection | |
| US12007851B2 (en) | Differential checksum validation | |
| US11782799B2 (en) | Using bitmaps to validate data | |
| US20230205641A1 (en) | Disaster recovery drills based on checksum validations |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |