Uh oh!
There was an error while loading. Please reload this page.
HBASE-28696 Partition BackupSystemTable queries - #6067
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Uh oh!
There was an error while loading. Please reload this page.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ndimiduk
left a comment
There was a problem hiding this comment.
Yes, BufferedMutator wraps up this use-case nicely. Please clean this up a bit more and it looks good for merge.
| return Bytes.toString(data).substring(SET_KEY_PREFIX.length()); | ||
| } | ||
| private void executeBufferedMutations(Table table, List<? extends Mutation> mutations) |
There was a problem hiding this comment.
This helper function is now kinda weird. I think that you can replace all the above try (Table table = ...) { ... } with try (BufferedMutator bm = ...) { ... }. On quick glance, you never use the table instance other than to get the name in order to create the BufferedMutator instance.
Apache-HBase
commented
Sep 6, 2024
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Sep 6, 2024
🎊 +1 overall
This message was automatically generated. |
Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
When successfully taking an incremental backup, one of our final steps is to delete bulk load metadata from the system table for the bulk loads that needed to be captured in the given backup. This means that we will basically truncate the entire bulk loads system table in a single batch of the deletes after successfully taking an incremental backup. Depending on your usage, one may run tons of bulk loads between backups, so this design is needlessly fragile. We should partition these deletes so that we never erroneously fail a backup due to this; there are a few other cases where we generated unbounded multi requests in the BackupSystemTable that this PR addresses too.
A few questions here:
@charlesconnell@ndimiduk