[HBASE-26276] Allow HashTable/SyncTable to perform rawScan when comparing cells

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.0-alpha-1, 2.2.7, 2.5.0, 2.3.6, 2.4.6
• Fix Version/s: 2.5.0, 2.2.8, 3.0.0-alpha-2, 2.3.7, 2.4.7

Release Note

Added --rawScan option to HashTable job, which allows HashTable/SyncTable to perform raw scans. If this property is omitted, it defaults to false. When used together with --versions set to a high value, SyncTable will fabricate delete markers to all old versions still hanging (not cleaned yet by major compaction), avoiding the inconsistencies reported in HBASE-21596.

• Assignee: Wellington Chevreuil
• Reporter: Wellington Chevreuil
• Created: 10/Sep/21 10:37
• Updated: 14/Sep/21 13:17
• Resolved: 10/Sep/21 16:17

Description

We had noticed some of our customers having inconsistent results when running HashTable/SyncTable in scenarios described previously by HBASE-21596. As discussed on HBASE-21596, one alternative to avoid such inconsistencies, is to set 'NEW_VERSION_BEHAVIOUR' introduced by HBASE-15968. That, however, does rely on the order of operations, which can't be guaranteed when standard replication (not serial replication) is being used, which is the case on the majority of our customers.

A possible workaround is to place delete markers to every single cell version returned on a raw scan, and setting a high value to the scan number of versions to be read.

Issue Links

• relates to: HBASE-21596 Delete for a specific cell version can bring back versions above VERSIONS limit
• links to: GitHub Pull Request #3673