apache
HBASE-28957: Adding support for continuous Backup and Point-in-Time Recovery
Summary
This PR introduces Continuous Backup and Point-in-Time Recovery (PITR) support in HBase. The feature enables continuous WAL archival and recovery to any specific point in time, providing stronger data protection and recovery flexibility.
Key Highlights
- Enables continuous backup instead of batch-based incremental backups.
- Supports precise point-in-time recovery to mitigate data loss due to corruption or accidental updates.
- Simplifies WAL management and backup lifecycle handling.
- Improves reliability and reduces storage overhead on the source cluster.
For detailed design and implementation, refer to the design document: [Continuous Backup and Point-in-Time Recovery]
:broken_heart: -1 overall
| Vote | Subsystem | Runtime | Logfile | Comment |
|---|---|---|---|---|
| +0 :ok: | reexec | 0m 31s | Docker mode activated. | |
| _ Prechecks _ | ||||
| +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. | |
| +0 :ok: | codespell | 0m 0s | codespell was not available. | |
| +0 :ok: | detsecrets | 0m 0s | detect-secrets was not available. | |
| +0 :ok: | shelldocs | 0m 0s | Shelldocs was not available. | |
| +0 :ok: | buf | 0m 1s | buf was not available. | |
| +0 :ok: | buf | 0m 1s | buf was not available. | |
| +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | |
| +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. | |
| _ master Compile Tests _ | ||||
| +0 :ok: | mvndep | 0m 33s | Maven dependency ordering for branch | |
| +1 :green_heart: | mvninstall | 4m 29s | master passed | |
| +1 :green_heart: | compile | 8m 57s | master passed | |
| +1 :green_heart: | checkstyle | 2m 34s | master passed | |
| +1 :green_heart: | spotbugs | 16m 2s | master passed | |
| +1 :green_heart: | spotless | 1m 17s | branch has no errors when running spotless:check. | |
| -0 :warning: | patch | 1m 54s | Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary. | |
| _ Patch Compile Tests _ | ||||
| +0 :ok: | mvndep | 0m 15s | Maven dependency ordering for patch | |
| -1 :x: | mvninstall | 4m 1s | /patch-mvninstall-root.txt | root in the patch failed. |
| -1 :x: | compile | 10m 2s | /patch-compile-root.txt | root in the patch failed. |
| -1 :x: | cc | 10m 2s | /patch-compile-root.txt | root in the patch failed. |
| -0 :warning: | javac | 10m 2s | /patch-compile-root.txt | root in the patch failed. |
| +1 :green_heart: | blanks | 0m 0s | The patch has no blanks issues. | |
| -0 :warning: | checkstyle | 2m 28s | /results-checkstyle-root.txt | root: The patch generated 51 new + 3 unchanged - 0 fixed = 54 total (was 3) |
| +1 :green_heart: | shellcheck | 0m 2s | No new issues. | |
| +1 :green_heart: | xmllint | 0m 1s | No new issues. | |
| -1 :x: | spotbugs | 0m 21s | /patch-spotbugs-hbase-backup.txt | hbase-backup in the patch failed. |
| -1 :x: | spotbugs | 8m 24s | /patch-spotbugs-root.txt | root in the patch failed. |
| -1 :x: | hadoopcheck | 3m 17s | The patch causes 16 errors with Hadoop v3.3.6. | |
| -1 :x: | hadoopcheck | 6m 25s | The patch causes 16 errors with Hadoop v3.4.1. | |
| -1 :x: | hbaseprotoc | 0m 17s | /patch-hbaseprotoc-hbase-backup.txt | hbase-backup in the patch failed. |
| -1 :x: | hbaseprotoc | 2m 37s | /patch-hbaseprotoc-root.txt | root in the patch failed. |
| -1 :x: | spotless | 0m 43s | patch has 23 errors when running spotless:check, run spotless:apply to fix. | |
| _ Other Tests _ | ||||
| +1 :green_heart: | asflicense | 0m 44s | The patch does not generate ASF License warnings. | |
| 80m 58s |
| Subsystem | Report/Notes |
|---|---|
| Docker | ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/1/artifact/yetus-general-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/7445 |
| JIRA Issue | HBASE-28957 |
| Optional Tests | dupname asflicense codespell detsecrets shellcheck shelldocs spotless javac xmllint hadoopcheck compile spotbugs checkstyle hbaseanti cc buflint bufcompat hbaseprotoc |
| uname | Linux 8f7e9e8df756 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 12e129276b4f840cde55677c61854fb9c6dbc0ff |
| Default Java | Eclipse Adoptium-17.0.11+9 |
| hadoopcheck | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/1/artifact/yetus-general-check/output/patch-javac-3.3.6.txt |
| hadoopcheck | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/1/artifact/yetus-general-check/output/patch-javac-3.4.1.txt |
| spotless | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/1/artifact/yetus-general-check/output/patch-spotless.txt |
| Max. process+thread count | 190 (vs. ulimit of 30000) |
| modules | C: hbase-protocol-shaded hbase-server hbase-mapreduce hbase-backup . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/1/console |
| versions | git=2.34.1 maven=3.9.8 spotbugs=4.7.3 shellcheck=0.8.0 xmllint=20913 |
| Powered by | Apache Yetus 0.15.0 https://yetus.apache.org |
This message was automatically generated.
:broken_heart: -1 overall
| Vote | Subsystem | Runtime | Logfile | Comment |
|---|---|---|---|---|
| +0 :ok: | reexec | 0m 28s | Docker mode activated. | |
| -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck | |
| _ Prechecks _ | ||||
| _ master Compile Tests _ | ||||
| +0 :ok: | mvndep | 0m 33s | Maven dependency ordering for branch | |
| +1 :green_heart: | mvninstall | 4m 30s | master passed | |
| +1 :green_heart: | compile | 2m 12s | master passed | |
| +1 :green_heart: | javadoc | 2m 58s | master passed | |
| +1 :green_heart: | shadedjars | 6m 10s | branch has no errors when building our shaded downstream artifacts. | |
| -0 :warning: | patch | 6m 40s | Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary. | |
| _ Patch Compile Tests _ | ||||
| +0 :ok: | mvndep | 0m 11s | Maven dependency ordering for patch | |
| -1 :x: | mvninstall | 3m 5s | /patch-mvninstall-root.txt | root in the patch failed. |
| -1 :x: | compile | 2m 4s | /patch-compile-root.txt | root in the patch failed. |
| -0 :warning: | javac | 2m 4s | /patch-compile-root.txt | root in the patch failed. |
| -0 :warning: | javadoc | 0m 12s | /results-javadoc-javadoc-hbase-backup.txt | hbase-backup generated 4 new + 0 unchanged - 0 fixed = 4 total (was 0) |
| -0 :warning: | javadoc | 1m 55s | /results-javadoc-javadoc-root.txt | root generated 4 new + 210 unchanged - 0 fixed = 214 total (was 210) |
| +1 :green_heart: | shadedjars | 6m 6s | patch has no errors when building our shaded downstream artifacts. | |
| _ Other Tests _ | ||||
| -1 :x: | unit | 227m 32s | /patch-unit-root.txt | root in the patch failed. |
| 265m 24s |
| Subsystem | Report/Notes |
|---|---|
| Docker | ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/1/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/7445 |
| JIRA Issue | HBASE-28957 |
| Optional Tests | javac javadoc unit shadedjars compile |
| uname | Linux c9e3fbeb55f2 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 12e129276b4f840cde55677c61854fb9c6dbc0ff |
| Default Java | Eclipse Adoptium-17.0.11+9 |
| Test Results | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/1/testReport/ |
| Max. process+thread count | 4373 (vs. ulimit of 30000) |
| modules | C: hbase-protocol-shaded hbase-server hbase-mapreduce hbase-backup . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/1/console |
| versions | git=2.34.1 maven=3.9.8 |
| Powered by | Apache Yetus 0.15.0 https://yetus.apache.org |
This message was automatically generated.
:confetti_ball: +1 overall
| Vote | Subsystem | Runtime | Logfile | Comment |
|---|---|---|---|---|
| +0 :ok: | reexec | 0m 31s | Docker mode activated. | |
| _ Prechecks _ | ||||
| +1 :green_heart: | dupname | 0m 1s | No case conflicting files found. | |
| +0 :ok: | codespell | 0m 1s | codespell was not available. | |
| +0 :ok: | detsecrets | 0m 1s | detect-secrets was not available. | |
| +0 :ok: | shelldocs | 0m 1s | Shelldocs was not available. | |
| +0 :ok: | buf | 0m 0s | buf was not available. | |
| +0 :ok: | buf | 0m 0s | buf was not available. | |
| +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | |
| +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. | |
| _ master Compile Tests _ | ||||
| +0 :ok: | mvndep | 0m 33s | Maven dependency ordering for branch | |
| +1 :green_heart: | mvninstall | 4m 31s | master passed | |
| +1 :green_heart: | compile | 8m 48s | master passed | |
| +1 :green_heart: | checkstyle | 2m 21s | master passed | |
| +1 :green_heart: | spotbugs | 12m 34s | master passed | |
| +1 :green_heart: | spotless | 0m 55s | branch has no errors when running spotless:check. | |
| -0 :warning: | patch | 1m 25s | Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary. | |
| _ Patch Compile Tests _ | ||||
| +0 :ok: | mvndep | 0m 11s | Maven dependency ordering for patch | |
| +1 :green_heart: | mvninstall | 3m 10s | the patch passed | |
| +1 :green_heart: | compile | 8m 45s | the patch passed | |
| +1 :green_heart: | cc | 8m 45s | the patch passed | |
| -0 :warning: | javac | 8m 45s | /results-compile-javac-root.txt | root generated 12 new + 1896 unchanged - 0 fixed = 1908 total (was 1896) |
| +1 :green_heart: | blanks | 0m 0s | The patch has no blanks issues. | |
| -0 :warning: | checkstyle | 2m 22s | /results-checkstyle-root.txt | root: The patch generated 50 new + 3 unchanged - 0 fixed = 53 total (was 3) |
| +1 :green_heart: | shellcheck | 0m 0s | No new issues. | |
| +1 :green_heart: | xmllint | 0m 0s | No new issues. | |
| +1 :green_heart: | spotbugs | 13m 8s | the patch passed | |
| +1 :green_heart: | hadoopcheck | 12m 53s | Patch does not cause any errors with Hadoop 3.3.6 3.4.1. | |
| +1 :green_heart: | hbaseprotoc | 4m 54s | the patch passed | |
| +1 :green_heart: | spotless | 0m 57s | patch has no errors when running spotless:check. | |
| _ Other Tests _ | ||||
| +1 :green_heart: | asflicense | 0m 58s | The patch does not generate ASF License warnings. | |
| 87m 47s |
| Subsystem | Report/Notes |
|---|---|
| Docker | ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/2/artifact/yetus-general-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/7445 |
| JIRA Issue | HBASE-28957 |
| Optional Tests | dupname asflicense codespell detsecrets shellcheck shelldocs spotless javac xmllint hadoopcheck compile spotbugs checkstyle hbaseanti cc buflint bufcompat hbaseprotoc |
| uname | Linux a4010f884649 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 6aa212f5abe3b1556740c3e7e80a4761d21a1c15 |
| Default Java | Eclipse Adoptium-17.0.11+9 |
| Max. process+thread count | 191 (vs. ulimit of 30000) |
| modules | C: hbase-protocol-shaded hbase-server hbase-mapreduce hbase-backup . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/2/console |
| versions | git=2.34.1 maven=3.9.8 spotbugs=4.7.3 shellcheck=0.8.0 xmllint=20913 |
| Powered by | Apache Yetus 0.15.0 https://yetus.apache.org |
This message was automatically generated.
:confetti_ball: +1 overall
| Vote | Subsystem | Runtime | Logfile | Comment |
|---|---|---|---|---|
| +0 :ok: | reexec | 0m 30s | Docker mode activated. | |
| -0 :warning: | yetus | 0m 3s | Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck | |
| _ Prechecks _ | ||||
| _ master Compile Tests _ | ||||
| +0 :ok: | mvndep | 0m 33s | Maven dependency ordering for branch | |
| +1 :green_heart: | mvninstall | 4m 31s | master passed | |
| +1 :green_heart: | compile | 2m 14s | master passed | |
| +1 :green_heart: | javadoc | 2m 58s | master passed | |
| +1 :green_heart: | shadedjars | 6m 17s | branch has no errors when building our shaded downstream artifacts. | |
| -0 :warning: | patch | 6m 47s | Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary. | |
| _ Patch Compile Tests _ | ||||
| +0 :ok: | mvndep | 0m 11s | Maven dependency ordering for patch | |
| +1 :green_heart: | mvninstall | 3m 5s | the patch passed | |
| +1 :green_heart: | compile | 2m 12s | the patch passed | |
| +1 :green_heart: | javac | 2m 12s | the patch passed | |
| -0 :warning: | javadoc | 0m 13s | /results-javadoc-javadoc-hbase-backup.txt | hbase-backup generated 4 new + 0 unchanged - 0 fixed = 4 total (was 0) |
| -0 :warning: | javadoc | 1m 56s | /results-javadoc-javadoc-root.txt | root generated 4 new + 210 unchanged - 0 fixed = 214 total (was 210) |
| +1 :green_heart: | shadedjars | 6m 8s | patch has no errors when building our shaded downstream artifacts. | |
| _ Other Tests _ | ||||
| +1 :green_heart: | unit | 290m 6s | root in the patch passed. | |
| 329m 45s |
| Subsystem | Report/Notes |
|---|---|
| Docker | ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/2/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/hbase/pull/7445 |
| JIRA Issue | HBASE-28957 |
| Optional Tests | javac javadoc unit shadedjars compile |
| uname | Linux 488b63b537ab 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 6aa212f5abe3b1556740c3e7e80a4761d21a1c15 |
| Default Java | Eclipse Adoptium-17.0.11+9 |
| Test Results | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/2/testReport/ |
| Max. process+thread count | 7246 (vs. ulimit of 30000) |
| modules | C: hbase-protocol-shaded hbase-server hbase-mapreduce hbase-backup . U: . |
| Console output | https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7445/2/console |
| versions | git=2.34.1 maven=3.9.8 |
| Powered by | Apache Yetus 0.15.0 https://yetus.apache.org |
This message was automatically generated.
@wchevreuil I have answers to some of your questions:
- Is this a per-table configuration?
Backups need to be enabled in the HBase conf file via hbase.backup.enable. For continuous backups, a backup WAL directory needs to be set via hbase.backup.continuous.wal.dir. Backups can be done on a per-table basis.
- Do we need to define a specific replication peer for this?
A replication peer is defined by default as continuous_backup_replication_peer using the CONTINUOUS_BACKUP_REPLICATION_PEER constant.
- Do we keep pitr wal files indefinitely?
No, WALs outside of the PITR window get cleaned up automatically. They are also removed when the backup is deleted. This is tracked in HBASE-28992
- Can we include doc changes within this PR?
I believe that is the plan. It's still a work in progress.
- If we have normal replication enabled (a normal replication peer), will all CFs with REPLICATION_SCOPE = 1 also be targeted for this PITR?
Negative. Continuous backup needs a special replication endpoint to be set for the peer ContinuousBackupReplicationEndpoint. Normal replication peers are not affected and work fine side-by-side.
- Should the pitr endpoint replicate method consider if the underlying FS supports sync before deciding the result to return?
The PITR endpoint assumes that sync() is not supported by the filesystem which is usually the case with object stores like S3. The WAL pointer gets persisted only when the stream is closed.
- Does it support pause (disable_peer)?
This is a very good question. Given that it's a standard replication endpoint, I would say sure, why not. This is something that we should validate sooner rather than later..
7. Can we include doc changes within this PR?
I suggest to finish reviewing and merging this patch first. Proper documentation and integration testing should come afterwards in separate PRs.
- Does it support pause (disable_peer)?
This is a very good question. Given that it's a standard replication endpoint, I would say sure, why not. This is something that we should validate sooner rather than later..
@anmolnar @wchevreuil We actually use that. When cleaning up WAL files, if all the files are removed (which happens when deleting the last full backup — the bare minimum required for PITR), we disable the peer.
More details: BackupCommands.java#L900
- If we have normal replication enabled (a normal replication peer), will all CFs with REPLICATION_SCOPE = 1 also be targeted for this PITR?
Negative. Continuous backup needs a special replication endpoint to be set for the peer
ContinuousBackupReplicationEndpoint. Normal replication peers are not affected and work fine side-by-side.
How does the PITR Endpoint avoids backing up entries for CFs with REPLICATION_SCOPE set to true (for normal replication), but which are not primarily wanted to be in PITR backups? Is it possible to "opt out" from PITR at CF table/level?
@wchevreuil I have answers to some of your questions:
- Is this a per-table configuration?
Backups need to be enabled in the HBase conf file via
hbase.backup.enable. For continuous backups, a backup WAL directory needs to be set viahbase.backup.continuous.wal.dir. Backups can be done on a per-table basis.
Will this trigger backups on all existing tables?
- Do we need to define a specific replication peer for this?
A replication peer is defined by default as
continuous_backup_replication_peerusing the CONTINUOUS_BACKUP_REPLICATION_PEER constant.
Can you elaborate further how this peer is defined?
- Do we keep pitr wal files indefinitely?
No, WALs outside of the PITR window get cleaned up automatically. They are also removed when the backup is deleted. This is tracked in HBASE-28992
Ok, so we can only do actually PITR within that window period. Can you point me to the code in this PR where this is implemented?
- If we have normal replication enabled (a normal replication peer), will all CFs with REPLICATION_SCOPE = 1 also be targeted for this PITR?
Negative. Continuous backup needs a special replication endpoint to be set for the peer
ContinuousBackupReplicationEndpoint. Normal replication peers are not affected and work fine side-by-side.How does the PITR Endpoint avoids backing up entries for CFs with REPLICATION_SCOPE set to true (for normal replication), but which are not primarily wanted to be in PITR backups? Is it possible to "opt out" from PITR at CF table/level?
@wchevreuil That is determined when starting the continuous backup.
For example, if you want to start continuous backup for table1, you initiate a full backup with the continuous backup option enabled. This performs the full backup and adds the table to the continuous_backup_replication_peer (the default replication peer used for continuous backup).
If the column families don’t already have replication scope enabled, it’s also set to true at this stage. Please refer to the following methods for details: https://github.com/apache/hbase/blob/6aa212f5abe3b1556740c3e7e80a4761d21a1c15/hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/impl/FullTableBackupClient.java#L269 enableTableReplication() updateContinuousBackupReplicationPeer() addContinuousBackupReplicationPeer()
So, if you manually change the replication scope to true for a random table, it will not be replicated as part of the continuous backup, since it’s not included in the continuous_backup_replication_peer.
Can you elaborate further how this peer is defined?
https://github.com/apache/hbase/blob/6aa212f5abe3b1556740c3e7e80a4761d21a1c15/hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/impl/FullTableBackupClient.java#L269
this contains the whole logic.
Ok, so we can only do actually PITR within that window period. Can you point me to the code in this PR where this is implemented?
here is the PITR logic is defined. validateAndRestore() method. https://github.com/apache/hbase/blob/6aa212f5abe3b1556740c3e7e80a4761d21a1c15/hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/impl/AbstractPitrRestoreHandler.java#L68
And this is where the clean-up logic is defined — how backed-up WALs are cleaned up as part of continuous backup. https://github.com/apache/hbase/blob/6aa212f5abe3b1556740c3e7e80a4761d21a1c15/hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/impl/BackupCommands.java#L900
@wchevreuil I have answers to some of your questions:
- Is this a per-table configuration?
Backups need to be enabled in the HBase conf file via
hbase.backup.enable. For continuous backups, a backup WAL directory needs to be set viahbase.backup.continuous.wal.dir. Backups can be done on a per-table basis.Will this trigger backups on all existing tables?
@wchevreuil You trigger a backup by running the hbase backup create full command on the desired table(s).
For example: hbase backup create full table1,table2,...,tableN
@wchevreuil I have answers to some of your questions:
- Is this a per-table configuration?
Backups need to be enabled in the HBase conf file via
hbase.backup.enable. For continuous backups, a backup WAL directory needs to be set viahbase.backup.continuous.wal.dir. Backups can be done on a per-table basis.Will this trigger backups on all existing tables?
@wchevreuil You trigger a backup by running the
hbase backup create fullcommand on the desired table(s). For example:hbase backup create full table1,table2,...,tableN
Ok, so only after a full backup is created on a given table through the described command is when that table is added to the pitr replication peer. Is there any action that may remove a given table from the list of tables tracked by the pitr replication peer?
Is there any action that may remove a given table from the list of tables tracked by the pitr replication peer?
@wchevreuil The only action I can think of is forcefully deleting the full backup (i.e. using --force-delete), as that is the foundation of the backup and thus the PITR. If the last full backup for the table is forcefully deleted, then all of the continuous backup metadata, associated WAL files, and the replication peer are cleaned up. If the user tries to delete the final full backup for that table without using --force-delete, then the delete attempt fails since that particular backup is important for the backup's integrity.
@vinayakphegde @ankitsol @anmolnar Can one of you please confirm?
Is there any action that may remove a given table from the list of tables tracked by the pitr replication peer?
@wchevreuil The only action I can think of is forcefully deleting the full backup (i.e. using
--force-delete), as that is the foundation of the backup and thus the PITR. If the last full backup for the table is forcefully deleted, then all of the continuous backup metadata, associated WAL files, and the replication peer are cleaned up. If the user tries to delete the final full backup for that table without using--force-delete, then the delete attempt fails since that particular backup is important for the backup's integrity.@vinayakphegde @ankitsol @anmolnar Can one of you please confirm?
Correct. related code: https://github.com/apache/hbase/blob/6aa212f5abe3b1556740c3e7e80a4761d21a1c15/hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/impl/BackupCommands.java#L900
LGTM, all my questions have been addressed.
Regarding the wal tracking approach, I don't have a strong opinion. @Apache9 , do you think this is a blocker for this merge? Or an alternative could be worked as a follow-up PR?
We're working on a pull request currently which would give us some insight on the alternative approach and lets us decide which way to move forward. Hopefully will be ready in a few days.
I suggest we try the approach to not introduce the new 'ReplicationResult' concept to see if it could work before merging this back. Once the new concept is there, it will be difficult to remove it in the future, as later code may rely on it too...
