[
https://issues.apache.org/jira/browse/HBASE-26537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456707#comment-17456707
]
Bryan Beaudreault commented on HBASE-26537:
-------------------------------------------
[~zhangduo] the reason I decided to only commit this to branch-1 is as follows:
* HBASE-15676 has been integrated for almost 6 years, and landed in the 2.0.0
release
* As such, anyone running 2.0.0 or higher will not be affected by this bug,
only those running a 1.x prior to that Jira – so they must be running a minor
version over 5 years old.
* The implementation of FuzzyRowFilter in 1.1.5, 1.2.2, 1.3.0, 2.0.0 is not
broken – just the ability to upgrade from a previous release to one of those
releases.
* 1.x line is EOL I believe (or almost EOL), but definitely the 1.x releases
implicated in the bug are EOL. I.E. < 1.1.5 and < 1.2.2
* This fix is sort of ugly – it will immortalize the old mask format from
pre-15676 and a new proto field to switch between them.
* Since all releases in our currently supported versions already use the new
mask format, it seems best not to pollute these branches with this
compatibility shim
Correct me if I'm wrong on this, but let's rewind back to April 2016. If we had
caught this bug before merging, we would have required the shim for branch-1
but allowed the cleaner breaking change in branch-2. So the intent of
submitting this patch is to make it possible for those users running very old
EOL releases to have an upgrade path. The idea is they'd do this:
* Upgrade to a version with this patch – either backport it to themselves, or
upgrade to HEAD of branch-1 or 1.8.0 if that gets released.
** Upgrade server first, then client
* From there they can upgrade to any 2.x release or 3.x release.
Does this sound reasonable?
> FuzzyRowFilter backwards compatibility
> --------------------------------------
>
> Key: HBASE-26537
> URL: https://issues.apache.org/jira/browse/HBASE-26537
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.1.13, 1.2.12, 1.3.6
> Reporter: Bryan Beaudreault
> Priority: Major
>
> HBASE-15676 introduced a backwards incompatible change which makes it
> impossible to upgrade in our designated upgraded order (server first, then
> client) without potential bad results. Worse, the failure mode is silent – a
> pre-HBASE-15676 client would incorrectly receive 0 results from a
> post-HBASE-15676 server.
> I solved this internally as part of our upgrade from 1.2.0 to 2.4.6 by adding
> a new proto field to switch between the two implementations. I'm submitting
> this Jira to capture and potentially backport that fix for anyone else who
> encounters it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
