[
https://issues.apache.org/jira/browse/HBASE-28897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18011821#comment-18011821
]
Vinayak Hegde commented on HBASE-28897:
---------------------------------------
[~hgromer] Thanks for fixing the issue.
As part of https://issues.apache.org/jira/browse/HBASE-29484, we're updating
the backup and restore documentation to reflect the latest changes.
Since this Jira also touches the backup and restore components, could you
please review the changes and check if any updates to the documentation are
needed? If so, kindly create a sub-task under
https://issues.apache.org/jira/browse/HBASE-29484 detailing the required
documentation updates. You’re welcome to assign it to yourself and work on it,
or we’d be happy to take it up as well.
Thanks!
> Force CF compatibility during incremental backup
> -------------------------------------------------
>
> Key: HBASE-28897
> URL: https://issues.apache.org/jira/browse/HBASE-28897
> Project: HBase
> Issue Type: Bug
> Components: backup&restore
> Affects Versions: 3.0.0-beta-1, 4.0.0-alpha-1, 2.7.0, 2.6.2
> Reporter: Hernan Gelaf-Romer
> Assignee: Hernan Gelaf-Romer
> Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0-beta-2, 2.6.2
>
>
> Incremental backups can be taken even if the table descriptor of the current
> table does not match the column families of the full backup for that same
> table. When restoring the table, we choose to use the families of the full
> backup. This can cause the restore process to fail if we add a column family
> in the incremental backup that doesn't exist in the full backup. The bulkload
> process will fail because it is trying to write column families that don't
> exist in the restore table.
>
> I think the correct solution here is to prevent incremental backups from
> being taken if the families of the current table don't match those of the
> full backup. This will force users to instead take a full backup.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
