Hi Josh,
I too have had this issue on several clusters I manage, particularly when
making schema changes. The worst part is, those nodes don't restart, and
the tables can't be dropped. Basically you have to rebuild your whole
cluster which often takes down time. Others have seen this on 3.0.x and i
For counter tables, non-counter types are of course allowed in the primary
key. Counters would be meaningless otherwise.
Thanks,
Cody
On Nov 1, 2016 7:00 AM, "Ali Akhtar" wrote:
> In the documentation for counters:
>
> https://docs.datastax.com/en/cql/3.1/cql/cql_using/use_counter_t.html
>
> Th
s to a counter and run the create table
> query, I get the error ' Cannot mix counter and non counter columns in
> the same table'
>
>
> On Tue, Nov 1, 2016 at 6:11 PM, Cody Yancey wrote:
>
>> For counter tables, non-counter types are of course allowed in the
&g
ue.
>
> For example:
>
> create column family stuff (
> rowkey string,
> column string,
> value string.
> counter_to_ignore long,
> primary key( rowkey, column, value));
>
>
>
> On Tue, Nov 1, 2016 at 9:29 AM, Ali Akhtar wrote:
>
>> That's a terrible
It is not possible. Internally Cassandra flattens your data out into a set
of key-value-pairs. All collection types, including lists, are nothing more
than a thin layer of schema over a clustered set of key-value-pairs, so on
disk there is no difference between an empty list and a list that doesn't
It is not possible. Internally Cassandra flattens your data out into a set
of key-value-pairs. All collection types, including lists, are nothing more
than a thin layer of schema over a clustered set of key-value-pairs, so on
disk there is no difference between an empty list and a list that doesn't
Getting the same TimeUUID values might be a major problem. Getting two
different TimeUUIDs that at least have time component would not be a major
problem as this is the main case today. Getting different time components
is actually the corner case, and it is a corner case that breaks
Internet-of-Th
NLY practice is to set the value before initiating the
> sequence of calls.
>
>
>
> *...*
>
>
>
> *Daemeon C.M. ReiydelleUSA (+1) 415.501.0198 <(415)%20501-0198>London
> (+44) (0) 20 8144 9872 <+44%2020%208144%209872>*
>
> On Wed, Nov 30, 2016 at 6:
On Thu, Dec 1, 2016 at 11:09 AM Sylvain Lebresne
wrote:
> there is much much more trivial solution: generate it client side. The
> `now()` function is a small convenience but there is nothing you cannot do
> without it client side
>
Please see my post above as to why this is a bad idea for inser
Hi Voytek,
I think the way you are using it is definitely the canonical way.
Unfortunately, as you learned, there are some gotchas. We tried
substantially increasing the batch size and it worked for a while, until we
reached new scale, and we increased it again, and so forth. It works, but
soon you
experience such that "batches over XXkb are definitely
> going to be a problem".
>
> Appreciate everyone's time.
> --Voytek Jarnot
>
> On Wed, Dec 7, 2016 at 11:31 AM, Cody Yancey wrote:
>
>> Hi Voytek,
>> I think the way you are using it is definitely
>> Cassandra stores hints for the lowest of gc_grace_seconds and
max_hint_window_in_ms
Was this a tough design decision or just a bug? It is certainly very
surprising behavior. Everything that I've read leads me to believe that
gc_grace_seconds was only intended to affect the treatment of *expired
12 matches
Mail list logo
