kudu-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weber, Richard" <riwe...@akamai.com>
Subject Re: Feature request for Kudu 1.3.0
Date Fri, 10 Feb 2017 18:32:01 GMT
I definitely would push for prioritization on this.

 

Our main use case is less about multiple racks and failure, and more about functionality during
the install process.  Our clusters are installed in logical regions, and we install 1/3 of
a region at a time.  That means 1/3 of the cluster can be down for the SW install, reboot,
or something else.  Allowing rack locality to be logically defined will allow the data to
still be available during normal maintenance operations.

 

 

 

 

-- Rick Weber

 

 

From: Todd Lipcon <todd@cloudera.com>
Reply-To: "user@kudu.apache.org" <user@kudu.apache.org>
Date: Friday, February 10, 2017 at 12:45 PM
To: "user@kudu.apache.org" <user@kudu.apache.org>
Subject: Re: Feature request for Kudu 1.3.0

 

Hi Jeff, 

 

Thanks for the input on prioritization.

 

I'm curious: do you have more than two racks in your cluster? With Kudu's replication strategy,
we need at least three racks to be able to survive a full rack outage. (with just two racks
it's impossible to distinguish a loss of a rack with a partition between the two racks).

 

-Todd

 

On Fri, Feb 10, 2017 at 7:27 AM, Jeff Dasch <jeff_dasch@yahoo.com> wrote:

Any chance we can get a fix for KUDU-1535 "Add rack awareness" added to the 1.3.0 release?


 

While I appreciate the need for Kerberos and TLS for some production systems, for my use-case
data availability really takes priority.

 

I looked at your scoping document, and for what it's worth, I'm fine with a shell script that
is similar to what Hadoop uses.

 

thanks,

-jeff

 

 

 



 

-- 

Todd Lipcon
Software Engineer, Cloudera


Mime
View raw message