[
https://issues.apache.org/jira/browse/HBASE-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack resolved HBASE-5275.
----------------------------------
Resolution: Won't Fix
Stale. Context is different now.
> Create migration for hbase-2600 meta table rejigger so regions denoted by end
> row
> ---------------------------------------------------------------------------------
>
> Key: HBASE-5275
> URL: https://issues.apache.org/jira/browse/HBASE-5275
> Project: HBase
> Issue Type: Task
> Reporter: Michael Stack
> Priority: Major
>
> Chatting with Alex, we'd do as was done previous where we'll can data from
> 0.92 and then have a test that unbundles this canned data, migrates it and
> then makes sure all still works. Migration test would include verification
> of idempotency; i.e. if migration fails midway, we should be able to rerun it.
> Canned data should include a meta with splits and WALs to split (migrations
> usually require clean shutdown so no WALs should be in place but just in
> case... And replication is reading logs)
> We were thinking that on startup, we'd check hbase.version file. If not
> updated, we'd rewrite .META. offline before starting up.
> In offline mode -- open of the .META. regions -- we'd do a rewrite per row
> changing the HRegionInfo version from VERSION=1 to VERSION=2.
> VERSION=2 is the new format HRegionInfo.
> VERSION=2 will use endrow but it will keep its current encoded name (though
> it was generated with startrow as input) so we don't have to move stuff
> around in filesystem.
> New HRIs subsequent to the migration will be written out as VERSION=3. A
> VERSION=3 has endrow in its name but the encoded name will be made using
> startrow+endrow+regionid+tablename rather than just
> startrow+regionid+tablename as in VERSION=1.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
