[
https://issues.apache.org/jira/browse/HBASE-19052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222845#comment-16222845
]
stack edited comment on HBASE-19052 at 10/27/17 9:20 PM:
---------------------------------------------------------
I love the rationale that has it that because there is no test in issue A,
issue B doesn't need one and that migration being neither branch-1 nor
branch-2, but in-between, is somehow untestable.
Thanks lads for the reminder on this one. I did not have this in my incompat
section in the hbase2 doc. Added it. I also started up an upgrade/migration
doc. on requirements and how to migrate:
https://docs.google.com/document/d/1sL92WaCcYyBTruTf6PMCHaDiWJV2hbObZIbS_JH_x60/edit#heading=h.m2ilt6k4zqn5
Regards the larger issue of requiring our users double-upgrade.... I see
[~anoop.hbase] asked over in HBASE-16189 the below:
bq. This issue came up again in the dev@ discussion thread. We fixed this in
later versions of 1.x means when rolling upgrade done to 2.0, first users have
to upgrade to some 1.x versions which is having this fix and then to 2.0.. What
do you guys think Whether we should avoid this kind of indirection? cc Enis
Soztutar, Stack, Ted Yu, Matteo Bertozzi
....and he got no answer.
Expecting users to double-upgrade -- first to latest branch-1 and then to
branch-2 -- and then go through a double-rolling restart to upgrade is going to
piss off our operators.
Is trailer the only reason we require folks go to the latest in branch-1 (seems
weird trying to teach hbase1 about hbase2... where do we stop doing this)? If
this the only reason to go to the latest on branch-1, can we figure a means of
doing w/o?
Changing the trailer such that it has arguments that parsers no longer
understand screams for our updating the version on the hfile. But new version
because of change in comparator name doesn't seem substantial enough of a
reason to up our hfile number, not without distinct benefit.
Can we go Poste [1]l here... If we wrote the old name into the hfile, could new
hfile readers in hbase2 map the old String to the new classes?
Thanks.
1. https://en.wikipedia.org/wiki/Robustness_principle
was (Author: stack):
I love the rationale that has it that because there is no test in issue A,
issue B doesn't need one and that migration being neither branch-1 nor
branch-2, but in-between, is somehow untestable.
Thanks lads for the reminder on this one. I did not have this in my incompat
section in the hbase2 doc. Added it. I also started up an upgrade/migration
doc. on requirements and how to migrate:
https://docs.google.com/document/d/1sL92WaCcYyBTruTf6PMCHaDiWJV2hbObZIbS_JH_x60/edit#heading=h.m2ilt6k4zqn5
Regards the larger issue of requiring our users double-upgrade.... I see
[~anoop.hbase] asked over in HBASE-16189 the below:
bq. This issue came up again in the dev@ discussion thread. We fixed this in
later versions of 1.x means when rolling upgrade done to 2.0, first users have
to upgrade to some 1.x versions which is having this fix and then to 2.0.. What
do you guys think Whether we should avoid this kind of indirection? cc Enis
Soztutar, Stack, Ted Yu, Matteo Bertozzi
....and he got no answer.
Expecting users to double-upgrade -- first to latest branch-1 and then to
branch-2 -- and then go through a double-rolling restart to upgrade is going to
piss off our operators.
Is trailer the only reason we require folks go to the latest in branch-1 (seems
weird trying to teach hbase1 about hbase2... where do we stop doing this)? If
this the only reason to go to the latest on branch-1, can we figure a means of
doing w/o?
Changing the trailer such that it has arguments that parsers no longer
understand screams for our updating the version on the hfile. But new version
because of change in comparator name doesn't seem substantial enough of a
reason to up our hfile number, not without distinct benefit.
If we wrote the old name into the hfile, could new hfile readers in hbase2 map
the old String to the new classes?
Thanks.
> FixedFileTrailer should recognize CellComparatorImpl class in branch-1.x
> ------------------------------------------------------------------------
>
> Key: HBASE-19052
> URL: https://issues.apache.org/jira/browse/HBASE-19052
> Project: HBase
> Issue Type: Improvement
> Components: HFile
> Reporter: Ted Yu
> Assignee: Ted Yu
> Priority: Critical
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13
>
> Attachments: 19052.branch-1.txt
>
>
> HBASE-18945 has gone into branch-2 .
> Let's consider rolling upgrade scenario from 1.x to 2.0 where there're three
> servers: s1, s2, s3
> s1 is upgraded to 2.0 first. It flushes to hfile in region r1 with
> CellComparatorImpl written in the hfile trailer.
> Somehow s1 crashes and master assigns r1 to s2 which is still running 1.x
> The following code in FixedFileTrailer would be triggered:
> {code}
> try {
> comparatorKlass = (Class<? extends CellComparator>)
> Class.forName(comparatorClassName);
> } catch (ClassNotFoundException e) {
> throw new IOException(e);
> }
> {code}
> since s2 is not aware of CellComparatorImpl.
> This issue is to backport CellComparatorImpl related change to branch-1.x
> Note: CellComparatorImpl wouldn't be used in write path, only in read path.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
