Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-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 981BD1027C for ; Thu, 15 Aug 2013 16:23:02 +0000 (UTC) Received: (qmail 58529 invoked by uid 500); 15 Aug 2013 16:22:54 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 58337 invoked by uid 500); 15 Aug 2013 16:22:49 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 58311 invoked by uid 99); 15 Aug 2013 16:22:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 16:22:47 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW X-Spam-Check-By: apache.org Received-SPF: error (nike.apache.org: local policy) Received: from [209.85.212.41] (HELO mail-vb0-f41.google.com) (209.85.212.41) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 16:22:42 +0000 Received: by mail-vb0-f41.google.com with SMTP id g17so765878vbg.28 for ; Thu, 15 Aug 2013 09:22:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=DjpIisZNewjlHirQexaAMpLgeeCoVk+/QwJxWdkDEZc=; b=fLzi+5Hr97Ko5rCyFRYMDoTGVq/U3uLaN169haQxtOwmu2pBhfARUlHldZpA4Pmrdi vujx3UpMg8X9tkBQCy7xxRC/tFipEgh2P+y+A9oVI/akYWIqBfNfN0YyO2Z5PV4f7iZx qlaDm/A3EFk06Wme6qyDWy4I8G0baPn/kkGZWS8sNr/jA3Q52IlWKqSLuWZxbz3Qto1u GZHO8X9BZU1VO5bPv5Bh9DldA3Ns18TbLMRv8RntxQAV0+qpH6hjZWrkjJf5xEMMrbUU l7D8A5LfFSntDt1ICVDRAvi82Cbawlse2hWdtg3qJbwQpNXI8sV+NnUgyfyQf9+oePb/ GWqw== X-Gm-Message-State: ALoCoQl992kGLsT23M2gKriSHj3llklEs6UvZEatEmdH7uQtmqYETR2sZPu2eEELGC/UGomghQJI MIME-Version: 1.0 X-Received: by 10.52.73.33 with SMTP id i1mr437672vdv.51.1376583721026; Thu, 15 Aug 2013 09:22:01 -0700 (PDT) Received: by 10.220.40.69 with HTTP; Thu, 15 Aug 2013 09:22:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Aug 2013 12:22:00 -0400 Message-ID: Subject: Re: How to re-IP an Accumulo Cluster From: Keith Turner To: user@accumulo.apache.org Content-Type: multipart/alternative; boundary=20cf3071c7e8b21ee204e3fedf83 X-Virus-Checked: Checked by ClamAV on apache.org --20cf3071c7e8b21ee204e3fedf83 Content-Type: text/plain; charset=ISO-8859-1 Use zkCli.sh and look in /accumulo/ In 1.4 Accumulo started locking its info in zookeeper down, so you may need to execute the following command : addauth digest accumulo:SECRET Replace SECRET with the secret from your accumulo-site.xml file. On Thu, Aug 15, 2013 at 12:05 PM, Terry P. wrote: > Hi Keith, > Many thanks for your detailed reply. I forgot to mention that yes indeed > this is on Accumulo 1.4.2, and it was the write-ahead logs that were the > issue -- partly because two of the tabletservers were not properly shutdown > before the re-IP operation, so recovery may have been needed on them. > > My naivety on Zookeeper certainly hampered the research as well. How does > one "look in zookeeper to see what is going on?" Any pointers would be > really helpful. > > I wish we could go to 1.5 and take advantage of the walogs in HDFS, but no > can do at this point unfortunately. > > > On Thu, Aug 15, 2013 at 10:24 AM, Keith Turner wrote: > >> >> >> >> On Thu, Aug 15, 2013 at 11:01 AM, Terry P. wrote: >> >>> Greetings everyone, >>> We had to re-IP our entire cluster recently to change subnetworks, and >>> we essentially lost everything (it was development, so no big deal). >>> However, doing a re-IP operation may be required in actual operational >>> cases, and I'd like to know if it can be done or not so we can note it for >>> the future (as in document "what not to do" to avoid data loss). >>> >>> The issue we had was that after shutting down the cluster, re-IPing all >>> servers, and starting everything back up, the tablets were still assigned >>> to Tabletservers with the old IP addresses, even though all the hostnames >>> were the same. So the system showed 3 Tabletservers, but no tablets, and >>> no entries in the tables where previously there were 400 million. >>> >>> So: >>> >>> A) Does Zookeeper track Tabletservers by IP address only, and not >>> hostname? >>> >> >> It does track by IP address, but not only IP address. Each tablet server >> has an ephemeral node in zookeeper under the IP address. This ehpemeral >> node should go away when the tserver process dies, and then the master will >> assume that tserver is dead. The location of a tablet in the metadata >> table is conceptually +, so once that >> ephemeral node goes away the location in metadata table is assumed invalid >> and the tablet is reassigned. If another tserver starts at the same IP, >> then the master can differentiate because the ephemeral node is different. >> >> You can look at the children nodes under a tserver ip in zookeeper. Look >> at the data for the lowest numbered ephemeral node to to get infor about >> who holds the lock for that IP. >> >> >> >> >>> B) If A is true, is there a mechanism to change those entries in >>> Zookeeper so that a re-IP operation could be performed? >>> >> >> A first step would be to look in zookeeper and see what going on with the >> ephemeral nodes. >> >> In Accumulo 1.3 and 1.4 one thing that normally causes problems when >> changing lots of IP addrs is write ahead logs. Tablets point to their >> write ahead logs using the IP address of the logger. This can cause walog >> recovery to fail. In 1.5 walog are stored in HDFS so this not an issue. >> >> > --20cf3071c7e8b21ee204e3fedf83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Use zkCli.sh and look in /accumulo/<accumulo instance i= d>

