This problem is not new to 1.1.
On Sep 6, 2012 5:51 AM, "Radim Kolar" wrote:
> i would migrate to 1.0 because 1.1 is highly unstable.
>
Thanks Tomek,
Feel free to add it to
http://wiki.apache.org/cassandra/Administration%20Tools
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On 5/09/2012, at 9:54 AM, Tomek Kuprowski wrote:
> Dear all,
>
> I'm happy to announce a
> Is there a specific metric you can recommend?
the not entirely correct but very lightweight approach would be to look at the
size of the HintsColumnFamily in the system KS.
If you want an exact number use the functions on the HH MBean
https://github.com/apache/cassandra/blob/trunk/src/java/
> 1. When a write request is received, it is written to the base CF and
> secondary index to secondary (hidden) CF. If this right, will the secondary
> index be written local the node or will it follow RP/OPP to write to nodes.
it's local.
If an index is to be updated the previous column values
The hit rate is pretty low
> 0.451 recent hit rate,
A bigger cache would not help too much.
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On 5/09/2012, at 11:31 PM, Ananth Gundabattula
wrote:
> Hello Aaron,
>
> Thanks a lot for the r
This is a problem…
> [default@system] list NodeIdInfo ;
> Using default limit of 100
> ...
> ---
> RowKey: 43757272656e744c6f63616c
> => (column=01efa5d0-e133-11e1--51be601cd0ff, value=0a1020d2,
> timestamp=1344414498989)
> => (column=92109b80-ea0a-11e1--51be601cd0af, valu
Sorry but you will need to provide details of a specific query or workload that
goes slower in 1.0.11.
As I said tests have shown improvements in performance in every new release. If
you are seeing a significant decrease in performance it may be a workload that
has not being considered or a kno
This is actually another problem that we've encountered with Cassandra; the
range of platforms it can be deployed on is fairly limited. If you want to run
with Oracle's JRE (which is apparently recommended), you are pretty much stuck
with Linux on x86/64 (I haven't tried the new JDK on ARM yet,
To minimize the impact on the cluster, I would bootstrap a new 1d node at
(42535295865117307932921825928971026432 - 100), then decommission the 1c
node at 42535295865117307932921825928971026432 and run cleanup on your
us-east nodes.
On Thu, Sep 6, 2012 at 1:11 PM, William Oberman wrote:
> Didn't
Didn't notice the racks! Of course
If I change a 1c to a 1d, what would I have to do to make sure data
shuffles around correctly? Repair everywhere?
will
On Thu, Sep 6, 2012 at 2:09 PM, Tyler Hobbs wrote:
> The main issue is that one of your us-east nodes is in rack 1d, while the
> resta
The main issue is that one of your us-east nodes is in rack 1d, while the
restart are in rack 1c. With NTS and multiple racks, Cassandra will try
use one node from each rack as a replica for a range until it either meets
the RF for the DC, or runs out of racks, in which case it just picks nodes
se
Hi,
I recently upgraded from 0.8.x to 1.1.x (through 1.0 briefly) and nodetool
-ring seems to have changed from "owns" to "effectively owns".
"Effectively owns" seems to account for replication factor (RF). I'm ok
with all of this, yet I still can't figure out what's up with my cluster.
I have
Hi,
If there is only one DC, can we still use EACH_QUORUM for write? We only
have one DC now, but will build another one in future and like to use
EACH_QUORUM when there are two. But like to know if it's good to use
EACH_QUORUM with the current 1 DC.
And if there are two DCs but in some cases one
A little clarification. When I talk about exclusive bounds, I mean:
"compareTo(ZERO) <= 0" or "compareTo(MAXIMUM) >= 0"
> I meant that what the OP spotted was it's an inclusive maximum <=
That's it Tim, you understood what I meant. Thank you for taking the time
to consider my question.
0 <= hash < (2**127) corresponds to the cyclic group Z/(2**127) so the
maximum is (2**127)-1
So there is indeed a mix up in sourc
Someone asked so I wrote the difference here
https://github.com/deanhiller/playorm/wiki/Fast-Scalable-Queries
playOrm queries are geared for a different problem then CQL is geared for.
Summary is basically playOrm uses significantly less resources as it only
queries the partitions it is interes
I'm down--we had a good mini-meetup last year at lunch. How about trying
to get something together on Wed or Thurs night?
On Wed, Sep 5, 2012 at 5:46 PM, Chris Burroughs
wrote:
> Surge [1] is scalability focused conference in late September hosted in
> Baltimore. It's a pretty cool conference w
i would migrate to 1.0 because 1.1 is highly unstable.
Hi nobody knows about this ?
Alain
2012/9/3 Alain RODRIGUEZ
> Hello,
>
> I'm running a 1.1.2 Cassandra 2 nodes wide cluster with RF=2 (CL = 1,
> nodes are m1.large from Amazon).
>
> I had this error 524 times last month on the node 1 and 2805 time on
> the second node.
>
> Should I worry about
19 matches
Mail list logo
