0
votes

This question related to 2nd Gen instances of Google CloudSQL.

When you perform point in time recovery on Google's CloudSQL platform, you must actually clone the instance, then specify the binary log file name and position to roll forward on.

I am unsure how this actually works internally, does it work out which backup needs to be first restored then which binary log files, if any, preclude the one you have selected? Or it does it clone the current state of the instance and roll back to the desired binary log file/position?

What if you have multiple binary log files in your chain since the last backup, i.e. because you have manually flushed logs?

Let's say you have a chain that looks like this in CloudSQL:

Full Backup > mysql-binlog.000001 > mysql-binlog.000002 > mysql-binlog.000003 > Full Backup > mysql-binlog.000004

and you want to restore to a recovery point in mysql-binlog.000003 - how do you do that, or do you not need to specify the precluding binlog files like you would if you were doing a native import with mysqlbinlog utility?

1

1 Answers

1
votes

You need to restore to the previous backup and then select the binlog that contains the point-in-time for which you want to go back to. You need to find and select that final point in the binlog to restore to. The instructions are here.

To answer your specific question, you only need to select the latest binlog (the one that contains the point-in-time). You basically choose the backup and then the binlog, and then the point in the binlog and the restoring is done by us.