Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-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 6FCA118828 for ; Fri, 19 Jun 2015 21:40:36 +0000 (UTC) Received: (qmail 49348 invoked by uid 500); 19 Jun 2015 21:40:33 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 49297 invoked by uid 500); 19 Jun 2015 21:40:33 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 49287 invoked by uid 99); 19 Jun 2015 21:40:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Jun 2015 21:40:33 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mgitman@gmail.com designates 209.85.213.182 as permitted sender) Received: from [209.85.213.182] (HELO mail-ig0-f182.google.com) (209.85.213.182) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Jun 2015 21:38:18 +0000 Received: by igblr2 with SMTP id lr2so1433840igb.0 for ; Fri, 19 Jun 2015 14:40:06 -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=m0Erc8YgT8NsLJkIAKJaM48unbsrtHgJjkELT4PDaWY=; b=WaJGs732nZ8vDfq4t8/aupdgsd5YqsQ1gaWi1QhAFKjNC0gqlc/0dU9k4hPl2LwH5q W46WYAPdn30Q+KIIhvGX8fdG30uQ/ucmRcDA31jh0O/eCo+xWjZbcJ8SetO19YjyNR/h GNxTR1QQ4dbn1pCZlCOGIf12md8wgXawdoFh8sQJcJOtPMAVg90pB+hBmKWjqtvOEpsV 9eFpQNrjLHXNVIFGb4sUBUtQ2dhnGk04OZd5A0O8dVQjOwUid9qsdDlbq5kfhurAnisx dOryNJV4YT5WM908gUOVv7vZULOmIyYD2YVZaCkk7wpZcVLfYGPSITSIusT3eJaFgTEM JThg== MIME-Version: 1.0 X-Received: by 10.42.43.199 with SMTP id y7mr14137410ice.12.1434750005915; Fri, 19 Jun 2015 14:40:05 -0700 (PDT) Received: by 10.107.30.7 with HTTP; Fri, 19 Jun 2015 14:40:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jun 2015 14:40:05 -0700 Message-ID: Subject: Re: sstableloader "Could not retrieve endpoint ranges" From: Mitch Gitman To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=bcaec519694171b7ef0518e5c4fd X-Virus-Checked: Checked by ClamAV on apache.org --bcaec519694171b7ef0518e5c4fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fabien, thanks for the reply. We do have Thrift enabled. From what I can tell, the "Could not retrieve endpoint ranges:" crops up under various circumstances. >From further reading on sstableloader, it occurred to me that it might be a safer bet to use the JMX StorageService bulkLoad command, considering that the data to import was already on one of the Cassandra nodes, just in an arbitrary directory outside the Cassandra data directories. I was able to get this bulkLoad command to fail with a message that the directory structure did not follow the expected keyspace/table/ pattern. So I created a keyspace directory and then a table directory within that and moved all the files under the table directory. Executed bulkLoad, passing in that directory. It succeeded. Then I went and ran a nodetool refresh on the table in question. Only one problem. If I then went to query the table for, well, anything, nothing came back. And this was after successfully querying the table before and truncating the table just prior to the bulkLoad, so that I knew that only the data coming from the bulkLoad could show up there. Oh, and for good measure, I stopped and started all the nodes too. No luck still. What's puzzling about this is that the bulkLoad silently succeeds, even though it doesn't appear to be doing anything. I haven't bothered yet to check the Cassandra logs. On Fri, Jun 19, 2015 at 12:28 AM, Fabien Rousseau wrote: > Hi, > > I already got this error on a 2.1 clusters because thrift was disabled. S= o > you should check that thrift is enabled and accessible from the > sstableloader process. > > Hope this help > > Fabien > Le 19 juin 2015 05:44, "Mitch Gitman" a =C3=A9crit : > >> I'm using sstableloader to bulk-load a table from one cluster to another= . >> I can't just copy sstables because the clusters have different topologie= s. >> While we're looking to upgrade soon to Cassandra 2.0.x, we're on Cassand= ra >> 1.2.19. The source data comes from a "nodetool snapshot." >> >> Here's the command I ran: >> sstableloader -d *IP_ADDRESSES_OF_SEED_NOTES* */SNAPSHOT_DIRECTORY/* >> >> Here's the result I got: >> Could not retrieve endpoint ranges: >> -pr,--principal kerberos principal >> -k,--keytab keytab location >> --ssl-keystore ssl keystore location >> --ssl-keystore-password ssl keystore password >> --ssl-keystore-type ssl keystore type >> --ssl-truststore ssl truststore location >> --ssl-truststore-password ssl truststore password >> --ssl-truststore-type ssl truststore type >> >> Not sure what to make of this, what with the hints at security arguments >> that pop up. The source and destination clusters have no security. >> >> Hoping this might ring a bell with someone out there. >> > --bcaec519694171b7ef0518e5c4fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fabien, thanks for the reply. We do have Thrift enabl= ed. From what I can tell, the "Could not retrieve endpoint ranges:&quo= t; crops up under various circumstances.

From furt= her reading on sstableloader, it occurred to me that it might be a safer be= t to use the JMX StorageService bulkLoad command, considering that the data= to import was already on one of the Cassandra nodes, just in an arbitrary = directory outside the Cassandra data directories.

= I was able to get this bulkLoad command to fail with a message that the dir= ectory structure did not follow the expected keyspace/table/ pattern. So I = created a keyspace directory and then a table directory within that and mov= ed all the files under the table directory. Executed bulkLoad, passing in t= hat directory. It succeeded.=C2=A0

Then I went and= ran a nodetool refresh on the table in question.=C2=A0

Only one problem. If I then went to query the table for, well, anythi= ng, nothing came back. And this was after successfully querying the table b= efore and truncating the table just prior to the bulkLoad, so that I knew t= hat only the data coming from the bulkLoad could show up there.
<= br>
Oh, and for good measure, I stopped and started all the nodes= too. No luck still.

What's puzzling about thi= s is that the bulkLoad silently succeeds, even though it doesn't appear= to be doing anything. I haven't bothered yet to check the Cassandra lo= gs.

On= Fri, Jun 19, 2015 at 12:28 AM, Fabien Rousseau <fabifabi95@gmail.com> wrote:

Hi,

I already got this error on a 2.1 clusters because thrift wa= s disabled. So you should check that thrift is enabled and accessible from = the sstableloader process.

Hope this help

Fabien

Le=C2=A019 juin 2015 05:44, "Mitch Gitman&q= uot; <mgitman@gma= il.com> a =C3=A9crit=C2=A0:
I'm using sstableloader to bulk-load a table from one cluste= r to another. I can't just copy sstables because the clusters have diff= erent topologies. While we're looking to upgrade soon to Cassandra 2.0.= x, we're on Cassandra 1.2.19. The source data comes from a "nodeto= ol snapshot."

Here's the command I ran:
sstableloader -d IP_ADDRESSES_OF= _SEED_NOTES /SNAPSHOT_DIRECTORY/

Here's the result I got:
Could no= t retrieve endpoint ranges:=C2=A0
=C2=A0-pr,--principal =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kerberos princi= pal
=C2=A0-k,--keytab =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 keytab location
=C2=A0--ssl-keystore= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0ssl keystore location
=C2=A0--ssl-keystore-password =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ssl keystore password
=C2=A0--ssl-keyst= ore-type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ssl= keystore type
=C2=A0--ssl-truststore =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ssl truststore location
=C2=A0--ss= l-truststore-password =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ssl trustst= ore password
=C2=A0--ssl-truststore-type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 ssl truststore type

Not sure what to make of this, w= hat with the hints at security arguments that pop up. The source and destin= ation clusters have no security.

=
Hoping this might ring a bell with someone out t= here.

--bcaec519694171b7ef0518e5c4fd--