adelapena commented on code in PR #1891: URL: https://github.com/apache/cassandra/pull/1891#discussion_r1210174416
########## conf/cassandra.yaml: ########## @@ -1956,3 +1956,30 @@ drop_compact_storage_enabled: false # big: # param1: value1 # ... + +# This property indicates with what Cassandra major version the storage format will be compatible with. +# +# The chosen storage compatiblity mode will determine the versions of the written sstables, commitlogs, hints, +# etc. Those storage elements will use the higher minor versions of the major version that corresponds to the +# Cassandra version we want to stay compatible with. For example, if we want to stay compatible with Cassandra 4.0 +# or 4.1, the value of this property should be 4, and that will make us use 'nc' sstables. +# +# This will also determine if certain features depending on newer formats are available. For example, extended TTLs +# up to 2106 depend on the sstable, commitlog, hints and messaging versions that were introduced by Cassandra 5.0, +# so that feature won't be available if this property is set to CASSANDRA_4. See upgrade guides for details. Currently +# the only supported major in CASSANDRA_4. +# +# Possible values are in the StorageCompatibilityMode.java file accessible online. At the time of writing these are: +# - CASSANDRA_Y: Stays compatible with the Y.x line in features, formats and component versions +# - UPGRADING: The cluster monitors nodes versions during this interim stage. _This has a cost_ but ensures any new features, +# formats, versions, etc are enabled safely. +# - NONE: Start with all the new features and formats enabled. +# +# A typical upgrade would be: +# - Do a rolling upgrade starting all nodes in CASSANDRA_Y compatibility mode. +# - Once the new binary is rendered stable do a rolling restart with UPGRADING. The cluster will enable new features in a safe way +# until all nodes are started in UPGRADING, then all new features are enabled. +# - Do a rolling restart with all nodes starting with NONE. This sheds the extra cost of checking nodes versions and ensures +# a stable cluster. If a node from a previous version was started by accident we won't any longer toggle behaviors as when UPGRADING. + Review Comment: Nit: we usually don't leave a blank line between properties and their comments. I think we should either remove the blank line or use a blank comment line (a line containing just `#`) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
