Merge branch 'cloud-2.0' into configurable-managed-backups-2.0

src/current/_data/releases.yml

@@ -6672,10 +6672,57 @@
     docker_arm_limited_access: false
   source: true
   previous_release: v23.1.25
-  cloud_only: true
-  cloud_only_message_short: 'Available only for select CockroachDB Cloud clusters'
-  cloud_only_message: >
-    This version is currently available only for select
-    CockroachDB Cloud clusters. To request to upgrade
-    a CockroachDB self-hosted cluster to this version,
-    [contact support](https://support.cockroachlabs.com/hc/requests/new).
+
+- release_name: v23.2.11
+  major_version: v23.2
+  release_date: '2024-09-16'
+  release_type: Production
+  go_version: go1.22.5
+  sha: bb17c9628b6b830a43ad1f8f25ee19342a4217d8
+  has_sql_only: true
+  has_sha256sum: true
+  mac:
+    mac_arm: true
+    mac_arm_experimental: true
+    mac_arm_limited_access: false
+  windows: true
+  linux:
+    linux_arm: true
+    linux_arm_experimental: false
+    linux_arm_limited_access: false
+    linux_intel_fips: true
+    linux_arm_fips: false
+  docker:
+    docker_image: cockroachdb/cockroach
+    docker_arm: true
+    docker_arm_experimental: false
+    docker_arm_limited_access: false
+  source: true
+  previous_release: v23.2.10
+
+- release_name: v24.2.2
+  major_version: v24.2
+  release_date: '2024-09-23'
+  release_type: Production
+  go_version: go1.22.5
+  sha: 8fb18e7ae08fdd481b959f74330e273a2500e1df
+  has_sql_only: true
+  has_sha256sum: true
+  mac:
+    mac_arm: true
+    mac_arm_experimental: true
+    mac_arm_limited_access: false
+  windows: true
+  linux:
+    linux_arm: true
+    linux_arm_experimental: false
+    linux_arm_limited_access: false
+    linux_intel_fips: true
+    linux_arm_fips: false
+  docker:
+    docker_image: cockroachdb/cockroach
+    docker_arm: true
+    docker_arm_experimental: false
+    docker_arm_limited_access: false
+  source: true
+  previous_release: v24.2.1

src/current/_includes/common/aws-privatelink-basic.md

@@ -0,0 +1 @@
+AWS PrivateLink is not available on CockroachDB {{ site.data.products.basic }}. For {{ site.data.products.basic }} clusters that were migrated from CockroachDB Serverless, existing [PrivateLink connections]({% link cockroachcloud/aws-privatelink.md %}) continue to work, but new PrivateLink connections cannot be added.

src/current/_includes/releases/v23.2/v23.2.11.md

@@ -0,0 +1,13 @@
+## v23.2.11
+
+Release Date: September 16, 2024
+
+{% include releases/new-release-downloads-docker-image.md release=include.release %}
+<h3 id="v23-2-11-bug-fixes">Bug fixes</h3>
+
+- Internally issued queries that are not initiated within a [SQL session]({% link v23.2/show-sessions.md %}) no longer respect a [statement timeout]({% link v23.2/session-variables.md %}#statement-timeout). This includes: background [jobs]({% link v23.2/show-jobs.md %}), queries issued by the [DB Console]({% link v23.2/ui-overview.md %}) that perform introspection, and the [Cloud SQL shell]({% link cockroachcloud/sql-shell.md %}). [#130525][#130525]
+- Fixed a rare bug where a [lease transfer]({% link v23.2/architecture/replication-layer.md %}#leases) could lead to a `side-transport update saw closed timestamp regression` panic. The bug could occur when a node was [overloaded]({% link v23.2/ui-overload-dashboard.md %}) and failing to heartbeat its [node liveness]({% link v23.2/cluster-setup-troubleshooting.md %}#node-liveness-issues) record. [#130523][#130523]
+- Resolved a concerning [log]({% link v23.2/logging-overview.md %}) message: `expiration of liveness record ... is not greater than expiration of the previous lease ... after liveness heartbeat`. This message is no longer possible. [#130523][#130523]
+
+[#130523]: https://github.com/cockroachdb/cockroach/pull/130523
+[#130525]: https://github.com/cockroachdb/cockroach/pull/130525

src/current/_includes/releases/v24.2/v24.2.2.md

@@ -0,0 +1,19 @@
+## v24.2.2
+
+Release Date: September 23, 2024
+
+{% include releases/new-release-downloads-docker-image.md release=include.release %}
+
+<h3 id="v24-2-2-bug-fixes">Bug fixes</h3>
+
+- Fixed a bug that could result in the inability to garbage collect an [MVCC]({% link v24.2/architecture/storage-layer.md %}#mvcc) range tombstone within a [global table]({% link v24.2/table-localities.md %}#global-tables). [#130946][#130946]
+
+<div class="release-note-contributors" markdown="1">
+
+<h3 id="v24-2-2-contributors">Contributors</h3>
+
+This release includes 3 merged PRs by 2 authors.
+
+</div>
+
+[#130946]: https://github.com/cockroachdb/cockroach/pull/130946

src/current/_includes/v23.1/performance/reduce-hot-spots.md

@@ -2,17 +2,23 @@
 
 - Place parts of the records that are modified by different transactions in different tables. That is, increase [normalization](https://wikipedia.org/wiki/Database_normalization). However, there are benefits and drawbacks to increasing normalization.
 
-    - Benefits:
+    - Benefits of increasing normalization:
 
+        - Can improve performance for write-heavy workloads. This is because, with increased normalization, a given business fact must be written to one place rather than to multiple places.  
         - Allows separate transactions to modify related underlying data without causing [contention](#transaction-contention).
-        - Can improve performance for read-heavy workloads.
+        - Reduces the chance of data inconsistency, since a given business fact must be written only to one place.
+        - Reduces or eliminates data redundancy.
+        - Uses less disk space.
 
-    - Drawbacks:
+    - Drawbacks of increasing normalization:
 
+        - Can reduce performance for read-heavy workloads. This is because increasing normalization results in more joins, and can make the SQL more complicated in other ways.
         - More complex data model.
-        - Increases the chance of data inconsistency.
-        - Increases data redundancy.
-        - Can degrade performance for write-heavy workloads.
+
+    - In general:
+
+        - Increase normalization for write-intensive and read/write-intensive transactional workloads.
+        - Do not increase normalization for read-intensive reporting workloads.
 
 - If the application strictly requires operating on very few different index keys, consider using [`ALTER ... SPLIT AT`]({% link {{ page.version.version }}/alter-table.md %}#split-at) so that each index key can be served by a separate group of nodes in the cluster.
 

src/current/_includes/v23.2/performance/reduce-hot-spots.md

@@ -2,17 +2,23 @@
 
 - Place parts of the records that are modified by different transactions in different tables. That is, increase [normalization](https://wikipedia.org/wiki/Database_normalization). However, there are benefits and drawbacks to increasing normalization.
 
-    - Benefits:
+    - Benefits of increasing normalization:
 
+        - Can improve performance for write-heavy workloads. This is because, with increased normalization, a given business fact must be written to one place rather than to multiple places.  
         - Allows separate transactions to modify related underlying data without causing [contention](#transaction-contention).
-        - Can improve performance for read-heavy workloads.
+        - Reduces the chance of data inconsistency, since a given business fact must be written only to one place.
+        - Reduces or eliminates data redundancy.
+        - Uses less disk space.
 
-    - Drawbacks:
+    - Drawbacks of increasing normalization:
 
+        - Can reduce performance for read-heavy workloads. This is because increasing normalization results in more joins, and can make the SQL more complicated in other ways.
         - More complex data model.
-        - Increases the chance of data inconsistency.
-        - Increases data redundancy.
-        - Can degrade performance for write-heavy workloads.
+
+    - In general:
+
+        - Increase normalization for write-intensive and read/write-intensive transactional workloads.
+        - Do not increase normalization for read-intensive reporting workloads.
 
 - If the application strictly requires operating on very few different index keys, consider using [`ALTER ... SPLIT AT`]({% link {{ page.version.version }}/alter-table.md %}#split-at) so that each index key can be served by a separate group of nodes in the cluster.