[
https://issues.apache.org/jira/browse/CASSANDRA-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976706#comment-13976706
]
Benedict commented on CASSANDRA-7031:
-------------------------------------
bq. Since one point of restore is, "I don't have the CL directory anymore" this
is kind of a non-solution.
But this is always a risk for any users - to eliminate that risk is impossible,
so they have to be able to cope with some degree of loss in this event, and
that's hardly unreasonable since we're talking about whole cluster failure of
commit and data disks for this to be a real pain point. We provide guarantees
against this problem through RF and more nodes, generally. Restore is more
useful for people who want to roll back their own mistakes, or bring a cluster
back from death, and if you've had that level of issue, losing out on the past
100Mb of writes is no worse than missing out on the past 25Mb.
bq. So now we're forcing users to add a cron job for PITR to work? I don't like
that idea either.
We're saying: if you need PITR for something within the most recent CL then you
need to run this. It's probably a very tiny number of users - I'm not sure it's
any at all. Most users want to be able to PITR to some safe point, not to some
point within the past 2 seconds or so. If they wanted that they'd be screwed by
delayed mutations anyway, so it's kind of moot.
> Increase default commit log total space + segment size
> ------------------------------------------------------
>
> Key: CASSANDRA-7031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7031
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Priority: Trivial
> Fix For: 2.1 beta2
>
> Attachments: 7031.txt
>
>
> I would like to increase the default commit log total space and segment size
> options for 64-bit JVMs:
> The current default of 1Gb and 32Mb is quite constrained and can have some
> (very minor) negative performance implications, for no major benefit:
> # 32Mb files are actually quite small, and if during the 10s interval we have
> completely filled multiple of them (quite easy) it would be more efficient to
> write fewer larger files, as we can issue fewer fsyncs and permit the OS to
> schedule the writes more efficiently. On my box this has a small but
> noticeable impact. Although I would expect on decent server hardware this
> would be smaller still, since we immediately drop the pages from cache on
> writing there isn't a great deal of advantage to keeping the files so small.
> The only advantage I can see is that during a drop KS/CF or other event that
> forces log rollover we're wasting less space until log recycling. 128-256Mb
> are modest increases that seem more appropriate to me.
> # 1Gb is too small for the default total log space. We can find that we force
> memtable flushes as a result of log utilisation instead of memtable occupancy
> quite often (esp. as a result of increased effective memtable space from
> recent improvements), especially on machines with more addressable memory. I
> suggest 8Gb as a minimum. The only disadvantage of having more log data is
> that replay on restart may be slightly slower, but since most of the events
> will be ignored it should be relatively benign, and I would rather take the
> penalty on startup instead of during running, no matter how small the running
> penalty.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
