hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Yu (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-7006) [MTTR] Improve Region Server Recovery Time - Distributed Log Replay
Date Fri, 17 May 2013 21:21:17 GMT

     [ https://issues.apache.org/jira/browse/HBASE-7006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ted Yu updated HBASE-7006:
--------------------------

    Release Note: 
Distributed Log Replay Description:

After a region server fails, we firstly assign a failed region to another region server with
recovering state marked in ZooKeeper. Then a SplitLogWorker directly replays edits from WAL(Write-Ahead-Log)s
of the failed region server to the region after it's re-opened in the new location. When a
region is in recovering state, it can also accept writes but no reads(including Append and
Increment), region split or merge. 

The feature piggybacks on existing distributed log splitting framework and directly replay
WAL edits to another region server instead of creating recovered.edits files.

The advantages over existing log splitting recovered edits implementation:
1) Eliminate the steps to write and read recovered.edits files. There could be thousands of
recovered.edits files are created and written concurrently during a region server recovery.
Many small random writes could degrade the overall system performance.
2) Allow writes even when a region is in recovering state. It only takes seconds for a failed
over region to accept writes again. 

The feature can be enabled by setting hbase.master.distributed.log.replay to true (by default
is false)


  was:
Distributed Log Replay Description:

After a region server fails, we firstly assign a failed region to another region server with
recovering state marked in ZooKeeper. Then a SplitLogWorker directly replays edits from WAL(Write-Ahead-Log)s
of the failed region server to the region after it's re-opened in the new location. When a
region is in recovering state, it can also accept writes but no reads(including Append and
Increment), region split or merge. 

The feature piggybacks on existing distributed log splitting framework and directly replay
WAL edits to another region server instead of creating recovered.edits files.

The advantages over existing log splitting recovered edits implementation:
1) Eliminate the steps to write and read recovered.edits files. There could be thousands of
recovered.edits files are created and written concurrently during a region server recovery.
Many small random writes could degrade the overall system performance.
2) Allow writes even when a region is in recovering state. It only takes seconds for a failed
over region to accept writes again. 

The feature can be disabled by setting hbase.master.distributed.log.replay to false(by default
is true)


    
> [MTTR] Improve Region Server Recovery Time - Distributed Log Replay
> -------------------------------------------------------------------
>
>                 Key: HBASE-7006
>                 URL: https://issues.apache.org/jira/browse/HBASE-7006
>             Project: HBase
>          Issue Type: New Feature
>          Components: MTTR
>            Reporter: stack
>            Assignee: Jeffrey Zhong
>            Priority: Critical
>             Fix For: 0.98.0, 0.95.1
>
>         Attachments: 7006-addendum-2.txt, 7006-addendum-3.txt, hbase-7006-addendum.patch,
hbase-7006-combined.patch, hbase-7006-combined-v1.patch, hbase-7006-combined-v4.patch, hbase-7006-combined-v5.patch,
hbase-7006-combined-v6.patch, hbase-7006-combined-v7.patch, hbase-7006-combined-v8.patch,
hbase-7006-combined-v9.patch, LogSplitting Comparison.pdf, ProposaltoimprovelogsplittingprocessregardingtoHBASE-7006-v2.pdf
>
>
> Just saw interesting issue where a cluster went down  hard and 30 nodes had 1700 WALs
to replay.  Replay took almost an hour.  It looks like it could run faster that much of the
time is spent zk'ing and nn'ing.
> Putting in 0.96 so it gets a look at least.  Can always punt.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message