This will depend on what driver you're using at the client. The Java
driver, for example, has ways to configure each of the things you
mentioned, with a variety of implementations you can choose from. There
are also ways to provide your own custom implementation if you don't like
the options avai
Depending on the use case, creating separate prepared statements for each
combination of set / unset values in large INSERT/UPDATE statements may be
prohibitive.
Instead, you can look into driver level support for UNSET values. Requires
Cassandra 2.2 or later IIRC.
See:
Java Driver:
https://docs
RE #2, some have had good results from having coordinator-only nodes:
https://www.slideshare.net/DataStax/optimizing-your-cluster-with-coordinator-nodes-eric-lubow-simplereach-cassandra-summit-2016
Assuming finite resources, it might be better to be certain you have good
token awareness in your ap
We are engaging in both strategies at the same time:
1) We call it functional sharding - we write to clusters targeted according
to the type of data being written. Because different data types often have
different workloads this has the nice side effect of being able to tune
each cluster accordin
I know this is the official recommendation, and has been for a while. I
highly recommend testing it for yourself though, as our own testing has
shown that for _most_ versions of Cassandra (not all), unlogged batch
meaningfully outperforms parallel execution of individual statements,
especially at
I believe that key estimates won't immediately respond to expired TTL, Not
until after compaction has completely dropped the records (which will
include subtle logic related to gc_grace and partitions with data in
multiple SSTables).
On Wed, May 23, 2018 at 6:18 AM Rahul Singh
wrote:
> If the TT
What is the value returned from Charset.defaultCharset() on both systems?
On Wed, May 16, 2018 at 5:00 AM rami dabbah wrote:
> Hi,
>
> I am trying to query text filed from Cassandra using java driver see code
> below. In windows it is working fine but in linux i am getting ??
> instead of Ch
You can fill in var-args with SomeColumns(myColumns:_*) style syntax.
See for example:
https://stackoverflow.com/questions/1832061/scala-pass-seq-to-var-args-functions
On Fri, Mar 30, 2018 at 6:15 PM Guillermo Ortiz
wrote:
>
> The poblem is that I have a method from Spark to insert into Cassand
Someone can correct me if I'm wrong, but I believe if you do a large IN()
on a single partition's cluster keys, all the reads are going to be served
from a single replica. Compared to many concurrent individual equal
statements you can get the performance gain of leaning on several replicas
for pa
Hi,
Just in case you haven't seen it, I gave a talk last year at the summit. In
the first part of the talk I speak for a while about the lifecycle of a
tombstone, and how they don't always get cleaned up when you might expect.
https://youtu.be/BhGkSnBZgJA
It looks like you're deleting cluster ke
To hop on what Jon said, if your concern is automatic application of schema
migrations, you want to be very careful with this. I'd consider it an
unsolved problem in Cassandra for some methods of schema application.
The failed ALTER is not what you have to worry about, it's two successful
ALTERs
The original timestamp is bigger than the timestamp you're using in your
batch. Cassandra uses timestamps for conflict resolution, so the batch
write will lose.
On Wed, Sep 13, 2017 at 11:59 AM Deepak Panda
wrote:
> Hi All,
>
> Am in the process of learning batch operations. Here is what I trie
You should be able to fairly efficiently iterate all the partition keys
like:
select id, token(id) from table where token(id) >= -9204925292781066255
limit 1000;
id | system.token(id)
+--
...
We've seen an unusually high instance failure rate with i3's (underlying
hardware degradation). Especially with the nodes that have been around
longer (recently provisioned nodes have a more typical failure rate). I
wonder if your underlying hardware is degraded and EC2 just hasn't noticed
yet.
> If using the SimpleStrategy replication class, it appears that
> replication_factor is the only option, which applies to the entire
> cluster, so only one node in both datacenters would have the data.
This runs counter to my understanding, or else I'm not reading your
statement correctly. When
Just curious if you've looked at materialized views. Something like:
CREATE MATERIALIZED VIEW users_by_mod_date AS
SELECT dept_id,mod_date,user_id,user_name FROM users
WHERE mod_date IS NOT NULL
PRIMARY KEY (dept_id,mod_date,user_id)
WITH CLUSTERING ORDER BY (mod_date
Jim's basic model is similar to how we've solved this exact kind of problem
many times. From my own experience, I strongly recommend that you make a
`bucket` field in the partition key, and a `time` field in the cluster
key. Make both of these of data type `timestamp`. Then use application
logic
23, 2017 at 11:43 PM Alain Rastoul
wrote:
On 24/03/2017 01:00, Eric Stevens wrote:
> Assuming an even distribution of data in your cluster, and an even
> distribution across those keys by your readers, you would not need to
> increase RF with cluster size to increase read performance. If yo
Assuming an even distribution of data in your cluster, and an even
distribution across those keys by your readers, you would not need to
increase RF with cluster size to increase read performance. If you have 3
nodes with RF=3, and do 3 million reads, with good distribution, each node
has served 1
Those future tombstones are going to continue to cause problems on those
partitions. If you're still writing to those partitions, you might be
losing data in the mean time. It's going to be hard to get the tombstone
out of the way so that new writes can begin to happen there (newly written
data w
> We’ve actually had several customers where we’ve done the opposite -
split large clusters apart to separate uses cases
We do something similar but for a single application. We're functionally
sharding data to different clusters from a single application. We can have
different server classes fo
This question is probably better suited for the user@ group.
It doesn't sound to me like you've uncovered a bug, but rather you're
engaging in highly contentious paxos, which is rarely going to have a
favorable outcome. Likely you're overwhelming your cluster (or more
specifically the replicas fo
The purpose of timestamps is to guarantee out-of-order conflicting writes
are resolved as last-write-wins. Cassandra doesn't really expect you to be
writing timestamps with wide variations from record to record. Indeed, if
you're doing this, it'll violate some of the assumptions in places such as
You probably want to look at change data capture rather than triggers:
http://cassandra.apache.org/doc/latest/operating/cdc.html
Be aware that one of your criteria regarding operation order is going to be
very difficult to guarantee due to eventual consistency.
On Fri, Dec 16, 2016, 2:43 AM Matij
You're able to set the timestamp of the write in the client application.
If you have a table which is especially sensitive to out of order writes
and want to deal with the repeated second correctly, you could do slewing
at your client application layer and be explicit with the timestamp for
those s
If you happen to be using Scala, we recently released some tooling we wrote
around using CCM for integration testing:
https://github.com/protectwise/cassandra-util
You define clusters and nodes in configuration, then ask the service to go:
https://github.com/protectwise/cassandra-util/blob/master/
You would have to perform a SELECT on the row in the trigger code in order
to determine if there was underlying data. Cassandra is in essence an
append-only data store, when an INSERT or UPDATE is executed, it has no
idea if there is already a row underlying it, and for write performance
reasons i
It sounds like you're trying to avoid the latency of waiting for a write
confirmation to a remote data center?
App ==> DC1 ==high-latency==> DC2
If you need the write to be confirmed before you consider the write
successful in your application (definitely recommended unless you're ok
with losing
What is your replication factor in this DC?
On Fri, Sep 30, 2016 at 8:08 AM techpyaasa . wrote:
> Hi ,
>
> We have c*-2.0.17 with 3 data centers . Each data center has 9 nodes. vnodes
> enabled in all nodes.
>
> When I ran -local repair(./nodetool -local repair keyspace_name1
> columnfamily_1
Using keyspaces to support multi tenancy is very close to an anti pattern
unless there is a finite and reasonable upper bound to how many tenants
you'll support overall. Large numbers of tables comes with cluster overhead
and operational complexity you will come to regret eventually.
>and because
It's important to note that this answer differs quite significantly
depending on whether you're talking about Cassandra < 3.0 or >= 3.0
DataStax has a good article on < 3.0:
http://docs.datastax.com/en/cassandra/2.0/cassandra/architecture/architecturePlanningUserData_t.html
The Last Pickle has a g
I might be inclined to include a generation ID in the partition keys. Keep
a separate table where you upgrade the generation ID when your processing
is complete. You can even use CAS operations in case you goofed up and
generated two generations at the same time (or your processing time exceeds
y
to Java driver.
> I used DCAwareRoundRobin, TokenAware Policy for application flow.
> Would ask question1 on driver mailing list, If someone could help with
> question 2.
>
>
>
>
>
>
>
>
>
>
> On Fri, Sep 2, 2016 at 6:59 PM, Eric Stevens wrote:
>
>> Thes
These sound like driver-side questions that might be better addressed to
your specific driver's mailing list. But from the terminology I'd guess
you're using a DataStax driver, possibly the Java one.
If so, you can look at WhiteListPolicy if you want to target specific
node(s). However aside fro
When you say merge cells, do you mean re-aggregating the data into courser
time buckets?
On Thu, Aug 4, 2016 at 5:59 AM Michael Burman wrote:
> Hi,
>
> Considering the following example structure:
>
> CREATE TABLE data (
> metric text,
> value double,
> time timestamp,
> PRIMARY KEY((metric), ti
say nothing about iterating all cells in a single partition
> if having a partition tombstone, I need to dig further
>
>
>
>
> On Sat, Jul 30, 2016 at 2:03 AM, Eric Stevens wrote:
>
>> I haven't tested that specifically, but I haven't bumped into any
>> p
eading at all the whole partition (let's limit the example to a
> single SSTable) ?
>
> On Fri, Jul 29, 2016 at 7:00 PM, Eric Stevens wrote:
>
>> > Sai was describing a timeout, not a failure due to the 100 K tombstone
>> limit from cassandra.yaml. But I still might b
though.
>
> This still sounds very weird to me but I am glad you solved your issue
> (temporary at least).
>
> C*heers,
> ---
> Alain Rodriguez - al...@thelastpickle.com
> France
>
> The Last Pickle - Apache Cassandra Consulting
> http://www.thela
Tombstones will not get removed even after gc_grace if bloom filters
indicate that there is overlapping data with the tombstone's partition in a
different sstable. This is because compaction can't be certain that the
tombstone doesn't overlap data in that other table. If you're writing to
one end
Those ciphers are not available on Java 6, on the off chance that you're
trying to run Cassandra on that (you'll run into other troubles).
The more likely problem is that I think those ciphers are only available if
you install the Unlimited Strength JCE policy files in your JVM on each
node. Doub
If a given partition only ever contains one set of those columns, it
probably makes no practical difference, though it suggests an unintuitive
data model, so you might break it up just because it no longer seems to
make sense to keep them together.
If you really don't ever overlap your columns dur
re is a fixed memory cost per CF). Reconsider
your data model, usually this many column families suggests dynamically
creating CF's (eg to solve multi-tenancy). If your CF count will grow
steadily over time at any appreciable rate, that's an anti-pattern.
On Thu, Jun 16, 2016 at 2:40 AM V
There's an effort to improve the docs, but while that's catching up, 3.0
has the latest version of the document you're looking for:
https://cassandra.apache.org/doc/cql3/CQL-3.0.html#createKeyspaceStmt
On Wed, Jun 15, 2016 at 5:28 AM Steve Anderson
wrote:
> Couple of Cqlsh questions:
>
> 1) Why
As a side note, if you're inserting records quickly enough that you're
potentially doing multiple in the same millisecond, it seems likely to me
that your partition size is going to be too large at a day level unless
your writes are super bursty: ((appkey, pub_date), pub_timestamp). You
might need
This is better kept to the User groups.
What are your JVM memory settings for Cassandra, and have you seen big GC's
in your logs?
The reason I ask is because that's a large number of column families, which
produces memory pressure, and at first blush that strikes me as a likely
cause.
On Wed, Ju
sert on a row with a map will always
> create tombstones :-(
>
>
>
> 2016-06-02 2:02 GMT+02:00 Eric Stevens :
>
>> From that perspective, you could also use a frozen collection which takes
>> away the ability to append, but for which overwrites shouldn't gener
?
>
> On 27 May 2016 at 15:20, Eric Stevens wrote:
>
>> If you aren't removing elements from the map, you should instead be able
>> to use an UPDATE statement and append the map. It will have the same effect
>> as overwriting it, because all the new keys will take prec
Those are rough guidelines, actual effective node size is going to depend
on your read/write workload and the compaction strategy you choose. The
biggest reason data density per node usually needs to be limited is due to
data grooming overhead introduced by compaction. Data at rest essentially
be
If you aren't removing elements from the map, you should instead be able to
use an UPDATE statement and append the map. It will have the same effect as
overwriting it, because all the new keys will take precedence over the
existing keys. But it'll happen without generating a tombstone first.
If yo
use except for very
small databases.
On Tue, May 24, 2016 at 11:54 AM Justin Lin
wrote:
> so i guess i have to 1) increase the heap size or 2) reduce the number of
> keyspaces/column families.
>
> Thanks for you confirmation.
>
> On Tue, May 24, 2016 at 10:08 AM, Eric Stevens
think this also is an anti-pattern.
>
> Regards,
> Aaditya
>
> On Tue, May 24, 2016 at 12:45 PM, Mark Reddy
> wrote:
>
>> +1 to what Eric said, a queue is a classic C* anti-pattern. Something
>> like Kafka or RabbitMQ might fit your use case better.
>>
>>
>&
the version. Given that it is a single node cluster for the time
> being, would your remarks apply to that particular setup?
>
>
> Thanks again!
> Ralf
>
>
> On 24.05.2016, at 19:18, Eric Stevens wrote:
>
> I'm not familiar with Titan's usage patterns for Ca
I'm not familiar with Titan's usage patterns for Cassandra, but I wonder if
this is because of the consistency level it's querying Cassandra at - i.e.
if CL isn't LOCAL_[something], then this might just be lots of little
checksums required to satisfy consistency requirements.
On Mon, May 23, 2016
Large numbers of tables is generally recommended against. Each table has a
fixed on-heap memory overhead, and by your description it sounds like you
might have as many as 12,000 total tables when you start running into
trouble.
With such a small heap to begin with, you've probably used up most of
It sounds like you're trying to build a queue in Cassandra, which is one of
the classic anti-pattern use cases for Cassandra.
You may be able to do something clever with triggers, but I highly
recommend you look at purpose-built queuing software such as Kafka to solve
this instead.
On Tue, May 24
t;
>> host ip: 10.125.138.59
>>
>> host DC : WDC
>>
>> distance of host: LOCAL
>>
>> host is up: true
>>
>> cassandra version : 2.0.17
>>
>> host ip: 10.124.114.97
>>
>> host DC : WDC
>>
>> distance of host: LOCAL
gt; UN 10.124.114.98 165.34 GB 256 37.6%
> cdc69c7d-b9d6-4abd-9388-1cdcd35d946c RAC1
>
> UN 10.124.114.113 145.22 GB 256 35.7%
> 1557af04-e658-4751-b984-8e0cdc41376e RAC1
>
> UN 10.125.138.59 162.65 GB 256 38.6%
> 9ba1b7b6-5655-456e-b1a1-6f429750fc96
wrote:
> We have two DC one with the above 8 nodes and other with 3 nodes.
>
>
>
> On Tue, Apr 12, 2016 at 8:06 PM, Eric Stevens wrote:
>
>> Maybe include nodetool status here? Are the four nodes serving reads in
>> one DC (local to your driver's config) while the
Maybe include nodetool status here? Are the four nodes serving reads in
one DC (local to your driver's config) while the others are in another?
On Tue, Apr 12, 2016, 1:01 AM Anishek Agarwal wrote:
> hello,
>
> we have 8 nodes in one cluster and attached is the traffic patterns across
> the node
Append-only workloads are a good candidate for Date Tiered or better Time
Windowed compaction. Effectively depending on how you set it up, data in
older SStables will eventually come to rest and never be compacted again.
On Fri, Apr 8, 2016 at 7:42 AM Robert Wille wrote:
> You still need compac
if so, how?) or manually specified
> somewhere?
> * Whether local_xxx consistencies always fail when a partition is not
> replicated in the local DC, as specified in its replication strategy.
>
> Perhaps I should ask the node.js client authors about this.
>
>
> On Monday, March
IIRC in DSE 4.6 using vnodes is basically always a bad idea in your Solr
datacenter. The overhead was more than you could reasonably want to pay
unless your vnode count was low enough that you lost all the advantage.
Around 4.7 there were significant performance improvements for vnodes in
DSE Sol
> Local quorum works in the same data center as the coordinator node,
but when an app server execute the write query, how is the coordinator
node chosen?
It typically depends on the driver, and decent drivers offer you several
options for this, usually called load balancing strategy. You indicate
In addition to writing null values acting as tombstones, also INSERTing a
collection (or UPDATE where you set the collection rather than append to
it) are also operations which will create tombstones.
On Wed, Mar 23, 2016 at 12:09 PM Robert Coli wrote:
> On Wed, Mar 23, 2016 at 9:50 AM, Ralf Ste
We have been working on filtering compaction for a month or so (though we
call it deleting compaction, its implementation is as a filtering
compaction strategy). The feature is nearing completion, and we have used
it successfully in a limited production capacity against DSE 4.8 series.
Our use ca
It's definitely not true for every use case of a large number of tables,
but for many uses where you'd be tempted to do that, adding whatever would
have driven your table naming instead as a column in your partition key on
a smaller number of tables will meet your needs. This is especially true
if
There's still a race condition there, because two clients could SELECT at
the same time as each other, then both INSERT.
You'd be better served with a CAS operation, and let Paxos guarantee
at-most-once execution.
On Tue, Jan 26, 2016 at 9:06 AM Francisco Reyes wrote:
> On 01/22/2016 10:29 PM,
It seems like this exact problem pops up every few weeks on this list. I
think the documentation does a dangerously bad job of describing the
limitations of CREATE TABLE...IF NOT EXISTS.
CREATE TABLE...IF NOT EXISTS is a dangerous construct because it seems to
advertise atomicity and isolation, n
Generally speaking (both for Cassandra as well as for many other projects),
timestamps don't carry a timezone directly. A single point in time has a
consistent value for timestamp regardless of the timezone, and when you
convert a timestamp to a human-friendly value, you can attach a timezone to
s
Inconsistent reads are most often the result of inconsistent data between
nodes. Inconsistent data during tests like this is quite often the result
of having loaded data fast enough that you dropped mutations (writing even
at quorum means that you could still be dropping data on some nodes and not
> 3) check the system.schema_columns if these column_name(s) exist in the
table
> 4) If the column don't exist in the table "ALTER table tablename add new
column_name text"
Unless you have some external control on this so that you know two
processors will never attempt the same operation within a
Check nodetool status to see if the replacement node is fully joined (UN
status). If it is and it didn't stream any data, then either
auto_bootstrap was false, or the node was in its own seeds list. If you
lost a node, then replace_address as Jonny mentioned would probably be a
good idea.
On Mon
> 512G memory , 128core cpu
This seems dramatically oversized for a Cassandra node. You'd do *much* better
to have a much larger cluster of much smaller nodes.
On Thu, Nov 5, 2015 at 8:25 AM Jack Krupansky
wrote:
> I don't know what current numbers are, but last year the idea of getting 1
> m
If you're talking about logged batches, these absolutely have an impact on
performance of about 30%. The whole batch will succeed or fail as a unit,
but throughput will go down and load will go up. Keep in mind that logged
batches are atomic but are not isolated - i.e. it's totally possible to ge
If you switch reads to CL=LOCAL_ALL, you should be able to increase RF,
then run repair, and after repair is complete, go back to your old
consistency level. However, while you're operating at ALL consistency, you
have no tolerance for a node failure (but at RF=1 you already have no
tolerance for
The server is binding to the IPv4 "all addresses" reserved address
(0.0.0.0), but binding it as IPv4 over IPv6 (:::0.0.0.0), which does
not have the same meaning as the IPv6 all addresses reserved IP (being ::,
aka 0:0:0:0:0:0:0:0).
My guess is you have an IPv4 address of 0.0.0.0 in rpc_addres
In short: Yes, but it's not a good idea.
To do it, you want to look into WhiteListPolicy for your loadbalancer
policy, if your WhiteListPolicy contains only the same host(s) that you
added as contact points, then the client will only connect to those hosts.
However it's probably not a good idea f
increased as well; you
>>> may need to increase your internal node-to-node timeouts .
>>>
>>> On Mon, Nov 2, 2015 at 8:01 PM, Ajay Garg
>>> wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> I am sorry, but I don't understand.
Serial consistency gets invoked at the protocol level when doing
lightweight transactions such as CAS operations. If you're expecting that
your topology is RF=2, N=2, it seems like some keyspace has RF=3, and so
there aren't enough nodes available to satisfy serial consistency.
See
http://docs.da
It seems to me that as long as cleanup hasn't happened, if you
*decommission* the newly joined nodes, they'll stream whatever writes they
took back to the original replicas. Presumably that should be pretty quick
as they won't have nearly as much data as the original nodes (as they only
hold data
seems a little overkill for just 1 feature though. LOCAL_SERIAL is
> fine if all you want to do is keep a handful of keys up to date.
>
> There’s a massive cost in adding something new to your infrastructure, and
> imo, very little gain in this case.
>
> On Oct 15, 2015, at 8:29 A
You probably could, but if I were you, I'd consider a tool built for that
purpose, such as Zookeeper. It'd open up access to a lot of other great
cluster coordination features.
On Thu, Oct 15, 2015 at 8:47 AM Jan Algermissen
wrote:
> Hi,
>
> suppose I have two data centers and want to coordinat
If the columns are not dynamically named (as in "actionId" and "code") you
should be able to add that to your CQL table definition with ALTER TABLE,
and those columns should be available in the query results.
If the columns *are* dynamically named, and you can't reasonably add every
option to the
You cannot busy throw bigger and bigger disks at a cluster that is
accumulating data as it fills up. This is due to data grooming tasks that
increase in cost as your data density per node increases (for example,
compaction), as well as other factors that are impacted by data density
(such as cache
The DataStax Java driver is based on Netty and is non blocking; if you do
any CQL work you should look into it. At ProtectWise we use it with high
write volumes from Scala/Akka with great success.
We have a thin Scala wrapper around the Java driver that makes it act more
Scalaish (eg, Scala futur
If you're at 1 node (N=1) and RF=1 now, and you want to go N=3 RF=3, you
ought to be able to increase RF to 3 before bootstrapping your new nodes,
with no downtime and no loss of data (even temporary). Effective RF is
min-bounded by N, so temporarily having RF > N ought to behave as RF = N.
If yo
Basically your client just needs a route to talk to the IP being broadcast
by each node. We do plenty in EC2 and we use the instance private IP in
the broadcast address. If you are doing multi-datacenter in EC2 it gets a
little harrier, where you need to use the public IP (but not necessarily
ela
Can you give us an example of the duplicate records that comes back? How
reliable is it (i.e. is it every record, is it one record per read, etc)?
By any chance is it just the `data` field that duplicates while the other
fields change per row?
> I don’t see duplicates in cqlsh.
I've never seen t
Since you have most of your reads hitting 5-8 SSTables, it's probably
related to that increasing your latency. That makes this look like your
write workload is either overwrite-heavy or append-heavy. Data for a
single partition key is being written to repeatedly over long time periods,
and this w
r your cluster is the factor to focus on and however you
> get there is fantastic. more replies inline:
>
> On Sep 25, 2015, at 1:24 PM, Eric Stevens wrote:
>
> > compaction usually is the limiter for most clusters, so the difference
> between async versus unlogged batch e
tra hops, if you eliminate the
> extra hops by token awareness then it just comes down to write size
> optimization.
>
> On Sep 24, 2015, at 5:18 PM, Eric Stevens wrote:
>
> > I side-tracked some punctual benchmarks and stumbled on the
> observations of unlogged inserts be
> I side-tracked some punctual benchmarks and stumbled on the observations
of unlogged inserts being *A LOT* faster than the async counterparts.
My own testing agrees very strongly with this. When this topic came up on
this list before, there was a concern that batch coordination produces GC
pres
29, 2015 at 12:42 PM, Robert Coli wrote:
> On Wed, Apr 29, 2015 at 9:16 AM, Eric Stevens wrote:
>
>> In the end, inserting a tombstone into a non-clustered column shouldn't
>> be appreciably worse (if it is at all) than inserting a value instead. Or
>> am I missin
e to
compact than a non-tombstone?
On Wed, Apr 29, 2015 at 10:06 AM, Jonathan Haddad wrote:
> Enough tombstones can inflate the size of an SSTable causing issues during
> compaction (imagine a multi tb sstable w/ 99% tombstones) even if there's
> no clustering key defined.
>
> Pe
Correct me if I'm wrong, but tombstones are only really problematic if you
have them going into clustering keys, then perform a range select on that
column, right (assuming it's not a symptom of the antipattern of
indefinitely overwriting the same value)? I.E. you're deleting clusters
off of a par
run nodetool repair
>>>
>>> <http://docs.datastax.com/en/cassandra/1.2/cassandra/tools/toolsNodetool_r.html>.
>>>
>>>2. Wait until repair completes on a node, then move to the next node.
>>>
>>>
>>> Any other things to ta
It depends on why you're adding a new node. If you're running out of disk
space or IO capacity in your 2 node cluster, then changing RF to 3 will not
improve either condition - you'd still be writing all data to all three
nodes.
However if you're looking to improve reliability, a 2 node RF=2 clus
Is it one of your seed nodes, or does it otherwise have itself as a seed?
A node will not bootstrap if it is in its own seeds list.
On Apr 18, 2015 2:53 PM, "Bill Miller" wrote:
> I upgraded a 5 node cluster from 1.2.5 to 1.2.9, ran ugradesstables and
> installed oracle java without issues. Then
little harsh to
> write it off
>
> On Apr 3, 2015, at 1:55 PM, Robert Coli wrote:
>
> On Fri, Apr 3, 2015 at 11:16 AM, Eric Stevens wrote:
>
>> Astyanax is no longer maintained, so I don't really expect that to go
>> anywhere, which is why I thought it mig
I know this list isn't the right place to discuss driver issues in general,
but I thought I'd offer a word of warning to anyone still using Astyanax
related to an issue we ran into over the weekend.
Astyanax has a hard coded maximum Thrift frame size. There is a pull
request to expose it to confi
1 - 100 of 235 matches
Mail list logo
