[
https://issues.apache.org/jira/browse/CASSANDRA-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14350577#comment-14350577
]
Benedict commented on CASSANDRA-7075:
-------------------------------------
It's also worth considering if we shouldn't simply round-robin on segment
advance, rather than on each mutation. If we wanted to improve the performance
of batch commit log latency we could round-robin on sync also (so the next
batch may potentially start committing before the prior batch has completed).
Since this is going into 3.0, and we're hoping for CASSANDRA-6696 to land then
also, it might alternatively make sense to tie the two together, and write CL
entries to the disk that will ultimately own the sstables also. This might
simplify the cognitive burden on recovery from a disk failure, since there
would be no risk of partial updates being played for an owned range and queries
being served from it. So no consideration would need to be given to these
partial failure scenarios.
> Add the ability to automatically distribute your commitlogs across all data
> volumes
> -----------------------------------------------------------------------------------
>
> Key: CASSANDRA-7075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7075
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Tupshin Harper
> Assignee: Branimir Lambov
> Priority: Minor
> Labels: performance
> Fix For: 3.0
>
>
> given the prevalance of ssds (no need to separate commitlog and data), and
> improved jbod support, along with CASSANDRA-3578, it seems like we should
> have an option to have one commitlog per data volume, to even the load. i've
> been seeing more and more cases where there isn't an obvious "extra" volume
> to put the commitlog on, and sticking it on only one of the jbodded ssd
> volumes leads to IO imbalance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
