Return-Path: X-Original-To: apmail-hbase-user-archive@www.apache.org Delivered-To: apmail-hbase-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BAFE4D0B3 for ; Mon, 2 Jul 2012 23:57:18 +0000 (UTC) Received: (qmail 51180 invoked by uid 500); 2 Jul 2012 23:57:15 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 51085 invoked by uid 500); 2 Jul 2012 23:57:15 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 50940 invoked by uid 99); 2 Jul 2012 23:57:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jul 2012 23:57:15 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of svarma.ng@gmail.com designates 209.85.214.41 as permitted sender) Received: from [209.85.214.41] (HELO mail-bk0-f41.google.com) (209.85.214.41) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jul 2012 23:57:11 +0000 Received: by bkcjc3 with SMTP id jc3so3271709bkc.14 for ; Mon, 02 Jul 2012 16:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gLCLwVzFaYmqPZnv350i1r+GtgfLT2IZNzutauUKKDA=; b=jP3Z16K782HyBddUA2wxSVS4kxmkLQk6RxW0IANTk0du0lrIhMKWlXf3PAwQ/DB8D5 +JOSteGIcb7+XfC9TcZ9Hk7JhUUb8muO3JoqKjfHw8JDDFPg35UqQhhtTpdyMlbgTiOb dOXvclW4Q1xyC0xOXcHp0Uo/jAF/ofYCe0L5Ap3+EnidVQIyVllHopCoGZLqPVP1NaRr DzNkEkXyyEjNuemO6c4uF1a2HSwyrgxQvPBPtdbTgmLMMCM4lFI1USWFd0iO1+r4W8Bo nyFQd4VlDexKkwJ9YtT3nQhmlsBVU7MIvQgxsIiM/QW0MBqnj6kUGc9LE8TaqVMF88ZQ kJNw== MIME-Version: 1.0 Received: by 10.204.151.81 with SMTP id b17mr8608738bkw.52.1341273410069; Mon, 02 Jul 2012 16:56:50 -0700 (PDT) Received: by 10.204.178.198 with HTTP; Mon, 2 Jul 2012 16:56:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Jul 2012 16:56:50 -0700 Message-ID: Subject: Re: HMaster not failing over dead RegionServers From: Suraj Varma To: user@hbase.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org This looks like it is trying to reach a datanode ... doesn't it? > 12/06/30 00:07:22 INFO ipc.Client: Retrying connect to server: /10.125.18.129:50020. Already tried 14 time(s). Is this from a master log or from a region server log? (I'm guess the above is from a region server log while trying to replay hlogs) Sometime back, we had a similar symptom (HLog splitting takes the long time due to the retries) and found that even though the datanode died, it was not being detected by the namenode. This leads to the region server retrying over dead datanodes over and over stretching out the splitting process. See this thread: http://www.mail-archive.com/core-user@hadoop.apache.org/msg10033.html We found that by default, it takes 15 mins for a datanode death to be detected by a NN ... and this seems to cause the NN serving back the dead DN as a valid one when RS tries to read the hlogs. The parameters in question are: dfs.heartbeat.recheck.interval and heartbeat.recheck.interval ... tweaking this down caused the recovery to be much faster. Also - hbase.rpc.timeout and zookeeper.session.timeout are two other configurations that need to be tweaked down from defaults for quick recovery. Not sure if this is the case in your error - but, might be something to investigate ... --Suraj On Sat, Jun 30, 2012 at 8:53 AM, Jimmy Xiang wrote: > Bryan, > > The master could not detect if the region server is dead. > How do you set the zookeeper session timeout? > > Thanks, > Jimmy > > On Sat, Jun 30, 2012 at 8:09 AM, Stack wrote: >> On Sat, Jun 30, 2012 at 7:04 AM, Bryan Beaudreault >> wrote: >>> 12/06/30 00:07:22 INFO ipc.Client: Retrying connect to server: / >>> 10.125.18.129:50020. Already tried 14 time(s). >>> >> >> This was one of the servers that went down? >> >>> It was not following through the splitting of HLog files and didn't appear >>> to be moving regions off failed hosts. After giving it about 20 minutes to >>> try to right itself, I tried restarting the service. The restart script >>> just hung for a while printing dots and nothing apparent was happening on >>> the logs at the time. >> >> Can we see the log Bryan? >> >> You might thread dump when its hung-up the next time Bryan (Would be >> something for us to do a looksee on). >> >>> Finally I kill -9 the process, so that another >>> master could take over. The new master seemed to start splitting logs, but >>> eventually got into the same state of printing the above message. >>> >> >> You think it a particular log? >> >> >>> Eventually it all worked out, but it took WAY too long (almost an hour, all >>> said). Is this something that is tunable? >> >> Have RS carry less WALs? Its a configuration. >> >>> They should have instantly been >>> removed from the list instead of retrying so many times. Each server was >>> retried upwards of 30-40 times. >>> >> >> Yeah, thats a bit silly. >> >> We're working on the MTTR in general. You logs would be of interest >> to a few of us if its ok that someone else can take a look. >> >> St.Ack >> >>> I am running cdh3u2 (0.90.4). >>> >>> Thanks, >>> >>> Bryan