[ 
https://issues.apache.org/jira/browse/CASSANDRA-16253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alain RODRIGUEZ updated CASSANDRA-16253:
----------------------------------------
    Description: 
About the documentation on commit logs:
 * Commit logs default is every 10 sec - *periodic*, not batch 
[https://github.com/apache/cassandra/blob/cassandra-3.11.8/conf/cassandra.yaml#L385-L386]
 (same in 3.11.9 or trunk). It can lead to data losses but still makes sense to 
me because fsync-ing every write is very expensive, and (even in batches) 
should be reserved for the super paranoid where handling multiple power-out (or 
sudden disk failures) simultaneously on multiple nodes needs to be handled (as 
[~mck] explained to me.

  * Nonetheless, apart from the theory behind it, in a more practical 
perspective, *the doc is wrong* and says *Default Value: batch* which mislead 
me and this could happen to more people: 
[https://cassandra.apache.org/doc/latest/architecture/storage_engine.html#commit-log]

 

I think this is important enough for us to quickly fix the documentation in 
trunk. As this information is fully missing in the 3.11 branch documentation, I 
suggest we add it as well on that branch (based on information about commit 
logs from trunk).

  was:
About the documentation on commit logs:
 * Commit logs default is every 10 sec (periodic), not batch 
[https://github.com/apache/cassandra/blob/cassandra-3.11.8/conf/cassandra.yaml#L385-L386]
 (same in 3.11.9 or trunk). It can lead to data losses but still makes sense to 
me because fsync-ing every write is very expensive, and (even in batches) 
should be reserved for the super paranoid where handling multiple power-out (or 
sudden disk failures) simultaneously on multiple nodes needs to be handled (as 
[~mck] explained to me.

  * Nonetheless, apart from the theory behind it, in a more practical 
perspective, *the doc is wrong* and says default is `_Default Value:_ batch` 
which mislead me and this could happen to more people: 
[https://cassandra.apache.org/doc/latest/architecture/storage_engine.html#commit-log]

 

I think this is important enough for us to quickly fix the documentation in 
trunk. As this information is fully missing in the 3.11 branch documentation, I 
suggest we add it as well on that branch (based on information about commit 
logs from trunk).


> Fix documentation to reflect real defaults for commit logs
> ----------------------------------------------------------
>
>                 Key: CASSANDRA-16253
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16253
>             Project: Cassandra
>          Issue Type: Task
>            Reporter: Alain RODRIGUEZ
>            Assignee: Alain RODRIGUEZ
>            Priority: Normal
>
> About the documentation on commit logs:
>  * Commit logs default is every 10 sec - *periodic*, not batch 
> [https://github.com/apache/cassandra/blob/cassandra-3.11.8/conf/cassandra.yaml#L385-L386]
>  (same in 3.11.9 or trunk). It can lead to data losses but still makes sense 
> to me because fsync-ing every write is very expensive, and (even in batches) 
> should be reserved for the super paranoid where handling multiple power-out 
> (or sudden disk failures) simultaneously on multiple nodes needs to be 
> handled (as [~mck] explained to me.
>   * Nonetheless, apart from the theory behind it, in a more practical 
> perspective, *the doc is wrong* and says *Default Value: batch* which mislead 
> me and this could happen to more people: 
> [https://cassandra.apache.org/doc/latest/architecture/storage_engine.html#commit-log]
>  
> I think this is important enough for us to quickly fix the documentation in 
> trunk. As this information is fully missing in the 3.11 branch documentation, 
> I suggest we add it as well on that branch (based on information about commit 
> logs from trunk).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to