On Oracle Cloud Infrastructure, aka OCI, MySQL Database Service, aka MDS uses the snapshot technology to backup your data.
This article is the second part of multiple part blog series. In part 1, we dealt with taking snapshots as backup. In this part, we deal with restoring the data.
We saw in the post one how to create the snapshots automatically (Backup Plan) or Manually. Both type of backups are what we call Managed Snapshots. This means that as a user, we don’t have access to the Object Storage where the backup is stored.
So what’s the purpose of these snapshots ?
Let’s see them:
Restoring a MDS backup is recommended of course to save the data and in case of issue (hardware or software problem unlikely or human issue more likely), we have the possibility to recover the data as it was at the time of the backup.
There are some important points to know before dealing with the backups and restoring them:
- if you delete an instance, all the automatic backups (from the Backup Plan) are also gone
- manual backups are kept for the entire retention period
- if you restore a backup from an active DB System, you will get a warning as some source values, such as IP address still exist.
Let’s see how we can restore a snapshot:
Then we get the wizard screen where we have some options we can change.
The first section is about changing the compartment, the name and the description of the new MySQL DB System:
As you can see, it’s not possible to enable HA if the source wasn’t a HA instance too.
You can modify the placement by choosing a different Availability Domain (or Fault Domain):
And by default the shape is the same as the snapshot’s source:
You finally need to click on Restore and the new instance will be deployed with the same data as the backup.
As this is a Volume Group Snapshot, we can see it as a filesystem snapshot. Therefor, to restore at the same consistent point as the source, InnoDB Recovery process is needed and we can see it in the error log:
| 2021-07-30 17:56:50.065844 | 1 | Note | MY-012551 | InnoDB | Database was not shutdown normally! | | 2021-07-30 17:56:50.065915 | 1 | Note | MY-012552 | InnoDB | Starting crash recovery. | | 2021-07-30 17:56:50.317713 | 1 | Note | MY-013086 | InnoDB | Starting to parse redo log at lsn = 263759567374, whereas checkpoint_lsn = 263759567747 and start_lsn = 263759567360
After that operation, the system is ready and available:
We saw previously that HA and HeatWave were not possible during the restore operation. However, as the Shape was compatible with HeatWave, we can still enable it after restore:
Changing the Shape of your MySQL DB System in OCI is something that almost every new user does. Indeed, you start with a small instance to test and then you want that test to become more important and use it more often. But you quickly realize that you would benefit from a bigger server. More CPU power and more RAM.
Or you just want to use HeatWave and you didn’t select a compatible Shape at start.
Restoring a backup is the perfect operation to achieve that goal.
One important point is that you cannot restore on a shape with less memory:
As we did for the Shape, it’s also possible to restore using the same Shape but increasing the disk space.
This is an easy task, you just click on Restore to New DB System and you increase the size (you can’t decrease):
Restoring a snapshot is very useful to create a new identical instance of your MySQL DB System or to recover data. It’s also useful to increase the Disk Data Storage. And finally to upgrade the Shape or migrate to a HeatWave compatible shape.