Hi Charulata,
IMO, 64MB is fine unless you archive commit log or scan it for backup.
Zhao
Charulata Sharma (charshar) 于2017年4月28日周五 上午8:01写道:
> Hi ,
>
> Can anyone please tell me the implication of increasing the
> commitlog_segment_size_in_mb
> from the default value of 32 MB to a higher
Hi ,
Can anyone please tell me the implication of increasing the
commitlog_segment_size_in_mb from the default value of 32 MB to a higher value?
Some of our mutations are > 16MB, so the writes are failing. This is because of
the way we store data in our Column families. 95% of the data is <
I'm looking into a case where it appears that recycling a commit log segment
and flushing the dirty CF's results in 46 CF's being flushed. Out of 47 in the
keyspace. All this flush activity blocks writes.
Before I dig further I wanted to confirm my understanding.
At 10:46 the MeteredFlusher ki
> I have one question about the 'commit log' in Cassandra, so imagine
> we issue a write with QUORUM, if the write was successful then we are
> sure that N/2 +1 replicas have the new data. If one of these replicas
> fail, no state is lost because the state is also available from
> another machin
Hello,
I have one question about the 'commit log' in Cassandra, so imagine
we issue a write with QUORUM, if the write was successful then we are
sure that N/2 +1 replicas have the new data. If one of these replicas
fail, no state is lost because the state is also available from
another machine i