wchevreuil commented on code in PR #7364:
URL: https://github.com/apache/hbase/pull/7364#discussion_r2448564788
##########
hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/impl/BackupAdminImpl.java:
##########
@@ -186,7 +186,10 @@ private void finalizeDelete(List<String> backupRoots,
BackupSystemTable table)
table.deleteIncrementalBackupTableSet(backupRoot);
if (!incrTableSet.isEmpty()) {
- table.addIncrementalBackupTableSet(incrTableSet, backupRoot);
+ // added 1ms to prevent LostUpdate problem in case when
deleteIncrementalBackupTableSet()
+ // executed very fast
+ long ts = EnvironmentEdgeManager.currentTime() + 1;
+ table.addIncrementalBackupTableSet(incrTableSet, backupRoot, ts);
}
}
Review Comment:
Ok, so the issue is that some servers are just so fast that the DELETE
generated in line 187 can have the same timestamp as the PUT generated in line
192?
It doesn't seem the backup code cares about the cells timestamps for the
backup system table, so I think you can simply add your +1 increment inside the
addIncrementalBackupTableSet method, no need to override it to expose the ts
parameter. I think that would be good enough to ensure the PUT is always at
least 1 millisecond younger than the DELETE.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
