Hypothetical case (probably asked a number of time here, sorry...): Can a client correcty put, get, scan (no admins tasks such as create table,...) with a HBase cluster having its HMaster process down ?
(if really the case, 'master' could be renamed to 'admin' to make it clear that it is 'optional'). Thx, Eric On 10/02/12 20:00, Doug Meil wrote: > > Also, there is a description of what is in META and ROOT in here... > > http://hbase.apache.org/book.html#arch.catalog > > ... and it also describes the startup sequencing. > > > > > > On 2/10/12 10:46 AM, "Harsh J"<[email protected]> wrote: > >> The client does communicate with the master to perform .META. changing >> interactions (create/delete tables, etc.). And for the rest, like >> locating regions off regionservers and reading off them, the master >> isn't touched (afaik). >> >> The master's work is also more about running/providing cluster >> management services for the many region servers than serving clients >> all the while. >> >> See the interfaces HMasterRegionInterface and MasterServices on trunk >> to get a view of what all functions the master carries out, on a high >> level, and why its role is important though clients may not need it >> beyond administrative purposes. >> >> 2012/2/10 yonghu<[email protected]>: >>> Thanks for your reply. If the -ROOT- and .META. tables are managed by >>> two RegionServer separately. What is the functionality of Master node? >>> It only assigns the Region node in the cluster? So, the client only >>> needs to contact with these two special RegionServer which contains >>> the -ROOT- and .META. tables. If the interaction model is like what I >>> said, the client will not contact with master node! If I am wrong, >>> let me know. >>> >>> Thanks >>> >>> Yong >>> >>> On Fri, Feb 10, 2012 at 12:47 PM, Harsh J<[email protected]> wrote: >>>> The HMaster does not host regions, and the -ROOT- is a region; It is >>>> hosted by one of the assigned RegionServers, and its location is >>>> registered under ZooKeeper. The -ROOT- region then holds the location >>>> of the .META. (Which again, is another region, and is hosted by >>>> RegionServers in just the same way). >>>> >>>> For your ZK question, if you run ZK in HBase's embedded mode, it runs >>>> on the HMaster, while if you run it standalone you can choose to run >>>> it anywhere. The latter method is what is recommended for production >>>> deployments, and its preferable to host it separately on its own >>>> boxes. >>>> >>>> P.s. The JIRA at https://issues.apache.org/jira/browse/HBASE-3171 may >>>> simplify this someday :) >>>> >>>> 2012/2/10 yonghu<[email protected]>: >>>>> Thanks! >>>>> I know this. I just want to know which nodes store this information >>>>> when the client first contact to HBase cluster, HMaster or >>>>> RegionServer or a special node in which runs the zookeeper. >>>>> >>>>> And the other question is whether zookeeper runs on the same nodes as >>>>> Hbase in the cluster or it runs in a separate nodes? >>>>> >>>>> Yong >>>>> >>>>> On Fri, Feb 10, 2012 at 12:16 PM, Roger<[email protected]> wrote: >>>>>> To my knowledge, it is a three level tree-like structure. >>>>>> ------------------ >>>>>> 该邮件从移动设备发送 >>>>>> >>>>>> ------------------ Original ------------------ >>>>>> From: "yonghu"<[email protected]> >>>>>> Date: Fri, Feb 10, 2012 07:12 PM >>>>>> To: "user"<[email protected]>; >>>>>> Subject: Which server store the root and .meta. information? >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> I read some articles which mention before the client connect to the >>>>>> master node, he will first connect to the zookeeper node and find the >>>>>> location of the root node. So, my question is that the node which >>>>>> stores the root information is different from master node or they are >>>>>> the same node? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Yong >>>> >>>> >>>> >>>> -- >>>> Harsh J >>>> Customer Ops. Engineer >>>> Cloudera | http://tiny.cloudera.com/about >> >> >> >> -- >> Harsh J >> Customer Ops. Engineer >> Cloudera | http://tiny.cloudera.com/about >> > -- eric | http://about.echarles.net | @echarles
