You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Johan Oskarsson (JIRA)" <ji...@apache.org> on 2007/12/10 19:45:43 UTC
[jira] Created: (HADOOP-2394) Add supprt for migrating between
hbase versions
Add supprt for migrating between hbase versions
-----------------------------------------------
Key: HADOOP-2394
URL: https://issues.apache.org/jira/browse/HADOOP-2394
Project: Hadoop
Issue Type: Improvement
Components: contrib/hbase
Reporter: Johan Oskarsson
If Hbase is to be used to serve data to live systems we would need a way to upgrade both the underlying hadoop installation and hbase to newer versions with minimal downtime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2394) Add supprt for migrating between
hbase versions
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558040#action_12558040 ]
stack commented on HADOOP-2394:
-------------------------------
There is no framework that I can see in HADOOP-2478. The is just a single script that addresses a single migration incident.
> Add supprt for migrating between hbase versions
> -----------------------------------------------
>
> Key: HADOOP-2394
> URL: https://issues.apache.org/jira/browse/HADOOP-2394
> Project: Hadoop
> Issue Type: Improvement
> Components: contrib/hbase
> Reporter: Johan Oskarsson
>
> If Hbase is to be used to serve data to live systems we would need a way to upgrade both the underlying hadoop installation and hbase to newer versions with minimal downtime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2394) Add supprt for migrating between
hbase versions
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551198 ]
Bryan Duxbury commented on HADOOP-2394:
---------------------------------------
What do we think of creating Rails-esque migration scripts for each version change? Each migration script would have to know how to read the previous version's data and write the current version. Then we can add a version number to any files we store in HDFS to indicate what version it was created at.
When you deploy a new version of HBase, you first need to run the migration script. Once the migration is completed successfully, you should be able to start the new version of HBase. Also, the migration script should prefer not overwriting the existing files, instead creating new ones. That way, we're less likely to make some mistake that causes the old data to get lost while the new data is being re-written.
> Add supprt for migrating between hbase versions
> -----------------------------------------------
>
> Key: HADOOP-2394
> URL: https://issues.apache.org/jira/browse/HADOOP-2394
> Project: Hadoop
> Issue Type: Improvement
> Components: contrib/hbase
> Reporter: Johan Oskarsson
>
> If Hbase is to be used to serve data to live systems we would need a way to upgrade both the underlying hadoop installation and hbase to newer versions with minimal downtime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (HADOOP-2394) Add supprt for migrating between
hbase versions
Posted by stack <st...@duboce.net>.
Your scenario, moving from one type to another, should be easy enough to
migrate; you'd just float both classes in the migration task and run the
conversion from one type to the other. But I think you were intending
to ask the harder question of going between versions of the same type.
Taking your example of MapFiles, MapFiles are versioned and it looks
like there's some attempt at making it so newer versions can read files
written by older versions. I'd suggest that any hbase class that makes
marks on the filesystem should be made do likewise. HLog emissions and
catalog tables, -ROOT- and .META., look like obvious candidates for
versioning.
St.Ack
Bryan Duxbury wrote:
> The scheme you propose would be good so long as we only ever do things
> like rename files and move them around. If we ever decide to change
> something significant, like the underlying file structure (like if we
> break away from using MapFile or something), then we'd need the
> ability to read the old version as well as write the new ones. What
> would you like to be able to do in these instances?
>
> On Dec 14, 2007, at 12:46 PM, stack (JIRA) wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/HADOOP-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551938
>> ]
>>
>> stack commented on HADOOP-2394:
>> -------------------------------
>>
>> I like the rails idea. Migration should support going in both
>> directions I'd say.
>>
>> hbase state is all kept out in the filesystem so hopefully,
>> filesystem machinations should be all thats required making migrations.
>>
>> HStoreFiles are MapFiles + an info file stored in a sympathetic
>> directory. This info file has little in it currently -- just
>> sequence id. Could also have hbase version. For log files, perhaps
>> first record is stamp of the hbase version doing the writing.
>>
>> It occurred to me that migrations could entail significant rewriting
>> of on-filesystem data. To distribute the migration, we could we
>> could have the master and regionservers run the migrations. Each
>> server on startup would look for any migrations to run and just run
>> them if any found. Nice thing about this is that we'd get the
>> migration job distributed. But thinking on it, probably better to
>> have the migration done outside of hbase in its own dedicated MR
>> job. Would be easier tracking failures and running reversals.
>>
>>> Add supprt for migrating between hbase versions
>>> -----------------------------------------------
>>>
>>> Key: HADOOP-2394
>>> URL: https://issues.apache.org/jira/browse/HADOOP-2394
>>> Project: Hadoop
>>> Issue Type: Improvement
>>> Components: contrib/hbase
>>> Reporter: Johan Oskarsson
>>>
>>> If Hbase is to be used to serve data to live systems we would need a
>>> way to upgrade both the underlying hadoop installation and hbase to
>>> newer versions with minimal downtime.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>
Re: [jira] Commented: (HADOOP-2394) Add supprt for migrating between hbase versions
Posted by Bryan Duxbury <br...@rapleaf.com>.
The scheme you propose would be good so long as we only ever do
things like rename files and move them around. If we ever decide to
change something significant, like the underlying file structure
(like if we break away from using MapFile or something), then we'd
need the ability to read the old version as well as write the new
ones. What would you like to be able to do in these instances?
On Dec 14, 2007, at 12:46 PM, stack (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/HADOOP-2394?
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#action_12551938 ]
>
> stack commented on HADOOP-2394:
> -------------------------------
>
> I like the rails idea. Migration should support going in both
> directions I'd say.
>
> hbase state is all kept out in the filesystem so hopefully,
> filesystem machinations should be all thats required making
> migrations.
>
> HStoreFiles are MapFiles + an info file stored in a sympathetic
> directory. This info file has little in it currently -- just
> sequence id. Could also have hbase version. For log files,
> perhaps first record is stamp of the hbase version doing the writing.
>
> It occurred to me that migrations could entail significant
> rewriting of on-filesystem data. To distribute the migration, we
> could we could have the master and regionservers run the
> migrations. Each server on startup would look for any migrations
> to run and just run them if any found. Nice thing about this is
> that we'd get the migration job distributed. But thinking on it,
> probably better to have the migration done outside of hbase in its
> own dedicated MR job. Would be easier tracking failures and
> running reversals.
>
>> Add supprt for migrating between hbase versions
>> -----------------------------------------------
>>
>> Key: HADOOP-2394
>> URL: https://issues.apache.org/jira/browse/
>> HADOOP-2394
>> Project: Hadoop
>> Issue Type: Improvement
>> Components: contrib/hbase
>> Reporter: Johan Oskarsson
>>
>> If Hbase is to be used to serve data to live systems we would need
>> a way to upgrade both the underlying hadoop installation and hbase
>> to newer versions with minimal downtime.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
[jira] Commented: (HADOOP-2394) Add supprt for migrating between
hbase versions
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551938 ]
stack commented on HADOOP-2394:
-------------------------------
I like the rails idea. Migration should support going in both directions I'd say.
hbase state is all kept out in the filesystem so hopefully, filesystem machinations should be all thats required making migrations.
HStoreFiles are MapFiles + an info file stored in a sympathetic directory. This info file has little in it currently -- just sequence id. Could also have hbase version. For log files, perhaps first record is stamp of the hbase version doing the writing.
It occurred to me that migrations could entail significant rewriting of on-filesystem data. To distribute the migration, we could we could have the master and regionservers run the migrations. Each server on startup would look for any migrations to run and just run them if any found. Nice thing about this is that we'd get the migration job distributed. But thinking on it, probably better to have the migration done outside of hbase in its own dedicated MR job. Would be easier tracking failures and running reversals.
> Add supprt for migrating between hbase versions
> -----------------------------------------------
>
> Key: HADOOP-2394
> URL: https://issues.apache.org/jira/browse/HADOOP-2394
> Project: Hadoop
> Issue Type: Improvement
> Components: contrib/hbase
> Reporter: Johan Oskarsson
>
> If Hbase is to be used to serve data to live systems we would need a way to upgrade both the underlying hadoop installation and hbase to newer versions with minimal downtime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2394) Add supprt for migrating between
hbase versions
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560204#action_12560204 ]
stack commented on HADOOP-2394:
-------------------------------
Chatting w/ Jim, we need to work out a design for how we see migrations working going forward. I made a start here http://wiki.apache.org/hadoop/Hbase/Migration.
> Add supprt for migrating between hbase versions
> -----------------------------------------------
>
> Key: HADOOP-2394
> URL: https://issues.apache.org/jira/browse/HADOOP-2394
> Project: Hadoop
> Issue Type: Improvement
> Components: contrib/hbase
> Reporter: Johan Oskarsson
>
> If Hbase is to be used to serve data to live systems we would need a way to upgrade both the underlying hadoop installation and hbase to newer versions with minimal downtime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2394) Add supprt for migrating between
hbase versions
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552590 ]
Bryan Duxbury commented on HADOOP-2394:
---------------------------------------
I would say -1 on going back in versions of hbase, because a reverse migration doesn't readily address how to deal with features and settings not available in prior versions. You'd have potential for loss of precision per se in terms of configuration.
Also, I'm not sure why you'd ever want to go from a later version to an earlier version, unless you've mistakenly upgraded in the first place. I suggest that you take care and back up your old HDFS files before migrating instead.
> Add supprt for migrating between hbase versions
> -----------------------------------------------
>
> Key: HADOOP-2394
> URL: https://issues.apache.org/jira/browse/HADOOP-2394
> Project: Hadoop
> Issue Type: Improvement
> Components: contrib/hbase
> Reporter: Johan Oskarsson
>
> If Hbase is to be used to serve data to live systems we would need a way to upgrade both the underlying hadoop installation and hbase to newer versions with minimal downtime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2394) Add supprt for migrating between
hbase versions
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552596 ]
stack commented on HADOOP-2394:
-------------------------------
I ain't too invested in our supporting reverse migrations but its worth noting that any migration system worth its salt -- systems I've worked on in the past and ruby on rails -- go both ways if only to facilitate testing of the forward migration (inevitably there's a bug when you try to migrate real data).
> Add supprt for migrating between hbase versions
> -----------------------------------------------
>
> Key: HADOOP-2394
> URL: https://issues.apache.org/jira/browse/HADOOP-2394
> Project: Hadoop
> Issue Type: Improvement
> Components: contrib/hbase
> Reporter: Johan Oskarsson
>
> If Hbase is to be used to serve data to live systems we would need a way to upgrade both the underlying hadoop installation and hbase to newer versions with minimal downtime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2394) Add supprt for migrating between
hbase versions
Posted by "Jim Kellerman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558037#action_12558037 ]
Jim Kellerman commented on HADOOP-2394:
---------------------------------------
stack wrote:
> I ain't too invested in our supporting reverse migrations but its worth noting that any migration system worth its salt -
> systems I've worked on in the past and ruby on rails - go both ways if only to facilitate testing of the forward migration
> (inevitably there's a bug when you try to migrate real data).
That's what backups are for :)
More importantly though, HADOOP-2478 incorporates a migration tool. The specifics of what the tool does will have to be
rewritten for each upgrade, but I think the framework is good.
> Add supprt for migrating between hbase versions
> -----------------------------------------------
>
> Key: HADOOP-2394
> URL: https://issues.apache.org/jira/browse/HADOOP-2394
> Project: Hadoop
> Issue Type: Improvement
> Components: contrib/hbase
> Reporter: Johan Oskarsson
>
> If Hbase is to be used to serve data to live systems we would need a way to upgrade both the underlying hadoop installation and hbase to newer versions with minimal downtime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.