Hi Fredrik,
Stack suggested it could be that your servers have in the nsswitch.conf
to use files before dns? Could you try for us and switch that, revert
the entry in the /etc/hosts and then try if the options J-D suggest to
see if they work for this problem?
Then we can document this properly in the overview.html or up on the wiki.
Thanks,
Lars
Jean-Daniel Cryans wrote:
Fredrik,
First, thanks for trying out trunk.
wrt your problem, have you tried setting the following configs?
hbase.master.dns.interface
hbase.master.dns.nameserver
This works just like in Hadoop.
The reason we removed the master address is that the master can now
failover to any other waiting master. You see how this could confuse
everything if it moves 2-3 times?
Thx,
J-D
On Mon, Jun 15, 2009 at 1:00 PM, Fredrik
Möllerstrand<[email protected]> wrote:
Hello list!
I've spent the better part of the afternoon upgrading from 0.19.3 to
trunk, and I did fall into a hole or two. Specifically, it turns out
that we rely on DNS lookups to find out what address HMaster binds to,
which caused me some grief. The documentation is also weak on what
part Zookeeper plays in the process; a stronger write-up of how HBase
utilizes Zookeeper would be a great help in troubleshooting issues
like this.
Basically, I saw the region servers trying to connect to
127.0.0.1:6000 without any hint as to why, neither in the (default)
configuration nor the logs.
HMaster happily reported this:
INFO org.apache.hadoop.hbase.master.HMaster: My address is
master2.internal.net:6000
quickly followed by:
INFO org.apache.hadoop.hbase.master.HMaster: HMaster initialized on
127.0.0.1:6000
The cause was simple and my face-palm genuine as the realization
struck me: there was a record for master2 in the hosts file, and it
was pointing to 127.0.0.1.
I suggest that an hbase.master.address option (that overrides any
resolved address) would make it easier to get the installation up and
running.
Cheers,
Fredrik
