natas_hw
/
cassandra
mirror of https://github.com/apache/cassandra
0
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'cassandra-4.1' into cassandra-5.0

This commit is contained in:
Stefan Miklosovic 2024-07-15 15:39:39 +02:00
parent d85d6750f9 891e65e251
commit 10a98fe5aa
No known key found for this signature in database
GPG Key ID: 32F35CB2F546D93E
3 changed files with 18 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
conf/cassandra.yaml
View File

@ -2210,17 +2210,19 @@ drop_compact_storage_enabled: false
# feature won't be available if this property is set to CASSANDRA_4. See the upgrade guide for more details.
#
# Possible values are:
# - CASSANDRA_4: Stays compatible with the 4.x line in features, formats and component versions.
# - UPGRADING: The cluster monitors the version of each node during this interim stage. This has a cost but ensures
#
# ** CASSANDRA_4: Stays compatible with the 4.x line in features, formats and component versions.
# ** UPGRADING: The cluster monitors the version of each node during this interim stage. This has a cost but ensures
# all new features, formats, versions, etc. are enabled safely.
# - NONE: Start with all the new features and formats enabled.
# ** NONE: Start with all the new features and formats enabled.
#
# A typical upgrade would be:
# - Do a rolling upgrade, starting all nodes in CASSANDRA_X compatibility mode.
# - Once the new binary is rendered stable, do a rolling restart with the UPGRADING mode. The cluster will keep new
#
# . Do a rolling upgrade, starting all nodes in CASSANDRA_X compatibility mode.
# . Once the new binary is rendered stable, do a rolling restart with the UPGRADING mode. The cluster will keep new
# features disabled until all nodes are started in the UPGRADING mode; when that happens, new features controlled by
# the storage compatibility mode are enabled.
# - Do a rolling restart with all nodes starting with the NONE mode. This eliminates the cost of checking node versions
# . Do a rolling restart with all nodes starting with the NONE mode. This eliminates the cost of checking node versions
# and ensures stability. If Cassandra was started at the previous version by accident, a node with disabled
# compatibility mode would no longer toggle behaviors as when it was running in the UPGRADING mode.
#

14
conf/cassandra_latest.yaml
View File

@ -2178,17 +2178,19 @@ default_secondary_index_enabled: true
# feature won't be available if this property is set to CASSANDRA_4. See the upgrade guide for more details.
#
# Possible values are:
# - CASSANDRA_4: Stays compatible with the 4.x line in features, formats and component versions.
# - UPGRADING: The cluster monitors the version of each node during this interim stage. This has a cost but ensures
#
# ** CASSANDRA_4: Stays compatible with the 4.x line in features, formats and component versions.
# ** UPGRADING: The cluster monitors the version of each node during this interim stage. This has a cost but ensures
# all new features, formats, versions, etc. are enabled safely.
# - NONE: Start with all the new features and formats enabled.
# ** NONE: Start with all the new features and formats enabled.
#
# A typical upgrade would be:
# - Do a rolling upgrade, starting all nodes in CASSANDRA_X compatibility mode.
# - Once the new binary is rendered stable, do a rolling restart with the UPGRADING mode. The cluster will keep new
#
# . Do a rolling upgrade, starting all nodes in CASSANDRA_X compatibility mode.
# . Once the new binary is rendered stable, do a rolling restart with the UPGRADING mode. The cluster will keep new
# features disabled until all nodes are started in the UPGRADING mode; when that happens, new features controlled by
# the storage compatibility mode are enabled.
# - Do a rolling restart with all nodes starting with the NONE mode. This eliminates the cost of checking node versions
# . Do a rolling restart with all nodes starting with the NONE mode. This eliminates the cost of checking node versions
# and ensures stability. If Cassandra was started at the previous version by accident, a node with disabled
# compatibility mode would no longer toggle behaviors as when it was running in the UPGRADING mode.
#

3
doc/scripts/convert_yaml_to_adoc.py
View File

@ -50,7 +50,8 @@ COMPLEX_OPTIONS = (
'server_encryption_options',
'client_encryption_options',
'transparent_data_encryption_options',
'hinted_handoff_disabled_datacenters'
'hinted_handoff_disabled_datacenters',
'startup_checks'
)
def convert(yaml_file, dest_file):