In 1.4 Accumulo started locking its info in = zookeeper down, so you may need to execute the following command :

=A0 addauth digest accumulo:SECRET
Replace SECRET with the secret from your accumulo-site.xm= l file.




On Thu, Aug 15, 2013 at 12:05 PM, Terry = P. <texpilot@gmail.com> wrote:
Hi Keith,
Many thanks for your det= ailed reply. I forgot to mention that yes indeed this is on Accumulo 1.4.2,= and it was the write-ahead logs that were the issue -- partly because two = of the tabletservers were not properly shutdown before the re-IP operation,= so recovery may have been needed on them.

My naivety on Zookeeper certainly hampered the research as well.= =A0 How does one "look in zookeeper to see what is going on?"=A0 = Any pointers would be really helpful.

I wish we could go to 1.= 5 and take advantage of the walogs in HDFS, but no can do at this point unf= ortunately.

On Thu, Aug 15, 2013 at 10:24 AM, Keith Tu= rner <keith@deenlo.com> wrote:



On Thu, Aug 15, 2013 at 11:01 A= M, Terry P. <texpilot@gmail.com> wrote:
Greetin= gs everyone,
We had to re-IP our entire cluster recently to change= subnetworks, and we essentially lost everything (it was development, so no= big deal).=A0 However, doing a re-IP operation may be required in actual o= perational cases, and I'd like to know if it can be done or not so we c= an note it for the future (as in document "what not to do" to avo= id data loss).

The issue we had was that after shutting down the cluster, re-IPi= ng all servers, and starting everything back up, the tablets were still ass= igned to Tabletservers with the old IP addresses, even though all the hostn= ames were the same.=A0 So the system showed 3 Tabletservers, but no tablets= , and no entries in the tables where previously there were 400 million.

So:

A) Does Zookeeper track Tabletservers by IP addr= ess only, and not hostname?

It does track by IP address, but not only IP address. =A0Each tablet serve= r has an ephemeral node in zookeeper under the IP address. =A0This ehpemera= l node should go away when the tserver process dies, and then the master wi= ll assume that tserver is dead. =A0The location of a tablet in the metadata= table is conceptually <ephemeral node id>+<IP address>, so onc= e that ephemeral node goes away the location in metadata table is assumed i= nvalid and the tablet is reassigned. =A0 If another tserver starts at the s= ame IP, then the master can differentiate because the ephemeral node is dif= ferent.

You can look at the children nodes under a tserver ip i= n zookeeper. =A0Look at the data for the lowest numbered ephemeral node to = to get infor about who holds the lock for that IP.




B) If A is true, is there a mechanism to change those entr= ies in Zookeeper so that a re-IP operation could be performed?

A first step would be to look = in zookeeper and see what going on with the ephemeral nodes. =A0=A0

In Accumulo 1.3 and 1.4 one thing that normally causes pr= oblems when changing lots of IP addrs is write ahead logs. =A0 Tablets poin= t to their write ahead logs using the IP address of the logger. This can ca= use walog recovery to fail. =A0In 1.5 walog are stored in HDFS so this not = an issue.



--20cf3071c7e8b21ee204e3fedf83--