#48963 restore can incorrectly remove changelog (if backup was online)
Opened 3 years ago by lkrispen. Modified 5 months ago

An online backup copies all databaseand changlog files and the txn logs to a backup directory. Writes are not disabled during backup. Since the txn logs are part of the backup during the restore all comitted operations are recovered and changelog and database are in sync.
But the online backup does also write the changelog maxRUV, it is written at the start of the backup and does not match teh final database RUV after restore.
At startup the database RUV and the changelog maxRUV are compared and if they don't match the changelog is reloaded (assuming it is invalid).

This is an unnecessary loss of a valid changelog database.

There are potentially three options to fix it:

1] write the CL ruv at the end of the backup.
this is not really possible, the POST_BACKUP_FN entry point is after the backup completed, any earlier entry point would have rade conditions with real updates

2] do not write the CL in backup, after restore the CL ruv is not there and will be reconstructed, and it will have the correct value. just the first startup can be a bit slower

3] disable updates during online restore, this should work, but would counteract the intention of online backup

There is probably a 4th option:

4] make use of the mechanism implemented in ticket #48402 to flag a startup after restore. write the cl ruv as now, but when starting after restore recreate the ruv (like in 2]), but start at the found CL RUV, this should only have to iterate thru a few csns

There is a variant of 4] which I would prefer

5] - use the database RUV as starting point, don't write CL RUV at online backup
With the new feature (#48402) to detect if startup is after restore we know that changelog and database are consistent. The CL RUV is missing and the database RUV can be behind (but only for some changes since the last DB RUV store.
So using the database RUV as start iteration in the CL, the CL max RUV can be calculated and set as database RUV. This is already done for startup after disorderly shutdown.

Metadata Update from @lkrispen:
- Issue set to the milestone:

3 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: None
- Issue set to the milestone: (was:

3 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Issue set to the milestone: 1.4.2 (was:

a year ago

Metadata Update from @vashirov:
- Issue set to the milestone: 1.4.4 (was: 1.4.2)

5 months ago

Login to comment on this ticket.