Data protection is vital for DB admins, especially when it involves data that is accessed and updated 24 hours a day. Clustering and replication are techniques that provide protection against failures, but what if a user or DBA issues a detrimental command against one of the databases? A user might erroneously delete or update the contents of one or more tables, drop database objects that are still needed during an update to an application, or run a large batch update that fails midway. How do we recover lost data?
In a previous post, we showed you how to do a full restore from backup. Great, now you’ve restored up to the last incremental backup that was done at 6am this morning. But how about the rest of the data?
This is where you’d do a point-in-time recovery, to recover your data prior to the transaction that caused the problem. The procedure involves restoring the database from backups prior to the target time for recovery, then uses a redo log to roll the database forward to the target time. This procedure is a noteworthy practice that every DBA or sysadmin should be familiar with.
In this blog, we will show you how to do a point-in-time recovery of your Galera Cluster. An important component here is the MySQL binary log, which contains events that describe all database changes. After the latest backup has been restored, the events in the binary log that were recorded after the backup was taken will be re-executed. Thus, it is possible to replay transactions up to the last consistent state of the database, right before the erroneous command was issued.