Copilot commented on code in PR #8542:
URL: https://github.com/apache/hbase/pull/8542#discussion_r3740813975
##########
hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/BackupInfo.java:
##########
@@ -516,8 +528,13 @@ public static BackupInfo fromProto(BackupProtos.BackupInfo
proto) {
context.setState(BackupInfo.BackupState.valueOf(proto.getBackupState().name()));
}
- context
- .setHLogTargetDir(BackupUtils.getLogBackupDir(proto.getBackupRootDir(),
proto.getBackupId()));
+ // Only incremental backups have a WAL target directory. Setting this
unconditionally would
+ // hand FULL backups a non-null path that never existed, which
cleanupHLogDir() would then
+ // try to delete.
+ if (BackupType.valueOf(proto.getBackupType().name()) ==
BackupType.INCREMENTAL) {
+ context.setHLogTargetDir(
Review Comment:
This condition regresses deletion of FULL backups.
`BackupAdminImpl.deleteBackup` relies on `cleanupBackupData`, but
`cleanupTargetDir` removes only per-table directories, while `.backup.manifest`
is stored directly under the backup-id path (`BackupManifest.java:494-496`).
Previously the synthetic log path made `cleanupHLogDir` enumerate and delete
every child of that path; returning `null` here now skips that cleanup and
leaves the manifest and backup-id directory behind after the system-table
record is deleted. Please either retain the existing reconstruction or decouple
backup-root/manifest cleanup from the WAL directory before making FULL backups
return `null`.
--
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]
