[
https://issues.apache.org/jira/browse/HBASE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266656#comment-13266656
]
nkeywal commented on HBASE-5877:
--------------------------------
Generated with protobuf 2.4.1
Here are the things I'm not a big fan, but for which I don't have a better
solution:
- the move management in the client code: I think it's possible to change the
way we manage error (don't wait for all results before retrying), but that
would be for another JIRA
- the destination is the closeRegion interface is a kind of interface
hijacking. Other options would be:
- sharing the region state in zookeeper
- letting the regionserver calls the master to get the new server. On paper
this would be more efficient than a client -> master call. In both cases we
could consider that the client should not connect to the master except for
cluster administration (create table, split regin; ...). That would increase
global reliability. That's for another discussion as well I think.
Here is what I plan to do in the final version
- move the handler functional code into a function in HRegionServer: this would
allow to have the function addToMovedRegion as private instead of public.
- Change all the CloseRegionHandler to take a RegionServer instead of a server?
I'm not really keen on adding a class RegionServerServices, but may be I should?
- Manage the case when the destination is not specified at the beginning of the
move (may be in a different Jira if it's not simple)...
All the previous comment should have been taken into account.
> When a query fails because the region has moved, let the regionserver return
> the new address to the client
> ----------------------------------------------------------------------------------------------------------
>
> Key: HBASE-5877
> URL: https://issues.apache.org/jira/browse/HBASE-5877
> Project: HBase
> Issue Type: Improvement
> Components: client, master, regionserver
> Affects Versions: 0.96.0
> Reporter: nkeywal
> Assignee: nkeywal
> Priority: Minor
> Fix For: 0.96.0
>
> Attachments: 5877.v1.patch, 5877.v6.patch
>
>
> This is mainly useful when we do a rolling restart. This will decrease the
> load on the master and the network load.
> Note that a region is not immediately opened after a close. So:
> - it seems preferable to wait before retrying on the other server. An
> optimisation would be to have an heuristic depending on when the region was
> closed.
> - during a rolling restart, the server moves the regions then stops. So we
> may have failures when the server is stopped, and this patch won't help.
> The implementation in the first patch does:
> - on the region move, there is an added parameter on the regionserver#close
> to say where we are sending the region
> - the regionserver keeps a list of what was moved. Each entry is kept 100
> seconds.
> - the regionserver sends a specific exception when it receives a query on a
> moved region. This exception contains the new address.
> - the client analyses the exeptions and update its cache accordingly...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
