Feed: Planet MySQL
;
Author: MyDBOPS
;
In this blog, we will see how to do flashback recovery or rolling back the data in MariaDB, MySQL and Percona.
As we know the saying “All human make mistakes”, following that in Database environment the data can be deleted or updated in the database either by intentionally or by accidentally.
To recover the lost data we have multiple ways.
- The data can be recovered from the latest full backup or incremental backup when data size is huge it could take hours to restore it.
- From backup of Binlogs.
- Data can also be recovered from delayed slaves, this case would be helpful when the mistake is found immediately, within the period of delay.
The above either way can help to recover the lost data, but what really matters is, What is the time taken to rollback or recover the data? and How much downtime was taken to get back to the initial state?
To overcome this disaster mysqlbinlog has a very useful option i.e –flashback that comes along with binary of MariaDB server though it comes with Mariaserver, it works well with Oracle Mysql servers and Percona flavour of MySQL.
What is Flashback?
Restoring back the data to the previous snapshot in a MySQL database or in a table is called Flashback.
Flashback options help us to undo the executed row changes(DML events).
For instance, it can change DELETE events to INSERTs and vice versa, and also it will swap WHERE and SET parts of the UPDATE events.
Prerequisites for using flashback :
- binlog_format = ROW
- binlog_row_image = FULL
Let us simulate a few test cases where flashback comes as a boon for recovering data.
For simulating the test cases I am using employees table and mariadb version 10.2
MariaDB [employees]> select @@version; +---------------------+ | @@version | +---------------------+ | 10.2.23-MariaDB-log | +---------------------+ 1 row in set (0.02 sec)
Table structure :
MariaDB [employees]> show create table employeesG *************************** 1. row *************************** Table: employees Create Table: CREATE TABLE `employees` ( `emp_no` int(11) NOT NULL, `birth_date` date NOT NULL, `first_name` varchar(14) NOT NULL, `last_name` varchar(16) NOT NULL, `gender` enum('M','F') NOT NULL, `hire_date` date NOT NULL, PRIMARY KEY (`emp_no`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 1 row in set (0.00 sec)
Case 1: Rollbacking the Deleted data.
Consider the data is deleted was from employees table where first_name =’Chirstian’ .
MariaDB [employees]> select COUNT(*) from employees where first_name ='Chirstian'; +----------+ | COUNT(*) | +----------+ | 226 | +----------+ 1 row in set (0.07 sec) MariaDB [employees]> delete from employees where first_name ='Chirstian'; Query OK, 226 rows affected (0.15 sec)
To revert the data to the intial state ,we need to decode the binlog and get the start and stop position of the delete event happened to the employees table.
It is necessary to take a proper start and stop positions. Start position should be taken exactly after BEGIN and Stop position is before the final COMMIT.
[root@vm3 vagrant]# mysqlbinlog -v --base64-output=DECODE-ROWS /var/lib/mysql/mysql-bin.000007 > mysql-bin.000007.txt
BEGIN /*!*/; # at 427 # at 501 #190417 17:49:49 server id 1 end_log_pos 501 CRC32 0xc7f1c84b Annotate_rows: #Q> delete from employees where first_name ='Chirstian' #190417 17:49:49 server id 1 end_log_pos 569 CRC32 0x6b1b5c98 Table_map: `employees`.`employees` mapped to number 29 # at 569 #190417 17:49:49 server id 1 end_log_pos 7401 CRC32 0x6795a972 Delete_rows: table id 29 flags: STMT_END_F ### DELETE FROM `employees`.`employees` ### WHERE ### @1=10004 ### @2='1954:05:01' ### @3='Chirstian' ### @4='Koblick' ### @5=1 ### @6='1986:12:01' # at 23733 #190417 17:49:49 server id 1 end_log_pos 23764 CRC32 0xf9ed5c3e Xid = 455 ### DELETE FROM `employees`.`employees` ### WHERE ### @1=498513 ### @2='1964:10:01' ### @3='Chirstian' ### @4='Mahmud' ### @5=1 ### @6='1992:06:03' # at 7401 COMMIT/*!*/; # at 23764 #190417 17:49:49 server id 1 end_log_pos 23811 CRC32 0x60dfac86 Rotate to mysql-bin.000008 pos: 4 DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */;
Once the count is verified the from the taken positions, we can prepare the data file or the .sql file using flashback as below
[root@vm3 vagrant]# mysqlbinlog -v --flashback --start-position=427 --stop-position=7401 /var/lib/mysql/mysql-bin.000007 > insert.sql
Below is the comparison of conversion from Delete to Insert for a single record:
### DELETE FROM `employees`.`employees` ### WHERE ### @1=498513 ### @2='1964:10:01' ### @3='Chirstian' ### @4='Mahmud' ### @5=1 ### @6='1992:06:03' ### INSERT INTO `employees`.`employees` ### SET ### @1=498513 ### @2='1964:10:01' ### @3='Chirstian' ### @4='Mahmud' ### @5=1 ### @6='1992:06:03'
MariaDB [employees]> source insert.sql Query OK, 0 rows affected (0.01 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.01 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec)
And the count is verified after the data load.
MariaDB [employees]> select COUNT(*) from employees where first_name ='Chirstian'; +----------+ | COUNT(*) | +----------+ | 226 | +----------+ 1 row in set (0.06 sec)
Case 2 : Rollbacking the Updated data.
The data was updated based on below conditions
MariaDB [employees]> select COUNT(*) from employees where first_name ='Chirstian' and gender='M'; +----------+ | COUNT(*) | +----------+ | 129 | +----------+ 1 row in set (0.14 sec) MariaDB [employees]> update employees set gender='F' where first_name ='Chirstian' and gender='M'; Query OK, 129 rows affected (0.16 sec) Rows matched: 129 Changed: 129 Warnings: 0 MariaDB [employees]> select COUNT(*) from employees where first_name ='Chirstian' and gender='M'; +----------+ | COUNT(*) | +----------+ | 0 | +----------+ 1 row in set (0.07 sec)
To revert back the updated data, the same steps to be followed as in case 1.
[root@vm3 vagrant]# mysqlbinlog -v --flashback --start-position=427 --stop-position=8380 /var/lib/mysql/mysql-bin.000008 > update.sql
MariaDB [employees]> source update.sql Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.01 sec) Query OK, 0 rows affected (0.00 sec) MariaDB [employees]> select COUNT(*) from employees where first_name ='Chirstian' and gender='M'; +----------+ | COUNT(*) | +----------+ | 129 | +----------+ 1 row in set (0.06 sec)
In the above two cases by using flashback option we were able to change Event Type statements from DELETE to INSERT and Update_Event statements by Swapping the SET part and WHERE part.
There are few Limitations of Flashback
- It Doesn’t support DDL ( DROP/TRUNCATE or other DDL’s)
- It Doesn’t support encrypted binlog
- It Doesn’t support compressed binlog
Key Takeaways:
- To reverse the mishandled operations from binary logs.
- No need to stop the server to carry out this operation.
- When the data is small to revert back, flashback process is very faster than recovering the data from Full Backup.
- Point in time recovery (PITR) becomes easy.
Photo by Jiyeon Park on Unsplash