You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Partitions of topics enabled for remote storage now follow the topic's retention policy specified via retention.bytes and retention.ms. If those are unspecified, cluster level defaults are used. The migration of existing topics is done in such a way that they preserve the previous behavior (i.e. data will not be deleted from cloud storage for topics created before v22.3). However, note that for new topics retention is applied and data can be expired from cloud storage automatically. by @VladLazar in cloud_storage: implement retention.ms/bytes for remote data #6833
Introduce retention.local-target.ms and retention.local-target.bytes topic configuration options. They control the retention policy of each partition within the topic and are only relevant for topics with remote write enabled. by @VladLazar in Add local-target topic configuration options for SI topics #6613
Users are no longer required to supply a node ID in each node's node configuration file. All nodes must be upgraded before using this feature. Node IDs on existing nodes will be preserved when using this. by @andrwng in cluster: support automatically assigning a node ID #6659
redpanda: cluster will not form without a node with an empty seed server list #333 Seed driven cluster bootstrap mode. Disable empty_seed_starts_cluster to use it. That will allow the set of servers listed as seeds to start a cluster together without a root node. All seed servers must be available for a cluster to be created, with identical node configuration. Afterwards, none of the seed servers will try to form another new cluster if their local storage is wiped out, unless all seed nodes are wiped together at the same time. Cluster now gets a cluster UUID reflected by a new controller log message, and stored in kvstore. by @dlex in Seeds Driven Cluster Bootstrap #6744
Tunable cluster configuration properties are added to set bounds on the segment.bytes topic property. If log_segment_size_min and/or log_segment_size_max are set, then any segment.bytes outside these bounds will be silently clamped to the permitted range. This prevents poorly-chosen configurations from inducing the cluster to create very large numbers of small segment files, or extremely large segment files. by @jcsp in storage: apply limits to segment.bytes #6492
rpk topic produce now has --allow-auto-topic-creation, which can create non-existent topics if the cluster has auto_create_topics_enabled set to true by @twmb in rpk: three small fixes #7197
Internal topics are created with an appropriate replication factor more reliably on clusters with at least 3 nodes, whereas previously in some circumstances they could exist in a single-replica state for a period of time before being upgraded to a replicated state. by @jcsp in cluster, schema_registry: improve handling of internal topic replication factors #6299
The properties cloud_storage_enable_remote_[read|write] are now applied to topics at creation time, and if they subsequently change, then existing topics' properties do not change. To modify the tiered storage mode of existing topics, you may set the redpanda.remote.[read|write] properties on the topic. by @jcsp in cloud_storage: make cluster default read/write properties "sticky" #6950
A new cluster configuration property cloud_storage_max_segments_per_shard is added, which controls the maximum number of segments per CPU core that may be promoted into a readable state from cloud storage. This may be tuned downward to reduce memory consumption at the possible cost of read throughput. The default setting is two per partition (i.e. the value of topic_partitions_per_shard multiplied by 2 is used). by @jcsp in cloud_storage: limit on hydrated segments per shard #7082
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Features
Bug Fixes
std::errc::broken_pipe
#6687AvailabilityTests.test_availability_when_one_node_failed
#6508 Returning retryable kafka error code in raft replication failure events that require the client to retry by @graphcareful in Remapraft::errc::replicated_entry_truncated
error code to a retry-able kafka one #6712write_truncate_compact
#6063 Fix a need for retrying truncation of compacted topic partition when it failed by @mmaslankaprv in Fixed truncation during adjacent segments compaction #6071Improvements
kube2iam
#7030ShadowIndexingWhileBusyTest.test_create_or_delete_topics_while_busy
with 10 readers, 1 writer, 1GB ram per core) #6111 Limit file handles used via remote_segments open #6023 Improved stability under random read workloads to tiered storage topics. by @jcsp in cloud_storage: limit reader concurrency to avoid bad_allocs under random read loads #7042ShadowIndexingWhileBusyTest.test_create_or_delete_topics_while_busy
with 10 readers, 1 writer, 1GB ram per core) #6111 Limit file handles used via remote_segments open #6023 A new cluster configuration property cloud_storage_max_readers_per_shard is added, which controls the maximum number of cloud storage reader objects that may exist per CPU core: this may be tuned downward to reduce memory consumption at the possible cost of read throughput. The default setting of one per partition (i.e. the value of topic_partitions_per_shard is used). by @jcsp in cloud_storage: limit reader concurrency to avoid bad_allocs under random read loads #7042ConsumerOffsetsMigrationTest
test_migrating_consume_offsets
failures=True.cpus=3
#5324 Recover from failures quickly by cleaning up resources. by @bharathv in rpc/transport: Release resource units right after dispatching send #5730Full Changelog: v22.2.7...v22.3.1
This discussion was created from the release v22.3.1.
Beta Was this translation helpful? Give feedback.
All reactions