diff --git a/src/current/_includes/v25.2/backups/locality-aware-multi-tenant.md b/src/current/_includes/v25.2/backups/locality-aware-multi-tenant.md index 896d29db2d6..dfa68c855e8 100644 --- a/src/current/_includes/v25.2/backups/locality-aware-multi-tenant.md +++ b/src/current/_includes/v25.2/backups/locality-aware-multi-tenant.md @@ -1 +1 @@ -Both CockroachDB {{ site.data.products.standard }} and CockroachDB {{ site.data.products.basic }} clusters operate with a different architecture compared to CockroachDB {{ site.data.products.core }}. These architectural differences have implications for how locality-aware backups can run. {{ site.data.products.standard }} and {{ site.data.products.basic }} clusters will scale resources depending on whether they are actively in use. This makes it less likely to have a SQL pod available in every locality. As a result, your Serverless cluster may not have a SQL pod in the locality where the data resides, which can lead to the cluster uploading that data to a storage bucket in a locality where you do have active SQL pods. You should consider this as you plan a backup strategy that must comply with [data domiciling]({% link v23.2/data-domiciling.md %}) requirements. +Both CockroachDB {{ site.data.products.standard }} and CockroachDB {{ site.data.products.basic }} clusters operate with a different architecture compared to CockroachDB {{ site.data.products.core }}. These architectural differences have implications for how locality-aware backups can run. {{ site.data.products.standard }} and {{ site.data.products.basic }} clusters will scale resources depending on whether they are actively in use. This makes it less likely to have a SQL pod available in every locality. As a result, your Serverless cluster may not have a SQL pod in the locality where the data resides, which can lead to the cluster uploading that data to a storage bucket in a locality where you do have active SQL pods. You should consider this as you plan a backup strategy that must comply with [data domiciling]({% link {{ page.version.version }}/data-domiciling.md %}) requirements. diff --git a/src/current/_includes/v25.2/backward-incompatible/alpha.1.md b/src/current/_includes/v25.2/backward-incompatible/alpha.1.md index dff3b4ea3c5..8d4004422ad 100644 --- a/src/current/_includes/v25.2/backward-incompatible/alpha.1.md +++ b/src/current/_includes/v25.2/backward-incompatible/alpha.1.md @@ -1,15 +1,15 @@ - CockroachDB no longer performs environment variable expansion in the parameter `--certs-dir`. Uses like `--certs-dir='$HOME/path'` (expansion by CockroachDB) can be replaced by `--certs-dir="$HOME/path"` (expansion by the Unix shell). [#81298][#81298] -- In the Cockroach CLI, [`BOOL` values](../v23.1/bool.html) are now formatted as `t` or `f` instead of `True` or `False`. [#81943][#81943] -- Removed the `cockroach quit` command. It has been deprecated since v20.1. To [shut down a node](../v23.1/node-shutdown.html) gracefully, send a `SIGTERM` signal to it. [#82988][#82988] -- Added a cluster version to allow the [Pebble storage engine](../v23.1/architecture/storage-layer.html#pebble) to recombine certain SSTables (specifically, user keys that are split across multiple files in a level of the [log-structured merge-tree](../v23.1/architecture/storage-layer.html#log-structured-merge-trees)). Recombining the split user keys is required for supporting the range keys feature. The migration to recombine the SSTables is expected to be short (split user keys are rare in practice), but will block subsequent migrations until all tables have been recombined. The `storage.marked-for-compaction-files` time series metric can show the progress of the migration. [#84887][#84887] +- In the Cockroach CLI, [`BOOL` values]({% link {{ page.version.version }}/bool.md %}) are now formatted as `t` or `f` instead of `True` or `False`. [#81943][#81943] +- Removed the `cockroach quit` command. It has been deprecated since v20.1. To [shut down a node]({% link {{ page.version.version }}/node-shutdown.md %}) gracefully, send a `SIGTERM` signal to it. [#82988][#82988] +- Added a cluster version to allow the [Pebble storage engine]({% link {{ page.version.version }}/architecture/storage-layer.md#pebble %}) to recombine certain SSTables (specifically, user keys that are split across multiple files in a level of the [log-structured merge-tree]({% link {{ page.version.version }}/architecture/storage-layer.md#log-structured-merge-trees %})). Recombining the split user keys is required for supporting the range keys feature. The migration to recombine the SSTables is expected to be short (split user keys are rare in practice), but will block subsequent migrations until all tables have been recombined. The `storage.marked-for-compaction-files` time series metric can show the progress of the migration. [#84887][#84887] - Using a single TCP port listener for both RPC (node-node) and SQL client connections is now deprecated. This capability **will be removed** in the next version of CockroachDB. Instead, make one of the following configuration changes to your CockroachDB deployment: - Preferred: keep port `26257` for SQL, and allocate a new port, e.g., `26357`, for node-node RPC connections. For example, you might configure a node with the flags `--listen-addr=:26357 --sql-addr=:26257`, where subsequent nodes seeking to join would then use the flag `--join=othernode:26357,othernode:26257`. This will become the default configuration in the next version of CockroachDB. When using this mode of operation, care should be taken to use a `--join` flag that includes both the previous and new port numbers for other nodes, so that no network partition occurs during the upgrade. - Optional: keep port `26257` for RPC, and allocate a new port, e.g., `26357`, for SQL connections. For example, you might configure a node with the flags `--listen-addr=:26257 --sql-addr=:26357`. When using this mode of operation, the `--join` flags do not need to be modified. However, SQL client apps or the SQL load balancer configuration (when in use) must be updated to use the new SQL port number. [#85671][#85671] -- If no `nullif` option is specified while using [`IMPORT CSV`](../v23.1/import.html), then a zero-length string in the input is now treated as `NULL`. The quoted empty string in the input is treated as an empty string. Similarly, if `nullif` is specified, then an unquoted value is treated as `NULL`, and a quoted value is treated as that string. These changes were made to make `IMPORT CSV` behave more similarly to `COPY CSV`. If the previous behavior (i.e., treating either quoted or unquoted values that match the `nullif` setting as `NULL`) is desired, you can use the new `allow_quoted_null` option in the `IMPORT` statement. [#84487][#84487] -- [`COPY FROM`](../v23.1/copy.html) operations are now atomic by default instead of being segmented into 100 row transactions. Set the `copy_from_atomic_enabled` session setting to `false` for the previous behavior. [#85986][#85986] -- The `GRANT` privilege has been removed and replaced by the more granular [`WITH GRANT OPTION`]({% link v25.2/grant.md %}#grant-privileges-with-the-option-to-grant-to-others), which provides control over which privileges are allowed to be granted. [#81310][#81310] +- If no `nullif` option is specified while using [`IMPORT CSV`]({% link {{ page.version.version }}/import.md %}), then a zero-length string in the input is now treated as `NULL`. The quoted empty string in the input is treated as an empty string. Similarly, if `nullif` is specified, then an unquoted value is treated as `NULL`, and a quoted value is treated as that string. These changes were made to make `IMPORT CSV` behave more similarly to `COPY CSV`. If the previous behavior (i.e., treating either quoted or unquoted values that match the `nullif` setting as `NULL`) is desired, you can use the new `allow_quoted_null` option in the `IMPORT` statement. [#84487][#84487] +- [`COPY FROM`]({% link {{ page.version.version }}/copy.md %}) operations are now atomic by default instead of being segmented into 100 row transactions. Set the `copy_from_atomic_enabled` session setting to `false` for the previous behavior. [#85986][#85986] +- The `GRANT` privilege has been removed and replaced by the more granular [`WITH GRANT OPTION`]({% link {{ page.version.version }}/grant.md %}#grant-privileges-with-the-option-to-grant-to-others), which provides control over which privileges are allowed to be granted. [#81310][#81310] - Removed the ability to cast `int`, `int2`, and `int8` to a `0` length `BIT` or `VARBIT`. [#81266][#81266] - Removed the deprecated `GRANT` privilege. [#81310][#81310] - Removed the `ttl_automatic_column` storage parameter. The `crdb_internal_expiration` column is created when `ttl_expire_after` is set and removed when `ttl_expire_after` is reset. [#83134][#83134] - Removed the byte string parameter in the `crdb_internal.schedule_sql_stats_compaction` function. [#82560][#82560] -- Changed the default value of the `enable_implicit_transaction_for_batch_statements` to `true`. This means that a [batch of statements]({% link v25.2/transactions.md %}#batched-statements) sent in one string separated by semicolons is treated as an implicit transaction. [#76834][#76834] +- Changed the default value of the `enable_implicit_transaction_for_batch_statements` to `true`. This means that a [batch of statements]({% link {{ page.version.version }}/transactions.md %}#batched-statements) sent in one string separated by semicolons is treated as an implicit transaction. [#76834][#76834] diff --git a/src/current/_includes/v25.2/misc/movr-schema.md b/src/current/_includes/v25.2/misc/movr-schema.md index e838bcf4572..1c51e944d74 100644 --- a/src/current/_includes/v25.2/misc/movr-schema.md +++ b/src/current/_includes/v25.2/misc/movr-schema.md @@ -9,4 +9,4 @@ Table | Description `user_promo_codes` | Promotional codes in use by users. `vehicle_location_histories` | Vehicle location history. -Geo-partitioning schema +Geo-partitioning schema diff --git a/src/current/_includes/v25.2/performance/check-rebalancing-after-partitioning.md b/src/current/_includes/v25.2/performance/check-rebalancing-after-partitioning.md index c7e19142bd4..d46472fdfd4 100644 --- a/src/current/_includes/v25.2/performance/check-rebalancing-after-partitioning.md +++ b/src/current/_includes/v25.2/performance/check-rebalancing-after-partitioning.md @@ -2,7 +2,7 @@ Over the next minutes, CockroachDB will rebalance all partitions based on the co To check this at a high level, access the Web UI on any node at `:8080` and look at the **Node List**. You'll see that the range count is still close to even across all nodes but much higher than before partitioning: -Perf tuning rebalancing +Perf tuning rebalancing To check at a more granular level, SSH to one of the instances not running CockroachDB and run the `SHOW EXPERIMENTAL_RANGES` statement on the `vehicles` table: diff --git a/src/current/_includes/v25.2/performance/check-rebalancing.md b/src/current/_includes/v25.2/performance/check-rebalancing.md index 32e3d98f8f1..3c63a0a2f0e 100644 --- a/src/current/_includes/v25.2/performance/check-rebalancing.md +++ b/src/current/_includes/v25.2/performance/check-rebalancing.md @@ -2,7 +2,7 @@ Since you started each node with the `--locality` flag set to its GCE zone, over To check this, access the DB Console on any node at `:8080` and look at the **Node List**. You'll see that the range count is more or less even across all nodes: -Perf tuning rebalancing +Perf tuning rebalancing For reference, here's how the nodes map to zones: diff --git a/src/current/_includes/v25.2/sql/macos-terminal-configuration.md b/src/current/_includes/v25.2/sql/macos-terminal-configuration.md index 5b636259ce1..85d5461f8f1 100644 --- a/src/current/_includes/v25.2/sql/macos-terminal-configuration.md +++ b/src/current/_includes/v25.2/sql/macos-terminal-configuration.md @@ -3,12 +3,12 @@ In **Apple Terminal**: 1. Navigate to "Preferences", then "Profiles", then "Keyboard". 1. Enable the checkbox "Use Option as Meta Key". -Apple Terminal Alt key configuration +Apple Terminal Alt key configuration In **iTerm2**: 1. Navigate to "Preferences", then "Profiles", then "Keys". 1. Select the radio button "Esc+" for the behavior of the Left Option Key. -iTerm2 Alt key configuration +iTerm2 Alt key configuration diff --git a/src/current/_includes/v25.2/start-in-docker/mac-linux-steps.md b/src/current/_includes/v25.2/start-in-docker/mac-linux-steps.md index 9de4428329d..d80728b8a62 100644 --- a/src/current/_includes/v25.2/start-in-docker/mac-linux-steps.md +++ b/src/current/_includes/v25.2/start-in-docker/mac-linux-steps.md @@ -276,7 +276,7 @@ The [DB Console]({% link {{ page.version.version }}/ui-overview.md %}) gives you 1. On the [**Cluster Overview**]({% link {{ page.version.version }}/ui-cluster-overview-page.md %}), notice that three nodes are live, with an identical replica count on each node: - DB Console + DB Console This demonstrates CockroachDB's [automated replication]({% link {{ page.version.version }}/demo-replication-and-rebalancing.md %}) of data via the Raft consensus protocol. @@ -286,7 +286,7 @@ The [DB Console]({% link {{ page.version.version }}/ui-overview.md %}) gives you 1. Click [**Metrics**]({% link {{ page.version.version }}/ui-overview-dashboard.md %}) to access a variety of time series dashboards, including graphs of SQL queries and service latency over time: - DB Console + DB Console 1. Use the [**Databases**]({% link {{ page.version.version }}/ui-databases-page.md %}), [**Statements**]({% link {{ page.version.version }}/ui-statements-page.md %}), and [**Jobs**]({% link {{ page.version.version }}/ui-jobs-page.md %}) pages to view details about your databases and tables, to assess the performance of specific queries, and to monitor the status of long-running operations like schema changes, respectively. 1. Optionally verify that DB Console instances for `roach2` and `roach3` are reachable on ports 8081 and 8082 and show the same information as port 8080. diff --git a/src/current/_includes/v25.2/topology-patterns/multi-region-cluster-setup.md b/src/current/_includes/v25.2/topology-patterns/multi-region-cluster-setup.md index cf8bf46a9a1..88438903d0a 100644 --- a/src/current/_includes/v25.2/topology-patterns/multi-region-cluster-setup.md +++ b/src/current/_includes/v25.2/topology-patterns/multi-region-cluster-setup.md @@ -1,6 +1,6 @@ Each [multi-region pattern]({% link {{ page.version.version }}/topology-patterns.md %}#multi-region) assumes the following setup: -Multi-region hardware setup +Multi-region hardware setup #### Hardware diff --git a/src/current/_includes/v25.2/ui/active-statement-executions.md b/src/current/_includes/v25.2/ui/active-statement-executions.md index e2254c2ac02..d2bc1ace62a 100644 --- a/src/current/_includes/v25.2/ui/active-statement-executions.md +++ b/src/current/_includes/v25.2/ui/active-statement-executions.md @@ -30,7 +30,7 @@ The statement execution details page provides the following details on the state If a statement execution is waiting, the statement execution details are followed by Contention Insights and details of the statement execution on which the blocked statement execution is waiting. For more information about contention, see [Understanding and avoiding transaction contention]({{ link_prefix }}performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention). -Movr rides transactions +Movr rides transactions ## See also diff --git a/src/current/_includes/v25.2/ui/active-transaction-executions.md b/src/current/_includes/v25.2/ui/active-transaction-executions.md index ee2ee069ad1..62a4c44ddf0 100644 --- a/src/current/_includes/v25.2/ui/active-transaction-executions.md +++ b/src/current/_includes/v25.2/ui/active-transaction-executions.md @@ -35,7 +35,7 @@ The transaction execution details page provides the following details on the tra If a transaction execution is waiting, the transaction execution details are followed by Contention Insights and details of the transaction execution on which the blocked transaction execution is waiting. For more information about contention, see [Transaction contention]({{ link_prefix }}performance-best-practices-overview.html#transaction-contention). -Movr rides transactions +Movr rides transactions ## See also diff --git a/src/current/_includes/v25.2/ui/insights.md b/src/current/_includes/v25.2/ui/insights.md index 8c1c9b43858..ddfbe78739b 100644 --- a/src/current/_includes/v25.2/ui/insights.md +++ b/src/current/_includes/v25.2/ui/insights.md @@ -185,11 +185,11 @@ The Workload Insights tab surfaces the following type of insights: The transaction or statement execution failed. The following screenshot shows a failed transaction execution: -Failed transaction execution +Failed transaction execution The following screenshot shows the default details of the preceding failed transaction execution. -Failed transaction execution details +Failed transaction execution details The **Insights** column shows the name of the insight, in this case **Failed Execution**. The **Details** column provides the **Error Code** and **Error Message**. CockroachDB uses [PostgreSQL Error Codes](https://www.postgresql.org/docs/current/errcodes-appendix.html). In this example, Error Code `40001` is a `serialization_failure`. @@ -197,7 +197,7 @@ The **Insights** column shows the name of the insight, in this case **Failed Exe The following screenshot shows the conditional details of the preceding failed transaction execution. In this case, there was a *serialization conflict*, also known as an *isolation conflict*, due to [transaction contention]({{ link_prefix }}performance-recipes.html#transaction-contention). (For transaction contention that causes *lock contention*, see [High Contention](#high-contention)). -Failed transaction execution details conditional +Failed transaction execution details conditional To capture more information in the event of a failed transaction execution due to a serialization conflict, set the [`sql.contention.record_serialization_conflicts.enabled`]({{ link_prefix }}cluster-settings.html#setting-sql-contention-record-serialization-conflicts-enabled) cluster setting to `true` (default). With this setting enabled, when the **Error Code** is `40001` and the **Error Message** specifically has [`RETRY_SERIALIZABLE - failed preemptive refresh`]({{ link_prefix }}transaction-retry-error-reference.html#failed_preemptive_refresh)` due to conflicting locks`, a conditional **Failed Execution** section is displayed with **Conflicting Transaction** and **Conflicting Location** information. @@ -211,11 +211,11 @@ To troubleshoot, refer to the performance tuning recipe for [identifying and unb The following screenshot shows the execution of a transaction flagged with **High Contention**: -Transaction execution +Transaction execution The following screenshot shows the execution details of the preceding transaction execution: -Transaction execution details +Transaction execution details ### High Retry Count @@ -236,11 +236,11 @@ The statement execution has resulted in one or more [index recommendations](#sch The following screenshot shows the statement execution of the query described in [Use the right index]({{ link_prefix }}apply-statement-performance-rules.html#rule-2-use-the-right-index): -Statement execution +Statement execution The following screenshot shows the execution details of the preceding statement execution: -Statement execution details +Statement execution details The **Insights** column shows the name of the insight, in this case **Suboptimal Plan**. The **Details** column provides details on the insight, such as a **Description** with the cause of the suboptimal plan and a **Recommendation** with a `CREATE INDEX` statement. The final column contains a **Create Index** button. Click the **Create Index** button to execute the recommended statement to mitigate the cause of the insight. @@ -262,7 +262,7 @@ This view lists the [indexes]({{ link_prefix }}indexes.html) that have not been The following screenshot shows the insight that displays after you run the query described in [Use the right index]({{ link_prefix }}apply-statement-performance-rules.html#rule-2-use-the-right-index) six or more times: -Schema insight +Schema insight CockroachDB uses the threshold of six executions before offering an insight because it assumes that you are no longer merely experimenting with a query at that point. diff --git a/src/current/_includes/v25.2/ui/jobs.md b/src/current/_includes/v25.2/ui/jobs.md index c67c55d9a0c..b7edf59e935 100644 --- a/src/current/_includes/v25.2/ui/jobs.md +++ b/src/current/_includes/v25.2/ui/jobs.md @@ -8,7 +8,7 @@ The Jobs list is designed for you to manage pending work. It is not intended to Use the **Jobs** table to see recently created and completed jobs. -DB Console Jobs Page +DB Console Jobs Page ### Filter jobs @@ -66,7 +66,7 @@ The details show: - **User Name** - error messages (if any) -DB Console Jobs Page +DB Console Jobs Page ## See also diff --git a/src/current/_includes/v25.2/ui/refresh.md b/src/current/_includes/v25.2/ui/refresh.md index d34c28da080..9f1f152b630 100644 --- a/src/current/_includes/v25.2/ui/refresh.md +++ b/src/current/_includes/v25.2/ui/refresh.md @@ -6,7 +6,7 @@ To control refresh of the data on the Active Executions views of the SQL Activit - A manual **Refresh** button: When clicked, refreshes data immediately. - An **Auto Refresh** toggle: When toggled **On** (default), refreshes data immediately and then automatically every 10 seconds. When toggled **Off**, stops automatic data refresh. The toggle setting is shared by both the Statements and the Transactions pages. Changing the setting on one page changes it on the other page. -Active executions view refresh +Active executions view refresh If **Auto Refresh** is toggled **On**, navigating to the Active Executions view on either the Statements page or Transactions page refreshes the data. diff --git a/src/current/_includes/v25.2/ui/sessions.md b/src/current/_includes/v25.2/ui/sessions.md index 8803337459b..6194f3ae6c5 100644 --- a/src/current/_includes/v25.2/ui/sessions.md +++ b/src/current/_includes/v25.2/ui/sessions.md @@ -1,10 +1,10 @@ {% if page.cloud != true %} -Sessions Page +Sessions Page {% endif %} To filter the sessions, click the **Filters** field. -Session filter +Session filter - To filter by [application]({{ link_prefix }}connection-parameters.html#additional-connection-parameters), select **Application Name** and choose one or more applications. @@ -40,7 +40,7 @@ To view details of a session, click a **Session Start Time (UTC)** to display se If a session is idle, the **Transaction** and **Most Recent Statement** panels will display **No Active [Transaction | Statement]**. {% if page.cloud != true %} -Sessions Details Page +Sessions Details Page {% endif %} The **Cancel statement** button ends the SQL statement. The session running this statement will receive an error. diff --git a/src/current/_includes/v25.2/ui/statement-details.md b/src/current/_includes/v25.2/ui/statement-details.md index 4c846eed9fa..66008abe036 100644 --- a/src/current/_includes/v25.2/ui/statement-details.md +++ b/src/current/_includes/v25.2/ui/statement-details.md @@ -35,7 +35,7 @@ The **Overview** section also displays the SQL statement fingerprint statistics The following screenshot shows the statement fingerprint of the query described in [Use the right index]({{ link_prefix }}apply-statement-performance-rules.html#rule-2-use-the-right-index): -Statement fingerprint overview +Statement fingerprint overview #### Insights @@ -47,7 +47,7 @@ The **Insights** table is displayed when CockroachDB has detected a problem with The following screenshot shows the insights of the statement fingerprint illustrated in [Overview](#overview): -Statement fingerprint overview +Statement fingerprint overview #### Charts @@ -65,7 +65,7 @@ Charts following the execution attributes display statement fingerprint statisti The following charts summarize the executions of the statement fingerprint illustrated in [Overview](#overview): -Statement fingerprint charts +Statement fingerprint charts ### Explain Plans @@ -73,7 +73,7 @@ The **Explain Plans** tab displays statement plans for an [explainable statement The following screenshot shows an execution of the query discussed in [Overview](#overview): -Plan table +Plan table The plan table shows the following details: @@ -94,7 +94,7 @@ Vectorized | Whether the execution used the [vectorized execution engine]({{ lin To display the plan that was executed, click the plan gist. For the plan gist `AgHUAQIABQAAAAHYAQIAiA...`, the following plan displays: -Plan table +Plan table #### Insights @@ -102,7 +102,7 @@ The plan table displays the number of insights related to the plan. If a plan ha The following screenshot shows 1 insight found after running the query discussed in [Overview](#overview) 6 or more times: -Plan with insight +Plan with insight {{site.data.alerts.callout_info}} CockroachDB uses the threshold of 6 executions before offering an insight because it assumes that you are no longer merely experimenting with a query at that point. @@ -114,7 +114,7 @@ If you click **Create Index**, a confirmation dialog displays a warning about th If you click **Apply** to create the index and then execute the statement again, the **Explain Plans** tab will show that the second execution (in this case at `19:40`), which uses the index and has no insight, takes less time than the first 6 executions. -Plan table after index +Plan table after index ### Diagnostics @@ -134,7 +134,7 @@ Diagnostics will be collected a maximum of *N* times for a given activated finge #### Activate diagnostics collection and download bundles -Activate statement diagnostics +Activate statement diagnostics {{site.data.alerts.callout_danger}} Collecting diagnostics has an impact on performance. All executions of the statement fingerprint will run slower until diagnostics are collected. @@ -156,11 +156,11 @@ To activate diagnostics collection: When the statement fingerprint is executed according to the statement diagnostic options selected, a row with the activation time and collection status is added to the **Statement diagnostics** table. -Statement diagnostics table +Statement diagnostics table The collection status values are: -- **READY**: indicates that the diagnostics have been collected. To download the diagnostics bundle, click Down arrow **Bundle (.zip)**. +- **READY**: indicates that the diagnostics have been collected. To download the diagnostics bundle, click Down arrow **Bundle (.zip)**. - **WAITING**: indicates that a SQL statement matching the fingerprint has not yet been recorded. To cancel diagnostics collection, click the **Cancel request** button. - **ERROR**: indicates that the attempt at diagnostics collection failed. @@ -173,4 +173,4 @@ Although fingerprints are periodically cleared from the Statements page, all dia - Click **Advanced Debug** in the left-hand navigation and click [Statement Diagnostics History]({% link {{ page.version.version }}/ui-debug-pages.md %}#reports). {% endif %} -Click Down arrow **Bundle (.zip)** to download any diagnostics bundle. +Click Down arrow **Bundle (.zip)** to download any diagnostics bundle. diff --git a/src/current/_includes/v25.2/ui/statements-filter.md b/src/current/_includes/v25.2/ui/statements-filter.md index 34305a565e4..0daac06c1f8 100644 --- a/src/current/_includes/v25.2/ui/statements-filter.md +++ b/src/current/_includes/v25.2/ui/statements-filter.md @@ -72,4 +72,4 @@ To filter the statements: The following screenshot shows the statements that contain the string `rides` for the `movr` application filtered by `Statement Type: DML`: -Movr rides statements +Movr rides statements diff --git a/src/current/_includes/v25.2/ui/statements-views.md b/src/current/_includes/v25.2/ui/statements-views.md index 607e05528f2..4d5fdd5ff30 100644 --- a/src/current/_includes/v25.2/ui/statements-views.md +++ b/src/current/_includes/v25.2/ui/statements-views.md @@ -41,11 +41,11 @@ The **Statements** tab is selected. The **Statement Fingerprints** radio button The following screenshot shows the statement fingerprint for `SELECT city, id FROM vehicles WHERE city = $1` while running the [`movr` workload]({{ link_prefix}}cockroach-workload.html#run-the-movr-workload): -Statement fingerprint +Statement fingerprint If you click the statement fingerprint in the **Statements** column, the [**Statement Fingerprint** page](#statement-fingerprint-page) displays. -Statement details +Statement details ## Active Executions view @@ -66,11 +66,11 @@ When Auto [Refresh](#refresh) is On, active executions are polled every 10 secon The following screenshot shows the active statement execution for `INSERT INTO users VALUES ($1, $2, $3, $4, $5)` while running the [`movr` workload]({{ link_prefix }}cockroach-workload.html#run-the-movr-workload): -Statement execution +Statement execution If you click the execution ID in the **Statement Execution ID** column, the [**Statement Execution** details page](#statement-execution-details-page) displays. -Statement execution details +Statement execution details {% if page.cloud != true %} {% include {{ page.version.version }}/ui/refresh.md %} diff --git a/src/current/_includes/v25.2/ui/transactions-filter.md b/src/current/_includes/v25.2/ui/transactions-filter.md index 57330f05477..e9225d4e9e1 100644 --- a/src/current/_includes/v25.2/ui/transactions-filter.md +++ b/src/current/_includes/v25.2/ui/transactions-filter.md @@ -69,4 +69,4 @@ To filter the transactions: The following screenshot shows the transactions that contain the string `rides` for the `movr` application filtered by `Runs Longer Than: 300 milliseconds`: -Movr rides transactions +Movr rides transactions diff --git a/src/current/_includes/v25.2/ui/transactions-views.md b/src/current/_includes/v25.2/ui/transactions-views.md index 37774b75fb6..96face0c911 100644 --- a/src/current/_includes/v25.2/ui/transactions-views.md +++ b/src/current/_includes/v25.2/ui/transactions-views.md @@ -41,11 +41,11 @@ Click the **Transactions** tab. The **Transaction Fingerprints** radio button is The following screenshot shows the transaction fingerprint for `SELECT city, id FROM vehicles WHERE city = $1` while running the [`movr` workload]({{ link_prefix }}cockroach-workload.html#run-the-movr-workload): -Transaction fingerprint +Transaction fingerprint If you click the transaction fingerprint in the **Transactions** column, the [**Transaction Details** page](#transaction-details-page) displays. -Transaction details +Transaction details ## Active Executions view @@ -66,11 +66,11 @@ When Auto [Refresh](#refresh) is On, active executions are polled every 10 secon The following screenshot shows the active statement execution for `UPSERT INTO vehicle_location_histories VALUES ($1, $2, now(), $4, $5)` while running the [`movr` workload]({{ link_prefix }}cockroach-workload.html#run-the-movr-workload): -Transaction execution +Transaction execution If you click the execution ID in the **Transaction Execution ID** column, the [**Transaction Execution** details page](#transaction-execution-details-page) displays. -Transaction execution details +Transaction execution details {% if page.cloud != true %} {% include {{ page.version.version }}/ui/refresh.md %} diff --git a/src/current/_includes/v25.2/ui/ui-summary-events.md b/src/current/_includes/v25.2/ui/ui-summary-events.md index f074d5584d6..abe374c88ab 100644 --- a/src/current/_includes/v25.2/ui/ui-summary-events.md +++ b/src/current/_includes/v25.2/ui/ui-summary-events.md @@ -20,7 +20,7 @@ P99 Latency | The 99th percentile of service latency. Underneath the [Summary](#summary-panel) panel, the **Events** panel lists the 5 most recent events logged for all nodes across the cluster. To list all events, click **View all events**. -DB Console Events +DB Console Events The following types of events are listed: diff --git a/src/current/_includes/v25.2/upgrade-requirements.md b/src/current/_includes/v25.2/upgrade-requirements.md index 2d28309a2be..048f5f257fb 100644 --- a/src/current/_includes/v25.2/upgrade-requirements.md +++ b/src/current/_includes/v25.2/upgrade-requirements.md @@ -1,3 +1,3 @@ CockroachDB v25.1 is an Innovation release. To upgrade to it, you must be running v24.3, the previous Regular release. -Before continuing, [upgrade to v24.3]({% link v24.3/upgrade-cockroach-version.md %}). +Before continuing, [upgrade to v24.3]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}). diff --git a/src/current/v25.2/architecture/reads-and-writes-overview.md b/src/current/v25.2/architecture/reads-and-writes-overview.md index e1c0d5ee0fa..27a1bbd1c97 100644 --- a/src/current/v25.2/architecture/reads-and-writes-overview.md +++ b/src/current/v25.2/architecture/reads-and-writes-overview.md @@ -30,7 +30,7 @@ First, imagine a simple read scenario where: - Ranges are replicated 3 times (the default). - A query is executed against node 2 to read from table 3. -Perf tuning concepts +Perf tuning concepts In this case: @@ -41,13 +41,13 @@ In this case: If the query is received by the node that has the leaseholder for the relevant range, there are fewer network hops: -Perf tuning concepts +Perf tuning concepts ## Write scenario Now imagine a simple write scenario where a query is executed against node 3 to write to table 1: -Perf tuning concepts +Perf tuning concepts In this case: @@ -60,7 +60,7 @@ In this case: Just as in the read scenario, if the write request is received by the node that has the leaseholder and Raft leader for the relevant range, there are fewer network hops: -Perf tuning concepts +Perf tuning concepts ## Network and I/O bottlenecks diff --git a/src/current/v25.2/architecture/storage-layer.md b/src/current/v25.2/architecture/storage-layer.md index 2fbafaef998..dd54b0ce1d0 100644 --- a/src/current/v25.2/architecture/storage-layer.md +++ b/src/current/v25.2/architecture/storage-layer.md @@ -63,7 +63,7 @@ Pebble uses a Log-structured Merge-tree (hereafter _LSM tree_ or _LSM_) to manag SSTs are an on-disk representation of sorted lists of key-value pairs. Conceptually, they look something like this (intentionally simplified) diagram: -Structure of an SST file +Structure of an SST file SST files are immutable; they are never modified, even during the [compaction process](#compaction). @@ -78,7 +78,7 @@ The SSTs within each level are guaranteed to be non-overlapping: for example, if - To allow LSM-based storage engines like Pebble to support ingesting large amounts of data, such as when using the [`IMPORT INTO`]({% link {{ page.version.version }}/import-into.md %}) statement. - To allow for easier and more efficient flushes of [memtables](#memtable-and-write-ahead-log). -LSM tree with SST files +LSM tree with SST files ##### Compaction @@ -128,7 +128,7 @@ Another file on disk called the write-ahead log (hereafter _WAL_) is associated The relationship between the memtable, the WAL, and the SST files is shown in the diagram below. New values are written to the WAL at the same time as they are written to the memtable. From the memtable they are eventually written to SST files on disk for longer-term storage. -Relationship between memtable, WAL, and SSTs +Relationship between memtable, WAL, and SSTs ##### LSM design tradeoffs diff --git a/src/current/v25.2/aws-dms.md b/src/current/v25.2/aws-dms.md index 99a42ac0532..df3317f81e3 100644 --- a/src/current/v25.2/aws-dms.md +++ b/src/current/v25.2/aws-dms.md @@ -93,7 +93,7 @@ As of publishing, AWS DMS supports migrations from these relational databases (f 1. In the AWS Console, open **AWS DMS**. 1. Open **Endpoints** in the sidebar. A list of endpoints will display, if any exist. 1. In the top-right portion of the window, select **Create endpoint**. - AWS-DMS-Create-Endpoint + AWS-DMS-Create-Endpoint A configuration page will open. 1. In the **Endpoint type** section, select **Target endpoint**. @@ -107,10 +107,10 @@ As of publishing, AWS DMS supports migrations from these relational databases (f {{site.data.alerts.callout_info}} To connect to a CockroachDB {{ site.data.products.standard }} or {{ site.data.products.basic }} cluster, set the **Database name** to `{host}.{database}`. For details on how to find these parameters, see [Connect to your cluster]({% link cockroachcloud/connect-to-your-cluster.md %}?filters=connection-parameters#connect-to-your-cluster). Also set **Secure Socket Layer (SSL) mode** to **require**. {{site.data.alerts.end}} - AWS-DMS-Endpoint-Configuration + AWS-DMS-Endpoint-Configuration 1. If needed, you can test the connection under **Test endpoint connection (optional)**. 1. To create the endpoint, select **Create endpoint**. - AWS-DMS-Test-Endpoint + AWS-DMS-Test-Endpoint ## Step 2. Create a database migration task @@ -124,7 +124,7 @@ To conserve CPU, consider migrating tables in multiple replication tasks, rather 1. While in **AWS DMS**, select **Database migration tasks** in the sidebar. A list of database migration tasks will display, if any exist. 1. In the top-right portion of the window, select **Create task**. - AWS-DMS-Create-DB-Migration-Task + AWS-DMS-Create-DB-Migration-Task A configuration page will open. 1. Supply a **Task identifier** to identify the replication task. @@ -135,17 +135,17 @@ To conserve CPU, consider migrating tables in multiple replication tasks, rather {{site.data.alerts.callout_danger}} If you choose **Migrate existing data and replicate ongoing changes** or **Replicate data changes only**, you must first [disable revision history for backups](#setup). {{site.data.alerts.end}} - AWS-DMS-Task-Configuration + AWS-DMS-Task-Configuration ### Step 2.2. Task settings 1. For the **Editing mode** radio button, keep **Wizard** selected. 1. To preserve the schema you manually created, select **Truncate** or **Do nothing** for the **Target table preparation mode**. - AWS-DMS-Task-Settings + AWS-DMS-Task-Settings 1. Optionally check **Enable validation** to compare the data in the source and target rows, and verify that the migration succeeded. You can view the results in the [**Table statistics**](#step-3-verify-the-migration) for your migration task. For more information about data validation, see the [AWS documentation](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html). 1. Check the **Enable CloudWatch logs** option. We highly recommend this for troubleshooting potential migration issues. 1. For the **Target Load**, select **Detailed debug**. - AWS-DMS-CloudWatch-Logs + AWS-DMS-CloudWatch-Logs ### Step 2.3. Table mappings @@ -161,7 +161,7 @@ When specifying a range of tables to migrate, the following aspects of the sourc 1. Select **Add new selection rule**. 1. In the **Schema** dropdown, select **Enter a schema**. 1. Supply the appropriate **Source name** (schema name), **Table name**, and **Action**. - AWS-DMS-Table-Mappings + AWS-DMS-Table-Mappings {{site.data.alerts.callout_info}} Use `%` as an example of a wildcard for all schemas in a PostgreSQL database. However, in MySQL, using `%` as a schema name imports all the databases, including the metadata/system ones, as MySQL treats schemas and databases as the same. @@ -205,7 +205,7 @@ If your migration succeeded, you should now: If your migration failed for some reason, you can check the checkbox next to the table(s) you wish to re-migrate and select **Reload table data**. -AWS-DMS-Reload-Table-Data +AWS-DMS-Reload-Table-Data ## Optional configurations @@ -221,7 +221,7 @@ The `BatchApplyEnabled` setting can improve replication performance and is recom 1. Choose your task, and then choose **Modify**. 1. From the **Task settings** section, switch the **Editing mode** from **Wizard** to **JSON editor**. Locate the `BatchApplyEnabled` setting and change its value to `true`. Information about the `BatchApplyEnabled` setting can be found [here](https://aws.amazon.com/premiumsupport/knowledge-center/dms-batch-apply-cdc-replication/). -AWS-DMS-BatchApplyEnabled +AWS-DMS-BatchApplyEnabled {{site.data.alerts.callout_info}} `BatchApplyEnabled` does not work when using **Drop tables on target** as a target table preparation mode. Thus, all schema-related changes must be manually copied over if using `BatchApplyEnabled`. @@ -277,7 +277,7 @@ The `BatchApplyEnabled` setting can improve replication performance and is recom To prevent this error, set the [`expect_and_ignore_not_visible_columns_in_copy` session variable]({% link {{ page.version.version }}/session-variables.md %}#expect-and-ignore-not-visible-columns-in-copy) in the DMS [target endpoint configuration](#step-1-create-a-target-endpoint-pointing-to-cockroachdb). Under **Endpoint settings**, add an **AfterConnectScript** setting with the value `SET expect_and_ignore_not_visible_columns_in_copy=on`. - AWS-DMS-Endpoint-Settings + AWS-DMS-Endpoint-Settings - The following error in the CockroachDB [logs]({% link {{ page.version.version }}/logging-overview.md %}) indicates that AWS DMS is unable to copy into a table with a [computed column]({% link {{ page.version.version }}/computed-columns.md %}): diff --git a/src/current/v25.2/backup-architecture.md b/src/current/v25.2/backup-architecture.md index 5a653eb6470..b0fabd82c3f 100644 --- a/src/current/v25.2/backup-architecture.md +++ b/src/current/v25.2/backup-architecture.md @@ -27,7 +27,7 @@ At a high level, CockroachDB performs the following tasks when running a backup The following diagram illustrates the flow from `BACKUP` statement through to a complete backup in cloud storage: -A flow diagram representing the process of a backup job from statement through to backup data stored. +A flow diagram representing the process of a backup job from statement through to backup data stored. ## Job creation phase @@ -85,7 +85,7 @@ In the following diagram, nodes that contain replicas of the relevant key spans While processing, the nodes emit progress data that tracks their backup work to the coordinator. In the diagram, **Node 3** and **Node 1** will send progress data to **Node 2**. The coordinator node will then aggregate the progress data into checkpoint files in the storage bucket. The checkpoint files provide a marker for the backup to resume after a retryable state, such as when it has been [paused]({% link {{ page.version.version }}/pause-job.md %}). -Three-node cluster exporting backup data from the leaseholders +Three-node cluster exporting backup data from the leaseholders ## Metadata writing phase @@ -112,7 +112,7 @@ For example, in the following diagram there is a three-node cluster split across During a [restore]({% link {{ page.version.version }}/restore.md %}) job, the job creation statement will need access to each of the storage locations to read the metadata files in order to complete a successful restore. -How a locality-aware backup writes to storage buckets in each region +How a locality-aware backup writes to storage buckets in each region #### Job coordination on CockroachDB Standard and Basic clusters diff --git a/src/current/v25.2/changefeed-messages.md b/src/current/v25.2/changefeed-messages.md index 616bf71ca7f..7ed100c03d8 100644 --- a/src/current/v25.2/changefeed-messages.md +++ b/src/current/v25.2/changefeed-messages.md @@ -237,7 +237,7 @@ A changefeed job cannot confirm that a message has been received by the sink unl When a changefeed must pause and then resume, it will return to the last checkpoint (**A**), which is the last point at which the coordinator confirmed all changes for the given timestamp. As a result, when the changefeed resumes, it will re-emit the messages that were not confirmed in the next checkpoint. The changefeed may not re-emit every message, but it will ensure each change is emitted at least once. -How checkpoints will re-emit messages when a changefeed pauses. The changefeed returns to the last checkpoint and potentially sends duplicate messages. +How checkpoints will re-emit messages when a changefeed pauses. The changefeed returns to the last checkpoint and potentially sends duplicate messages. ### Changefeed encounters an error diff --git a/src/current/v25.2/changefeed-monitoring-guide.md b/src/current/v25.2/changefeed-monitoring-guide.md index 28d0cec6af5..defa5f110f3 100644 --- a/src/current/v25.2/changefeed-monitoring-guide.md +++ b/src/current/v25.2/changefeed-monitoring-guide.md @@ -22,7 +22,7 @@ The changefeed pipeline contains three main sections that start at the [storage - [**Processing**](#processing-aggregation-and-encoding): Prepares the change events from the rangefeed into [changefeed messages]({% link {{ page.version.version }}/changefeed-messages.md %}) by encoding messages into the specified [format]({% link {{ page.version.version }}/changefeed-messages.md %}#message-formats). - [**Sink**](#sink): Delivers changefeed messages to the [downstream sink]({% link {{ page.version.version }}/changefeed-sinks.md %}). -An overview of the changefeed pipeline and the metrics that are connected to each stage. +An overview of the changefeed pipeline and the metrics that are connected to each stage. Where noted in the following sections, you can use changefeed [metrics labels]({% link {{ page.version.version }}/monitor-and-debug-changefeeds.md %}#using-changefeed-metrics-labels) to measure metrics per changefeed. diff --git a/src/current/v25.2/cloud-storage-authentication.md b/src/current/v25.2/cloud-storage-authentication.md index 4a7ec43d91d..bdcd2b44969 100644 --- a/src/current/v25.2/cloud-storage-authentication.md +++ b/src/current/v25.2/cloud-storage-authentication.md @@ -131,7 +131,7 @@ For example, to configure a user to assume an IAM role that allows a bulk operat The `sts:AssumeRole` permission allows the user to obtain a temporary set of security credentials that gives them access to an S3 bucket to which they would not have access with their user-based permissions. - AWS user summary page showing the JSON policy in place + AWS user summary page showing the JSON policy in place 1. Return to your IAM role's **Summary** page, and click on the **Trust Relationships** tab. Add a trust policy into the role, which will define the users that can assume the role. @@ -304,7 +304,7 @@ Once you have an identity role that your CockroachDB nodes can assume, you can c Copy the ARN of the identity role. In the Amazon management console, click on **IAM**, then **Roles**, and select the name of your identity role. From the **Summary** page, copy your ARN. You will need this when configuring the Trust Policy for the IAM role to be assumed. -Role summary page showing the ARN copied +Role summary page showing the ARN copied See [Step 2. Trust the identity role](#step-2-trust-the-identity-role) to add this ARN to an operation role's Trust Policy. @@ -318,21 +318,21 @@ If you already have the role that contains permissions for the operation, ensure 1. To create an operation role, click **Create Role** under the **Roles** menu. Select **Custom trust policy** and then add the ARN of your identity role (from [Step 1](#step-1-set-up-the-identity-role)) to the JSON by clicking `Principal`. This will open a dialog box. Select **IAM Roles** for **Principal Type** and paste the ARN. Click **Add Principal** and then **Next**. - Dialog box to add principal with IAM roles selected + Dialog box to add principal with IAM roles selected 2. On the **Add Permissions** page, search for the permission policies that the role will need to complete the bulk operation. - Filter list to add permissions to IAM roles + Filter list to add permissions to IAM roles Or, use the **Create Policy** button to define the required permissions. You can use the visual editor to select the service, actions, and resources. - Using the visual editor to define S3 service and S3 actions. + Using the visual editor to define S3 service and S3 actions. Or, use the JSON tab to specify the policy. For the JSON editor, see [Storage Permissions]({% link {{ page.version.version }}/use-cloud-storage.md %}#storage-permissions) for an example and detail on the minimum permissions required for each operation to complete. Click **Next**. 3. Finally, give the role a name on the **Name, review, and create** page. The following screenshot shows the selected trust policy and permissions: - Final screen in the create role process to review permissions and name role + Final screen in the create role process to review permissions and name role ### Step 3. Run the operation by assuming the role @@ -447,7 +447,7 @@ For this example, both service accounts have already been created. If you need t - In [Google's Cloud console](https://console.cloud.google.com/getting-started), click **IAM & Admin**, **Roles**, and then **Create Role**. - Add a title for the role and then click **Add Permissions**. Filter for the permissions required for the bulk operation. For example, if you want to enable service account B to run a changefeed, your role will include the `storage.objects.create` permission. See the [Storage permissions]({% link {{ page.version.version }}/use-cloud-storage.md %}#storage-permissions) section on this page for details on the minimum permissions each CockroachDB bulk operation requires. - Adding permissions to a changefeed role when creating a role. + Adding permissions to a changefeed role when creating a role. {{site.data.alerts.callout_success}} Alternately, you can use the [gcloud CLI](https://cloud.google.com/sdk/gcloud/reference/iam/roles/create) to create roles. @@ -457,14 +457,14 @@ For this example, both service accounts have already been created. If you need t - Go to the **Cloud Storage** menu and select the bucket. In the bucket's menu, click **Grant Access**. - Add the service account to the **Add principals** box and select the name of the role you created in step 1 under **Assign roles**. - Adding service account with the created role to the bucket. + Adding service account with the created role to the bucket. 1. Next, service account B needs the "Service Account Token Creator" role for service account A. This enables service account B to create short-lived tokens for A. - Go to the **Service Accounts** menu in the Google Cloud Console. - Select service account B from the list, then the **Permissions** tab, and click **Grant Access** under **Principals with access to this service account**. - Enter the name of service account A into the **New principals** box and select "Service Account Token Creator" under the **Assign roles** dropdown. Click **Save** to complete. - Granting service account A access to service account B with the token creator role. + Granting service account A access to service account B with the token creator role. 1. Finally, you will run the bulk operation from your CockroachDB cluster. If you're using [specified authentication](#google-cloud-storage-specified), pass in the GCS bucket's URL with the IAM user's `CREDENTIALS`. If you're using [implicit authentication](#google-cloud-storage-implicit), specify `AUTH=IMPLICIT` instead. For assuming the role, pass the assumed role's service account name, which you can copy from the **Service Accounts** page: @@ -600,13 +600,13 @@ See [Step 2](#step-2-create-the-operation-service-account) to create an operatio b. In the **Grant this service account access to project** section, select the role you require for the bulk operation, e.g., "Storage Object Creator". See [Storage Permissions]({% link {{ page.version.version }}/use-cloud-storage.md %}#storage-permissions) for detail on the minimum permissions required for each operation to complete. Click **Continue**. - Adding the workload identity role to the service account users role box + Adding the workload identity role to the service account users role box c. In the **Grant users access to this service account** section, paste the name of the identity service account. Then, click **Done**. - Adding the workload identity role to the service account users role box + Adding the workload identity role to the service account users role box ### Step 3. Give the identity service account the token creator role @@ -616,7 +616,7 @@ Next, the operation service account needs to contain the "Service Account Token 1. Select the operation service account from the list, then the **Permissions** tab, and click **Grant Access** under **Principals with access to this service account**. 1. Enter the name of the identity service account into the **New principals** box and select "Service Account Token Creator" under the **Assign roles** dropdown. Click **Save** to complete. - Granting the identity service account access to the operation service account with the token creator role. + Granting the identity service account access to the operation service account with the token creator role. ### Step 4. Run the operation by assuming the service account diff --git a/src/current/v25.2/configure-replication-zones.md b/src/current/v25.2/configure-replication-zones.md index 927b5e363f3..090ea83714b 100644 --- a/src/current/v25.2/configure-replication-zones.md +++ b/src/current/v25.2/configure-replication-zones.md @@ -129,7 +129,7 @@ The following diagram presents the same set of schema objects as the previous ou Each box represents a schema object in the zone configuration inheritance hierarchy. Each solid line ends in an arrow that points from a parent object to its child object, which will inherit the parent's values unless those values are changed at the child level. The dotted lines between partitions and sub-partitions represent the known limitation mentioned previously that sub-partitions do not inherit their values from their parent partitions. Instead, sub-partitions inherit their values from the parent table. For more information about this limitation, see [cockroachdb/cockroach#75862](https://github.com/cockroachdb/cockroach/issues/75862). -zone config inheritance diagram +zone config inheritance diagram #### Zone config inheritance - example SQL session diff --git a/src/current/v25.2/data-resilience.md b/src/current/v25.2/data-resilience.md index 27b25203458..aaf0b8ecd8d 100644 --- a/src/current/v25.2/data-resilience.md +++ b/src/current/v25.2/data-resilience.md @@ -9,7 +9,7 @@ CockroachDB provides built-in [**high availability (HA)**](#high-availability) f - HA features ensure continuous access to data without interruption even in the presence of [failures]({% link {{ page.version.version }}/demo-cockroachdb-resilience.md %}) or disruptions to maximize uptime. - DR tools allow for recovery from major incidents to minimize downtime and data loss. -Diagram showing how HA features and DR tools create a resilient CockroachDB deployment. +Diagram showing how HA features and DR tools create a resilient CockroachDB deployment. You can balance required SLAs and recovery objectives with the cost and management of each of these features to build a resilient deployment. diff --git a/src/current/v25.2/datadog.md b/src/current/v25.2/datadog.md index 5c56257e111..7bc20da2645 100644 --- a/src/current/v25.2/datadog.md +++ b/src/current/v25.2/datadog.md @@ -30,7 +30,7 @@ Before you can follow the steps presented in this tutorial, you must have: To enable the CockroachDB check for your installed Datadog Agent, navigate to the [Integrations page](https://app.datadoghq.com/account/settings#integrations) and find CockroachDB in the list of available integrations. Hover over the icon and click **+ Install**. -CockroachDB integration for Datadog installation +CockroachDB integration for Datadog installation Note that you must restart the Datadog Agent for the change to take effect. CockroachDB will then be listed as an installed integration. @@ -122,11 +122,11 @@ cockroachdb (1.6.0) Open your Datadog [Dashboard List](https://app.datadoghq.com/dashboard/lists) and click on `CockroachDB Overview`: -CockroachDB Overview dashboard in Datadog Dashboard List +CockroachDB Overview dashboard in Datadog Dashboard List This sample dashboard presents metrics on cluster availability, query performance, and resource usage: -CockroachDB Overview dashboard for Datadog +CockroachDB Overview dashboard for Datadog {{site.data.alerts.callout_info}} If you wish to customize your CockroachDB dashboard, it's recommended that you clone the default `CockroachDB Overview` dashboard before adding and removing widgets. If you leave the default dashboard intact, Datadog will update it when new versions of the integration's dashboard are released. @@ -152,7 +152,7 @@ cockroach workload run movr --duration=5m 'postgresql://root@localhost:26257?ssl The query metrics will appear on the dashboard: -CockroachDB Overview dashboard for Datadog with SQL metrics +CockroachDB Overview dashboard for Datadog with SQL metrics ## Step 6. Add monitoring and alerting @@ -162,14 +162,14 @@ Select **Threshold Alert** as the detection method. You can use this option to c The example alert below will trigger when [a node has less than 15% of storage capacity remaining]({% link {{ page.version.version }}/monitoring-and-alerting.md %}#node-is-running-low-on-disk-space): -CockroachDB Threshold Alert in Datadog +CockroachDB Threshold Alert in Datadog - `cockroachdb.capacity.available` is divided by `cockroachdb.capacity.total` to determine the fraction of available capacity on the node's [store]({% link {{ page.version.version }}/architecture/storage-layer.md %}) (the directory on each node where CockroachDB reads and writes its data). - The alert threshold is set to `0.15`. The timeseries graph at the top of the page indicates the configured metric and threshold: -CockroachDB Threshold Alert in Datadog +CockroachDB Threshold Alert in Datadog ## Known limitations diff --git a/src/current/v25.2/dbeaver.md b/src/current/v25.2/dbeaver.md index ee645c9ef67..accad7a3811 100644 --- a/src/current/v25.2/dbeaver.md +++ b/src/current/v25.2/dbeaver.md @@ -32,19 +32,19 @@ To work through this tutorial, take the following steps: 1. Start DBeaver, and select **Database > New Connection** from the menu. In the dialog that appears, select **CockroachDB** from the list. - DBeaver - Select CockroachDB + DBeaver - Select CockroachDB 1. Click **Next**. The **Connection Settings** dialog displays. 1. In the **Database** field, enter `movr`. - DBeaver - CockroachDB connection settings + DBeaver - CockroachDB connection settings ## Step 2. Update the connection settings 1. Click the **SSL** tab. - DBeaver - SSL tab + DBeaver - SSL tab 1. Check the **Use SSL** checkbox as shown, and fill in the text areas as follows: - **Root certificate**: Use the `ca.crt` file you generated for your secure cluster. @@ -61,13 +61,13 @@ To work through this tutorial, take the following steps: 1. Click **Test Connection ...**. If you need a driver, the following dialog displays: - DBeaver - download driver dialog + DBeaver - download driver dialog 1. Click **Download**. After the driver downloads, if the connection was successful, you will see a **Connected** dialog. - DBeaver - connection success dialog + DBeaver - connection success dialog 1. Click **OK** to dismiss the dialog. @@ -75,7 +75,7 @@ To work through this tutorial, take the following steps: Expand the **movr** database node and navigate to the **rides** table. -DBeaver - CockroachDB with the movr database +DBeaver - CockroachDB with the movr database For more information about using DBeaver, see the [DBeaver documentation](https://dbeaver.io/docs/). diff --git a/src/current/v25.2/dbmarlin.md b/src/current/v25.2/dbmarlin.md index 4f754a8966c..857dcd188c2 100644 --- a/src/current/v25.2/dbmarlin.md +++ b/src/current/v25.2/dbmarlin.md @@ -50,7 +50,7 @@ Follow the steps in [Instance Dashboard](https://docs.dbmarlin.com/docs/Using-DB When you open the dashboard you'll see : -CockroachDB Overview dashboard for DBmarlin +CockroachDB Overview dashboard for DBmarlin ## See also diff --git a/src/current/v25.2/demo-automatic-cloud-migration.md b/src/current/v25.2/demo-automatic-cloud-migration.md index c3003bd87e8..78950787f84 100644 --- a/src/current/v25.2/demo-automatic-cloud-migration.md +++ b/src/current/v25.2/demo-automatic-cloud-migration.md @@ -171,7 +171,7 @@ Now open the DB Console at `http://localhost:8080` and click **Metrics** in the Scroll down a bit and hover over the **Replicas per Node** graph. Because CockroachDB replicates each piece of data 3 times by default, the replica count on each of your 3 nodes should be identical: -DB Console +DB Console ## Step 7. Add 3 nodes on "cloud 2" @@ -223,7 +223,7 @@ $ cockroach start \ Back on the **Overview** dashboard in DB Console, hover over the **Replicas per Node** graph again. Because you used [`--locality`]({% link {{ page.version.version }}/configure-replication-zones.md %}#descriptive-attributes-assigned-to-nodes) to specify that nodes are running on 2 clouds, you'll see an approximately even number of replicas on each node, indicating that CockroachDB has automatically rebalanced replicas across both simulated clouds: -DB Console +DB Console Note that it takes a few minutes for the DB Console to show accurate per-node replica counts on hover. This is why the new nodes in the screenshot above show 0 replicas. However, the graph lines are accurate, and you can click **View node list** in the **Summary** area for accurate per-node replica counts as well. @@ -242,7 +242,7 @@ $ cockroach sql --execute="ALTER RANGE default CONFIGURE ZONE USING constraints= Back on the **Overview** dashboard in the DB Console, hover over the **Replicas per Node** graph again. Very soon, you'll see the replica count double on nodes 4, 5, and 6 and drop to 0 on nodes 1, 2, and 3: -DB Console +DB Console This indicates that all data has been migrated from cloud 1 to cloud 2. In a real cloud migration scenario, at this point you would update the load balancer to point to the nodes on cloud 2 and then stop the nodes on cloud 1. But for the purpose of this local simulation, there's no need to do that. diff --git a/src/current/v25.2/demo-cockroachdb-resilience.md b/src/current/v25.2/demo-cockroachdb-resilience.md index d07d3f9df57..570398d6bf7 100644 --- a/src/current/v25.2/demo-cockroachdb-resilience.md +++ b/src/current/v25.2/demo-cockroachdb-resilience.md @@ -187,25 +187,25 @@ Initially, the workload creates a new database called `ycsb`, creates the table 1. To check the SQL queries getting executed, click **Metrics** on the left, and hover over the **SQL Statements** graph at the top: - DB Console SQL Statements + DB Console SQL Statements 1. To check the client connections from the load generator, select the **SQL** dashboard and hover over the **Open SQL Sessions** graph: - DB Console Open Sessions + DB Console Open Sessions You'll notice 3 client connections from the load generator. If you want to check that HAProxy balanced each connection to a different node, you can change the **Graph** dropdown from **Cluster** to specific nodes. 1. To see more details about the `ycsb` database and the `public.usertable` table, click **Databases** in the upper left and click **ycsb**: - DB Console Databases + DB Console Databases You can also view the schema and other table details of `public.usertable` by clicking the table name: - DB Console usertable + DB Console usertable 1. By default, CockroachDB replicates all data 3 times and balances it across all nodes. To see this balance, click **Overview** and check the replica count across all nodes: - DB Console Overview + DB Console Overview ## Step 5. Simulate a single node failure @@ -246,7 +246,7 @@ When a node fails, the cluster waits for the node to remain offline for 5 minute Go back to the DB Console, click **Metrics** on the left, and verify that the cluster as a whole continues serving data, despite one of the nodes being unavailable and marked as **Suspect**: -DB Console Suspect Node +DB Console Suspect Node This shows that when all ranges are replicated 3 times (the default), the cluster can tolerate a single node failure because the surviving nodes have a majority of each range's replicas (2/3). @@ -254,7 +254,7 @@ This shows that when all ranges are replicated 3 times (the default), the cluste Click **Overview** on the left: -DB Console Cluster Repair +DB Console Cluster Repair Because you reduced the time it takes for the cluster to consider the down node dead, after 1 minute or so, the cluster will consider the down node "dead", and you'll see the replica count on the remaining nodes increase and the number of under-replicated ranges decrease to 0. This shows the cluster repairing itself by re-replicating missing replicas. @@ -286,7 +286,7 @@ To be able to tolerate 2 of 5 nodes failing simultaneously without any service i 1. In the DB Console **Overview** dashboard, watch the replica count increase and even out across all 6 nodes: - DB Console Cluster Restore + DB Console Cluster Restore This shows the cluster up-replicating so that each range has 5 replicas, one on each node. @@ -303,7 +303,7 @@ kill -TERM {process IDs} 1. Click **Overview** on the left, and verify the state of the cluster: - DB Console Cluster Health + DB Console Cluster Health 1. To verify that the cluster still serves data, use the `cockroach sql` command to interact with the cluster. diff --git a/src/current/v25.2/demo-low-latency-multi-region-deployment.md b/src/current/v25.2/demo-low-latency-multi-region-deployment.md index 2025a5d8c49..62ae55d060d 100644 --- a/src/current/v25.2/demo-low-latency-multi-region-deployment.md +++ b/src/current/v25.2/demo-low-latency-multi-region-deployment.md @@ -121,7 +121,7 @@ node 9: And here is the view on the **Network Latency Page**, which shows which nodes are in which cluster regions: -Geo-partitioning network latency +Geo-partitioning network latency You can see by referring back and forth between `\demo ls` and the **Network Latency Page** that the cluster has the following region/node/port correspondences, which we can use to determine how to connect MovR from various regions: @@ -251,13 +251,13 @@ Now that you have load hitting the cluster from different regions, check how the In the [DB Console]({% link {{ page.version.version }}/ui-overview.md %}) at http://127.0.0.1:8080, click [**Metrics**]({% link {{ page.version.version }}/ui-overview-dashboard.md %}) on the left and hover over the [**Service Latency: SQL, 99th percentile**]({% link {{ page.version.version }}/ui-overview-dashboard.md %}#service-latency-sql-99th-percentile) timeseries graph. You should see the effects of network latency on this workload. -Geo-partitioning SQL latency +Geo-partitioning SQL latency For each of the 3 nodes that you are pointing the movr workload at, the max latency of 99% of queries are in the 1-2 seconds range. The SQL latency is high because of the network latency between regions. To see the network latency between any two nodes in the cluster, click [**Network Latency**]({% link {{ page.version.version }}/ui-network-latency-page.md %}) in the left-hand navigation. -Geo-partitioning network latency +Geo-partitioning network latency Within a single region, round-trip latency is under 6 ms (milliseconds). Across regions, round-trip latency is significantly higher. @@ -314,7 +314,7 @@ As the multi-region schema changes complete, you should see changes to the follo The small demo cluster used in this example is essentially in a state of overload from the start. The performance numbers shown here only reflect the direction of the performance improvements. You should expect to see much better absolute performance numbers than those described here [in a production deployment]({% link {{ page.version.version }}/recommended-production-settings.md %}). {{site.data.alerts.end}} -Geo-partitioning SQL latency +Geo-partitioning SQL latency ## See also diff --git a/src/current/v25.2/demo-serializable.md b/src/current/v25.2/demo-serializable.md index f867f225b6a..246bb904952 100644 --- a/src/current/v25.2/demo-serializable.md +++ b/src/current/v25.2/demo-serializable.md @@ -33,7 +33,7 @@ When write skew happens, a transaction reads something, makes a decision based o ### Schema -Schema for serializable transaction tutorial +Schema for serializable transaction tutorial ## Step 1. Set up the scenario on PostgreSQL diff --git a/src/current/v25.2/deploy-cockroachdb-on-aws.md b/src/current/v25.2/deploy-cockroachdb-on-aws.md index 58f4e2fe26b..c9839932810 100644 --- a/src/current/v25.2/deploy-cockroachdb-on-aws.md +++ b/src/current/v25.2/deploy-cockroachdb-on-aws.md @@ -56,7 +56,7 @@ CockroachDB is supported in all [AWS regions](https://docs.aws.amazon.com/AWSEC2 In this basic deployment, 3 CockroachDB nodes are each deployed on an Amazon EC2 instance across 3 availability zones. These are grouped within a single VPC and security group. Users are routed to the cluster via [Amazon Route 53](https://aws.amazon.com/route53/) (which is not used in this tutorial) and a load balancer. -Architecture diagram for a three-node CockroachDB cluster deployed on AWS +Architecture diagram for a three-node CockroachDB cluster deployed on AWS ## Step 1. Create instances diff --git a/src/current/v25.2/deploy-cockroachdb-with-kubernetes-openshift.md b/src/current/v25.2/deploy-cockroachdb-with-kubernetes-openshift.md index dc5120c6342..89092692536 100644 --- a/src/current/v25.2/deploy-cockroachdb-with-kubernetes-openshift.md +++ b/src/current/v25.2/deploy-cockroachdb-with-kubernetes-openshift.md @@ -67,7 +67,7 @@ This article assumes you have already installed the OpenShift Container Platform 1. Enter "cockroach" in the search box. There are two tiles called **CockroachDB Operator**. Find the tile _without_ the `Marketplace` label (which requires a subscription). - OpenShift OperatorHub + OpenShift OperatorHub Click the **CockroachDB Operator** tile and then **Install**. @@ -93,7 +93,7 @@ This article assumes you have already installed the OpenShift Container Platform 1. In the **CockroachDB Operator** tile, click **Create instance**. - OpenShift OperatorHub + OpenShift OperatorHub 1. Make sure **CockroachDB Version** is set to a valid CockroachDB version. For a list of compatible image names, see `spec.containers.env` in the [pulic operator manifest](https://raw.github.com/cockroachdb/cockroach-operator/v{{ latest_operator_version }}/install/operator.yaml) on GitHub. @@ -101,7 +101,7 @@ This article assumes you have already installed the OpenShift Container Platform 1. Navigate to **Workloads** > **Pods** and observe the pods being created: - OpenShift OperatorHub + OpenShift OperatorHub 1. You can also use the command line to view the pods: @@ -317,7 +317,7 @@ To run a sample [CockroachDB workload]({% link {{ page.version.version }}/cockro 1. Select one of the CockroachDB pods on the **Pods** page and click **Logs**. This will reveal the JDBC URL that your application can use to connect to CockroachDB: - OpenShift OperatorHub + OpenShift OperatorHub ## Step 8. Delete the cluster @@ -327,7 +327,7 @@ If you want to continue using this cluster, see the documentation on [configurin 1. Go to the **Installed Operators** page and find the cluster name of the CockroachDB cluster. Select **Delete CrdbCluster** from the menu. - OpenShift OperatorHub + OpenShift OperatorHub This will delete the CockroachDB cluster being run by the operator. It will *not* delete: diff --git a/src/current/v25.2/detect-hotspots.md b/src/current/v25.2/detect-hotspots.md index 8712d0f4faf..0b18a5ccb2b 100644 --- a/src/current/v25.2/detect-hotspots.md +++ b/src/current/v25.2/detect-hotspots.md @@ -15,7 +15,7 @@ This page provides practical guidance on identifying common [hotspots]({% link { The following sections provide detailed instructions for identifying potential hotspots and applying mitigations. -Troubleshoot hotspots workflow +Troubleshoot hotspots workflow ## Step 1. Check for a node outlier in metrics @@ -27,7 +27,7 @@ To identify a [hotspot]({% link {{ page.version.version }}/understand-hotspots.m 1. Create a custom chart to monitor the `kv.concurrency.latch_conflict_wait_durations-avg` metric, which tracks time spent on [latch acquisition]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#latch-manager) waiting for conflicts with other latches. For example, a [sequence]({% link {{ page.version.version }}/understand-hotspots.md %}#hot-sequence) that writes to the same row must wait to acquire the latch. 1. To display the metric per node, select the `PER NODE/STORE` checkbox as shown: - kv.concurrency.latch_conflict_wait_durations-avg + kv.concurrency.latch_conflict_wait_durations-avg 1. Is there a node with a maximum value that is a clear outlier in the cluster for the latch conflict wait durations metric? - If **Yes**, note the ID of the [hot node]({% link {{ page.version.version }}/understand-hotspots.md %}#hot-node) and the time period when it was hot. Proceed to check for a [`popular key detected `log](#a-popular-key-detected). @@ -39,7 +39,7 @@ To identify a [hotspot]({% link {{ page.version.version }}/understand-hotspots.m 1. Monitor the [**CPU Percent** graph]({% link {{ page.version.version }}/ui-hardware-dashboard.md %}#cpu-percent). CPU usage typically increases with traffic volume. 1. Check if the CPU usage of the hottest node is 20% or more above the cluster average. For example, node `n5`, represented by the green line in the following **CPU Percent** graph, hovers at around 87% at time 17:35 compared to other nodes that hover around 20% to 25%. - graph of CPU Percent utilization per node showing hot key + graph of CPU Percent utilization per node showing hot key 1. Is there a node with a maximum value that is a clear outlier in the cluster for the CPU percent metric? - If **Yes**, note the ID of the [hot node]({% link {{ page.version.version }}/understand-hotspots.md %}#hot-node) and the time period when it was hot. Proceed to check for a [`popular key detected `log](#a-popular-key-detected). diff --git a/src/current/v25.2/disaster-recovery-overview.md b/src/current/v25.2/disaster-recovery-overview.md index e919d0dd4b6..abe5e12903a 100644 --- a/src/current/v25.2/disaster-recovery-overview.md +++ b/src/current/v25.2/disaster-recovery-overview.md @@ -12,7 +12,7 @@ As you evaluate CockroachDB's disaster recovery features, consider your organiza When you use backups, RPO and RTO can be visualized as follows: -Simulating RPO and RTO. With RPO representing the tolerable data loss, and RTO representing the tolerable time to recovery. +Simulating RPO and RTO. With RPO representing the tolerable data loss, and RTO representing the tolerable time to recovery. {{site.data.alerts.callout_info}} For an overview of resiliency features in CockroachDB, refer to [Data Resilience]({% link {{ page.version.version }}/data-resilience.md %}). diff --git a/src/current/v25.2/enable-node-map.md b/src/current/v25.2/enable-node-map.md index 8d8dea4b7b9..d9028d36b53 100644 --- a/src/current/v25.2/enable-node-map.md +++ b/src/current/v25.2/enable-node-map.md @@ -15,7 +15,7 @@ This page guides you through the process of setting up and enabling the Node Map -DB Console +DB Console ## Set up and enable the Node Map @@ -99,17 +99,17 @@ To start a new cluster with the correct `--locality` flags: 1. [Access the DB Console]({% link {{ page.version.version }}/ui-overview.md %}#db-console-access). -1. If the node list displays, click the selector Node map selector and select **Node Map**. +1. If the node list displays, click the selector Node map selector and select **Node Map**. The following page is displayed: -DB Console +DB Console ### Step 2. Set the Enterprise license and refresh the DB Console The Node Map should now be displaying the highest-level localities you defined: -DB Console +DB Console {{site.data.alerts.callout_info}} To be displayed on the world map, localities must be assigned a corresponding latitude and longitude. @@ -140,7 +140,7 @@ For the latitudes and longitudes of AWS, Azure, and Google Cloud regions, see [L Refresh the DB Console to see the updated Node Map: -DB Console +DB Console ### Step 5. Navigate the Node Map @@ -148,11 +148,11 @@ To navigate to Node 2, which is in datacenter `us-east-1a` in the `us-east-1` re 1. Click the map component marked as **region=us-east-1** on the Node Map. The [locality component]({% link {{ page.version.version }}/ui-cluster-overview-page.md %}#locality-component) for the datacenter is displayed. - DB Console + DB Console 1. Click the datacenter component marked as **datacenter=us-east-1a**. The individual [node components]({% link {{ page.version.version }}/ui-cluster-overview-page.md %}#node-component) are displayed. - DB Console + DB Console 1. To navigate back to the cluster view, either click **Cluster** in the breadcrumb trail at the top of the Node Map, or click **Up to REGION=US-EAST-1** and then click **Up to CLUSTER** in the lower left-hand side of the Node Map. @@ -165,7 +165,7 @@ To navigate to Node 2, which is in datacenter `us-east-1a` in the `us-east-1` re To verify all requirements, navigate to the [**Localities**]({% link {{ page.version.version }}/ui-debug-pages.md %}#configuration) debug page in the DB Console. -DB Console +DB Console The **Localities** debug page displays the following: diff --git a/src/current/v25.2/explain.md b/src/current/v25.2/explain.md index 4d7d62e83a1..1d62a9312a3 100644 --- a/src/current/v25.2/explain.md +++ b/src/current/v25.2/explain.md @@ -886,7 +886,7 @@ The output of `EXPLAIN (DISTSQL)` is a URL for a graphical diagram that displays To view the [DistSQL plan diagram]({% link {{ page.version.version }}/explain-analyze.md %}#distsql-plan-diagram), open the URL. You should see the following: -EXPLAIN (DISTSQL) +EXPLAIN (DISTSQL) To include the data types of the input columns in the physical plan, use `EXPLAIN(DISTSQL, TYPES)`: @@ -903,7 +903,7 @@ EXPLAIN (DISTSQL, TYPES) SELECT l_shipmode, AVG(l_extendedprice) FROM lineitem G Open the URL. You should see the following: -EXPLAIN (DISTSQL) +EXPLAIN (DISTSQL) ### Find the indexes and key ranges a query uses diff --git a/src/current/v25.2/geojson.md b/src/current/v25.2/geojson.md index 859223f7ad1..6ee553e9f0c 100644 --- a/src/current/v25.2/geojson.md +++ b/src/current/v25.2/geojson.md @@ -189,7 +189,7 @@ The JSON below is modified from the output above: it is grouped into a GeoJSON ` Here is the geometry described above as shown on [geojson.io](http://geojson.io): -GeoJSON.io output +GeoJSON.io output ## See also diff --git a/src/current/v25.2/geoserver.md b/src/current/v25.2/geoserver.md index 8753fd6be84..27371d9d2c6 100644 --- a/src/current/v25.2/geoserver.md +++ b/src/current/v25.2/geoserver.md @@ -174,7 +174,7 @@ In the row for the `roads` layer, click the **OpenLayers** button under the **Co Your browser should open a new tab with the title **OpenLayers map preview**. It should show a map view that looks like the following: -GeoServer U.S. National Atlas preview +GeoServer U.S. National Atlas preview ## See also diff --git a/src/current/v25.2/how-does-a-changefeed-work.md b/src/current/v25.2/how-does-a-changefeed-work.md index b58be3b1303..092fdd37972 100644 --- a/src/current/v25.2/how-does-a-changefeed-work.md +++ b/src/current/v25.2/how-does-a-changefeed-work.md @@ -9,7 +9,7 @@ When a changefeed that will emit changes to a sink is started on a node, that no Each node uses its _aggregator processors_ to send back checkpoint progress to the coordinator, which gathers this information to update the _high-water mark timestamp_. The high-water mark acts as a checkpoint for the changefeed’s job progress, and guarantees that all changes before (or at) the timestamp have been emitted. In the unlikely event that the changefeed’s coordinating node were to fail during the job, that role will move to a different node and the changefeed will restart from the last checkpoint. If restarted, the changefeed may [re-emit messages]({% link {{ page.version.version }}/changefeed-messages.md %}#duplicate-messages) starting at the high-water mark time to the current time. Refer to [Ordering Guarantees]({% link {{ page.version.version }}/changefeed-messages.md %}#ordering-and-delivery-guarantees) for detail on CockroachDB's at-least-once-delivery-guarantee and how per-key message ordering is applied. -Changefeed process in a 3-node cluster +Changefeed process in a 3-node cluster With [`resolved`]({% link {{ page.version.version }}/create-changefeed.md %}#resolved) specified when a changefeed is started, the coordinator will send the resolved timestamp (i.e., the high-water mark) to each endpoint in the sink. For example, when using [Kafka]({% link {{ page.version.version }}/changefeed-sinks.md %}#kafka) this will be sent as a message to each partition; for [cloud storage]({% link {{ page.version.version }}/changefeed-sinks.md %}#cloud-storage-sink), this will be emitted as a resolved timestamp file. diff --git a/src/current/v25.2/kibana.md b/src/current/v25.2/kibana.md index ba125267c27..9f0a21d850f 100644 --- a/src/current/v25.2/kibana.md +++ b/src/current/v25.2/kibana.md @@ -83,11 +83,11 @@ Open the Kibana web interface and click **Dashboard**. Search for the CockroachDB dashboard: -CockroachDB dashboard selection for Metricbeat +CockroachDB dashboard selection for Metricbeat Click the dashboard title to open the dashboard, which presents metrics on replicas and query performance: -CockroachDB Overview dashboard for Metricbeat +CockroachDB Overview dashboard for Metricbeat ## Step 4. Run a sample workload @@ -109,7 +109,7 @@ cockroach workload run movr --duration=5m 'postgresql://root@localhost:26257?ssl Click **Refresh**. The query metrics will appear on the dashboard: -CockroachDB Overview dashboard for Metricbeat with SQL metrics +CockroachDB Overview dashboard for Metricbeat with SQL metrics ## See also diff --git a/src/current/v25.2/log-sql-activity-to-datadog.md b/src/current/v25.2/log-sql-activity-to-datadog.md index 1e6b9eddf43..103a75e8930 100644 --- a/src/current/v25.2/log-sql-activity-to-datadog.md +++ b/src/current/v25.2/log-sql-activity-to-datadog.md @@ -145,7 +145,7 @@ Each `sampled_query` and `sampled_transaction` event has an `event.TransactionID 1. Navigate to [**Datadog > Logs**](https://app.datadoghq.com/logs). 1. Search for `@event.EventType:(sampled_query OR sampled_transaction)` to see the logs for the query and transaction events that are emitted. For example: -Datadog Telemetry Logs +Datadog Telemetry Logs ## See also diff --git a/src/current/v25.2/logical-data-replication-overview.md b/src/current/v25.2/logical-data-replication-overview.md index 84d134883ee..2ec95433be4 100644 --- a/src/current/v25.2/logical-data-replication-overview.md +++ b/src/current/v25.2/logical-data-replication-overview.md @@ -29,13 +29,13 @@ For a comparison of CockroachDB high availability and resilience features and to Maintain [high availability]({% link {{ page.version.version }}/data-resilience.md %}#high-availability) and resilience to region failures with a two-datacenter topology. You can run bidirectional LDR to ensure [data resilience]({% link {{ page.version.version }}/data-resilience.md %}) in your deployment, particularly in datacenter or region failures. If you set up two single-region clusters, in LDR, both clusters can receive application reads and writes with low, single-region write latency. Then, in a datacenter, region, or cluster outage, you can redirect application traffic to the surviving cluster with [low downtime]({% link {{ page.version.version }}/data-resilience.md %}#high-availability). In the following diagram, the two single-region clusters are deployed in US East and West to provide low latency for that region. The two LDR jobs ensure that the tables on both clusters will reach eventual consistency. -Diagram showing bidirectional LDR from cluster A to B and back again from cluster B to A. +Diagram showing bidirectional LDR from cluster A to B and back again from cluster B to A. ### Achieve workload isolation between clusters Isolate critical application workloads from non-critical application workloads. For example, you may want to run jobs like [changefeeds]({% link {{ page.version.version }}/change-data-capture-overview.md %}) or [backups]({% link {{ page.version.version }}/backup-and-restore-overview.md %}) from one cluster to isolate these jobs from the cluster receiving the principal application traffic. -Diagram showing unidirectional LDR from a source cluster to a destination cluster with the destination cluster supporting secondary workloads plus jobs and the source cluster accepting the main application traffic. +Diagram showing unidirectional LDR from a source cluster to a destination cluster with the destination cluster supporting secondary workloads plus jobs and the source cluster accepting the main application traffic. ## Features diff --git a/src/current/v25.2/map-sql-activity-to-app.md b/src/current/v25.2/map-sql-activity-to-app.md index 13723f18c88..51d9c4953d0 100644 --- a/src/current/v25.2/map-sql-activity-to-app.md +++ b/src/current/v25.2/map-sql-activity-to-app.md @@ -22,7 +22,7 @@ SET application_name = movr_app; Once you set the application name, the [DB Console]({% link {{ page.version.version }}/ui-overview.md %}) lets you [filter database workloads by application name]({% link {{ page.version.version }}/ui-statements-page.md %}#filter). -Movr app filter +Movr app filter If parts of your applications or known microservices are experiencing performance degradation, you can filter for the database workload tracing statements and transactions back to that part of your application directly in the DB Console. You can quickly identify whether there were database performance problems and if so, troubleshoot the issue using [SQL observability touch points](#trace-sql-activity-using-metrics) in the DB Console. diff --git a/src/current/v25.2/monitor-and-analyze-transaction-contention.md b/src/current/v25.2/monitor-and-analyze-transaction-contention.md index bb64dc6d370..161ab78ea83 100644 --- a/src/current/v25.2/monitor-and-analyze-transaction-contention.md +++ b/src/current/v25.2/monitor-and-analyze-transaction-contention.md @@ -40,7 +40,7 @@ In the DB Console, in the cluster view, this rate is averaged across all nodes, The following image from the DB Console was taken from a cluster running more than 50,000 queries per second with around 2 contention events per second. This contention is unlikely to have an impact on the workload. -DB Console SQL Statement Contention graph +DB Console SQL Statement Contention graph ### SQL Activity pages @@ -54,7 +54,7 @@ The [**Contention Time** column]({% link {{ page.version.version }}/ui-statement The following image shows the **Statements** page with the top 3 statement fingerprints by Contention Time in a cluster containing the test data from the [Analyze using `crdb_internal` tables](#analyze-using-crdb_internal-tables) section. -Statements page by Contention Time +Statements page by Contention Time #### Transactions page @@ -64,7 +64,7 @@ The [**Contention Time** column]({% link {{ page.version.version }}/ui-transacti The following image shows the **Transactions** page with the top 3 transactions fingerprints by Contention Time in a cluster containing the test data in the [Analyze using `crdb_internal` tables](#analyze-using-crdb_internal-tables) section. -Transactions page by Contention Time +Transactions page by Contention Time ### Insights page @@ -377,15 +377,15 @@ This section applies a variation of the previously described analysis process to Review the [DB Console Metrics]({% link {{ page.version.version }}/ui-overview.md %}#metrics) graphs to get a high-level understanding of the contention events. The [SQL Statement Errors]({% link {{ page.version.version }}/ui-sql-dashboard.md %}#sql-statement-errors) graph shows an increase of errors during the time period of 9:16 to 9:23 UTC: -DB Console SQL Statement Errors graph +DB Console SQL Statement Errors graph The [SQL Statement Contention]({% link {{ page.version.version }}/ui-sql-dashboard.md %}#sql-statement-contention) graph shows a corresponding increase between 9:16 and 9:23 UTC: -DB Console SQL Statement Contention graph +DB Console SQL Statement Contention graph The [Transaction Restarts]({% link {{ page.version.version }}/ui-sql-dashboard.md %}#transaction-restarts) graph also shows a corresponding increase between 9:16 and 9:23 UTC: -DB Console Transaction Restarts graph +DB Console Transaction Restarts graph These graphs help to understand the incident at a high-level, but not the specific transactions that are involved. To understand that, query the `crdb_internal.transaction_contention_events` table. diff --git a/src/current/v25.2/monitor-cockroachdb-kubernetes.md b/src/current/v25.2/monitor-cockroachdb-kubernetes.md index da454617282..546154511e5 100644 --- a/src/current/v25.2/monitor-cockroachdb-kubernetes.md +++ b/src/current/v25.2/monitor-cockroachdb-kubernetes.md @@ -167,11 +167,11 @@ If you're on Hosted GKE, before starting, make sure the email address associated 1. To verify that each CockroachDB node is connected to Prometheus, go to **Status > Targets**. The screen should look like this: - Prometheus targets + Prometheus targets 1. To verify that data is being collected, go to **Graph**, enter the `sys_uptime` variable in the field, click **Execute**, and then click the **Graph** tab. The screen should like this: - Prometheus graph + Prometheus graph {{site.data.alerts.callout_success}} Prometheus auto-completes CockroachDB time series metrics for you, but if you want to see a full listing, with descriptions, port-forward as described in {% if page.secure == true %}[Access the DB Console]({% link {{ page.version.version }}/deploy-cockroachdb-with-kubernetes.md %}#step-4-access-the-db-console){% else %}[Access the DB Console]({% link {{ page.version.version }}/deploy-cockroachdb-with-kubernetes.md %}#step-4-access-the-db-console){% endif %} and then point your browser to http://localhost:8080/_status/vars. @@ -242,11 +242,11 @@ Active monitoring helps you spot problems early, but it is also essential to sen 1. Go to http://localhost:9093 in your browser. The screen should look like this: - Alertmanager + Alertmanager 1. Ensure that the Alertmanagers are visible to Prometheus by opening http://localhost:9090/status. The screen should look like this: - Alertmanager + Alertmanager 1. Add CockroachDB's starter [alerting rules](https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/prometheus/alert-rules.yaml): @@ -262,11 +262,11 @@ Active monitoring helps you spot problems early, but it is also essential to sen 1. Ensure that the rules are visible to Prometheus by opening http://localhost:9090/rules. The screen should look like this: - Alertmanager + Alertmanager 1. Verify that the `TestAlertManager` example alert is firing by opening http://localhost:9090/alerts. The screen should look like this: - Alertmanager + Alertmanager 1. To remove the example alert: diff --git a/src/current/v25.2/monitor-cockroachdb-operator.md b/src/current/v25.2/monitor-cockroachdb-operator.md index 86cd625d29f..6db92afa1e9 100644 --- a/src/current/v25.2/monitor-cockroachdb-operator.md +++ b/src/current/v25.2/monitor-cockroachdb-operator.md @@ -105,11 +105,11 @@ If you're on Hosted GKE, before starting, make sure the email address associated 1. To verify that each CockroachDB node is connected to Prometheus, go to **Status > Targets**. The screen should look like this: - Prometheus targets + Prometheus targets 1. To verify that data is being collected, go to **Graph**, enter the `sys_uptime` variable in the field, click **Execute**, and then click the **Graph** tab. The screen should like this: - Prometheus graph + Prometheus graph {{site.data.alerts.callout_info}} Prometheus auto-completes CockroachDB time series metrics for you, but if you want to see a full listing, with descriptions, port-forward as described in [Access the DB Console]({% link {{ page.version.version }}/deploy-cockroachdb-with-cockroachdb-operator.md %}#step-4-access-the-db-console) and then point your browser to [http://localhost:8080/_status/vars](http://localhost:8080/_status/vars). @@ -174,11 +174,11 @@ Active monitoring helps you spot problems early, but it is also essential to sen 1. Go to [http://localhost:9093](http://localhost:9093/) in your browser. The screen should look like this: - Alertmanager + Alertmanager 1. Ensure that the Alertmanagers are visible to Prometheus by opening [http://localhost:9090/status](http://localhost:9090/status). The screen should look like this: - Alertmanager + Alertmanager 1. Add CockroachDB's starter [alerting rules](https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/prometheus/alert-rules.yaml): @@ -193,11 +193,11 @@ Active monitoring helps you spot problems early, but it is also essential to sen 1. Ensure that the rules are visible to Prometheus by opening [http://localhost:9090/rules](http://localhost:9090/rules). The screen should look like this: - Alertmanager + Alertmanager 1. Verify that the `TestAlertManager` example alert is firing by opening [http://localhost:9090/alerts](http://localhost:9090/alerts). The screen should look like this: - Alertmanager + Alertmanager 1. To remove the example alert: 1. Use the `kubectl edit` command to open the rules for editing: diff --git a/src/current/v25.2/monitoring-and-alerting.md b/src/current/v25.2/monitoring-and-alerting.md index 5a5816fb1b3..a499632b1e7 100644 --- a/src/current/v25.2/monitoring-and-alerting.md +++ b/src/current/v25.2/monitoring-and-alerting.md @@ -143,7 +143,7 @@ The `/_status/vars` metrics endpoint is in Prometheus format and is not deprecat Several endpoints return raw status meta information in JSON at `http://:/#/debug`. You can investigate and use these endpoints, but note that they are subject to change. -Raw Status Endpoints +Raw Status Endpoints ### Node status command diff --git a/src/current/v25.2/node-shutdown.md b/src/current/v25.2/node-shutdown.md index d924e112d5c..77b6adb1936 100644 --- a/src/current/v25.2/node-shutdown.md +++ b/src/current/v25.2/node-shutdown.md @@ -311,25 +311,25 @@ This can lead to disk utilization imbalance across nodes. **This is expected beh In this scenario, each range is replicated 3 times, with each replica on a different node: -
Decommission Scenario 1
+
Decommission Scenario 1
If you try to decommission a node, the process will hang indefinitely because the cluster cannot move the decommissioning node's replicas to the other 2 nodes, which already have a replica of each range: -
Decommission Scenario 1
+
Decommission Scenario 1
To successfully decommission a node in this cluster, you need to **add a 4th node**. The decommissioning process can then complete: -
Decommission Scenario 1
+
Decommission Scenario 1
#### 5-node cluster with 3-way replication In this scenario, like in the scenario above, each range is replicated 3 times, with each replica on a different node: -
Decommission Scenario 1
+
Decommission Scenario 1
If you decommission a node, the process will run successfully because the cluster will be able to move the node's replicas to other nodes without doubling up any range replicas: -
Decommission Scenario 1
+
Decommission Scenario 1
diff --git a/src/current/v25.2/performance-benchmarking-with-tpcc-large.md b/src/current/v25.2/performance-benchmarking-with-tpcc-large.md index daa4accbb6b..d24ab1d97ce 100644 --- a/src/current/v25.2/performance-benchmarking-with-tpcc-large.md +++ b/src/current/v25.2/performance-benchmarking-with-tpcc-large.md @@ -197,7 +197,7 @@ CockroachDB comes with a number of [built-in workloads]({% link {{ page.version. - To monitor the number of lease transfers, open the [DB Console]({% link {{ page.version.version }}/ui-overview.md %}), select the **Replication** dashboard, hover over the **Range Operations** graph, and check the **Lease Transfers** data point. - To check the number of snapshots, open the [DB Console]({% link {{ page.version.version }}/ui-overview.md %}), select the **Replication** dashboard, and hover over the **Snapshots** graph. - TPC-C 140k replication and partitioning dashboards + TPC-C 140k replication and partitioning dashboards ## Step 7. Allocate partitions diff --git a/src/current/v25.2/performance-recipes.md b/src/current/v25.2/performance-recipes.md index 1758d395baa..bd756e2fabe 100644 --- a/src/current/v25.2/performance-recipes.md +++ b/src/current/v25.2/performance-recipes.md @@ -113,7 +113,7 @@ These are indicators that lock contention occurred in the past: {{site.data.alerts.end}} - The **SQL Statement Contention** graph ([CockroachDB {{ site.data.products.cloud }} Console]({% link cockroachcloud/metrics-sql.md %}#sql-statement-contention) and [DB Console]({% link {{ page.version.version }}/ui-sql-dashboard.md %}#sql-statement-contention)) is showing spikes over time. - SQL Statement Contention graph in DB Console + SQL Statement Contention graph in DB Console If a long-running transaction is waiting due to [lock contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention): @@ -150,7 +150,7 @@ When running under `SERIALIZABLE` isolation, implement [client-side retry handli If you see many waiting transactions, a single long-running transaction may be blocking transactions that are, in turn, blocking others. In this case, sort the table by **Time Spent Waiting** to find the transaction that has been waiting for the longest amount of time. Unblocking this transaction may unblock the other transactions. {{site.data.alerts.end}} Click the transaction's execution ID and view the following transaction execution details: - Movr rides transactions + Movr rides transactions - **Last Retry Reason** shows the last [transaction retry error](#transaction-retry-error) received for the transaction, if applicable. - The details of the **blocking** transaction, directly below the **Contention Insights** section. Click the blocking transaction to view its details. @@ -158,7 +158,7 @@ When running under `SERIALIZABLE` isolation, implement [client-side retry handli 1. [Identify the **blocking** transaction](#identify-conflicting-transactions) and view its transaction execution details. 1. Click its **Session ID** to open the **Session Details** page. - Sessions Details Page + Sessions Details Page 1. Click **Cancel Statement** to cancel the **Most Recent Statement** and thus the transaction, or click **Cancel Session** to cancel the session issuing the transaction. ##### Identify transactions and objects that experienced lock contention @@ -294,7 +294,7 @@ If the [Overview dashboard]({% link {{ page.version.version }}/ui-overview-dashb In the DB Console, the [Tables List Tab]({% link {{ page.version.version }}/ui-databases-page.md %}#tables-list-tab) of the [Database Details Page]({% link {{ page.version.version }}/ui-databases-page.md %}#database-details-page) for a given database shows the percentage of live data for each table. For example: -Table live data +Table live data In this example, at `37.3%` the `vehicles` table would be considered to have a low percentage of live data. In the worst cases, the percentage can be `0%`. diff --git a/src/current/v25.2/performance.md b/src/current/v25.2/performance.md index 2d19619a625..249ac9abbc4 100644 --- a/src/current/v25.2/performance.md +++ b/src/current/v25.2/performance.md @@ -22,7 +22,7 @@ For a refresher on what exactly TPC-C is and how it is measured, see [Benchmark CockroachDB achieves this performance in [`SERIALIZABLE` isolation]({% link {{ page.version.version }}/demo-serializable.md %}), the strongest isolation level in the SQL standard. -TPC-C 140,000 +TPC-C 140,000 | Metric | CockroachDB 19.2 | CockroachDB 21.1 | |-------------------------------------------------+------------------+------------------| @@ -37,7 +37,7 @@ CockroachDB achieves this performance in [`SERIALIZABLE` isolation]({% link {{ p CockroachDB has **no theoretical scaling limit** and, in practice, can achieve near-linear performance at 256 nodes. Because the TPC-C results reflect leaps in scale, to test linear scaling, Cockroach Labs ran a simple benchmark named KV 95 (95% point reads, 5% point writes, all uniformly distributed) on AWS `c5d.4xlarge` machines: -CRDB Linear Scale +CRDB Linear Scale This chart shows that adding nodes increases throughput linearly while holding p50 and p99 latency constant. The concurrency for each scale was chosen to optimize throughput while maintaining an acceptable latency and can be observed in the following table. diff --git a/src/current/v25.2/physical-cluster-replication-technical-overview.md b/src/current/v25.2/physical-cluster-replication-technical-overview.md index 897b4ad6205..1f0d79af063 100644 --- a/src/current/v25.2/physical-cluster-replication-technical-overview.md +++ b/src/current/v25.2/physical-cluster-replication-technical-overview.md @@ -27,7 +27,7 @@ The stream initialization proceeds as follows: 1. The initial scan runs on the primary and backfills all data from the primary virtual cluster as of the starting timestamp of the replication stream. 1. Once the initial scan is complete, the primary then begins streaming all changes from the point of the starting timestamp. -Two virtualized clusters with system virtual cluster and application virtual cluster showing the directional stream. +Two virtualized clusters with system virtual cluster and application virtual cluster showing the directional stream. #### Start-up sequence with read on standby @@ -55,7 +55,7 @@ If the primary cluster does not receive replicated time information from the sta The tracked replicated time and the advancing protected timestamp allow the replication stream to also track _retained time_, which is a timestamp in the past indicating the lower bound that the replication stream could fail over to. The retained time can be up to 4 hours in the past, due to the protected timestamp. Therefore, the _failover window_ for a replication job falls between the retained time and the replicated time. -Timeline showing how the failover window is between the retained time and replicated time. +Timeline showing how the failover window is between the retained time and replicated time. _Replication lag_ is the time between the most up-to-date replicated time and the actual time. While the replication keeps as current as possible to the actual time, this replication lag window is where there is potential for data loss. diff --git a/src/current/v25.2/query-behavior-troubleshooting.md b/src/current/v25.2/query-behavior-troubleshooting.md index c810f6dfc8d..f29c033c25c 100644 --- a/src/current/v25.2/query-behavior-troubleshooting.md +++ b/src/current/v25.2/query-behavior-troubleshooting.md @@ -58,23 +58,23 @@ You can look more closely at the behavior of a statement by visualizing a [state 1. Click **JSON File** in the Jaeger UI and upload `trace-jaeger.json` from the diagnostics bundle. The trace will appear in the list on the right. - Jaeger Trace Upload JSON + Jaeger Trace Upload JSON 1. Click the trace to view its details. It is visualized as a collection of spans with timestamps. These may include operations executed by different nodes. - Jaeger Trace Spans + Jaeger Trace Spans The full timeline displays the execution time and [execution phases]({% link {{ page.version.version }}/architecture/sql-layer.md %}#sql-parser-planner-executor) for the statement. 1. Click a span to view details for that span and log messages. - Jaeger Trace Log Messages + Jaeger Trace Log Messages 1. You can troubleshoot [transaction contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention), for example, by gathering [diagnostics]({% link {{ page.version.version }}/ui-statements-page.md %}#diagnostics) on statements with high latency and looking through the log messages in `trace-jaeger.json` for jumps in latency. In the following example, the trace shows that there is significant latency between a push attempt on a transaction that is holding a [lock]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#writing) (56.85ms) and that transaction being committed (131.37ms). - Jaeger Trace Log Messages + Jaeger Trace Log Messages #### Visualize traces sent directly from CockroachDB @@ -93,7 +93,7 @@ Enabling full tracing is expensive both in terms of CPU usage and memory footpri 1. Go to [`http://localhost:16686`](http://localhost:16686). 1. In the Service field, select **CockroachDB**. - Jaeger Trace Log Messages + Jaeger Trace Log Messages 1. Click **Find Traces**. diff --git a/src/current/v25.2/query-spatial-data.md b/src/current/v25.2/query-spatial-data.md index 572c3d1a1a1..678918809cc 100644 --- a/src/current/v25.2/query-spatial-data.md +++ b/src/current/v25.2/query-spatial-data.md @@ -279,7 +279,7 @@ We can see that almost half of all of the tornadoes in this outbreak began in Ok It might be interesting to draw these points on a map. The image below shows the points from the query above drawn as a simple polygon on a map of Oklahoma. The boxes around the polygon show the [spatial index]({% link {{ page.version.version }}/spatial-indexes.md %}) coverings for the polygon. -1999 Oklahoma tornado outbreak map view +1999 Oklahoma tornado outbreak map view (Map data © 2020 Google) diff --git a/src/current/v25.2/secure-a-cluster.md b/src/current/v25.2/secure-a-cluster.md index e2819037b89..c54abe3d4a4 100644 --- a/src/current/v25.2/secure-a-cluster.md +++ b/src/current/v25.2/secure-a-cluster.md @@ -309,7 +309,7 @@ The CockroachDB [DB Console]({% link {{ page.version.version }}/ui-overview.md % 1. On the [**Cluster Overview**]({% link {{ page.version.version }}/ui-cluster-overview-page.md %}), notice that three nodes are live, with an identical replica count on each node: - DB Console + DB Console This demonstrates CockroachDB's [automated replication]({% link {{ page.version.version }}/demo-replication-and-rebalancing.md %}) of data via the Raft consensus protocol. @@ -319,7 +319,7 @@ The CockroachDB [DB Console]({% link {{ page.version.version }}/ui-overview.md % 1. Click [**Metrics**]({% link {{ page.version.version }}/ui-overview-dashboard.md %}) to access a variety of time series dashboards, including graphs of SQL queries and service latency over time: - DB Console + DB Console 1. Use the [**Databases**]({% link {{ page.version.version }}/ui-databases-page.md %}), [**Statements**]({% link {{ page.version.version }}/ui-statements-page.md %}), and [**Jobs**]({% link {{ page.version.version }}/ui-jobs-page.md %}) pages to view details about your databases and tables, to assess the performance of specific queries, and to monitor the status of long-running operations like schema changes, respectively. @@ -349,7 +349,7 @@ The CockroachDB [DB Console]({% link {{ page.version.version }}/ui-overview.md % 1. Back in the DB Console, despite one node being "suspect", notice the continued SQL traffic: - DB Console + DB Console 1. Restart node 3: @@ -393,7 +393,7 @@ Adding capacity is as simple as starting more nodes with `cockroach start`. 1. Back on the **Cluster Overview** in the DB Console, you'll now see 5 nodes listed: - DB Console + DB Console At first, the replica count will be lower for nodes 4 and 5. Very soon, however, you'll see those numbers even out across all nodes, indicating that data is being [automatically rebalanced]({% link {{ page.version.version }}/demo-replication-and-rebalancing.md %}) to utilize the additional capacity of the new nodes. diff --git a/src/current/v25.2/set-up-logical-data-replication.md b/src/current/v25.2/set-up-logical-data-replication.md index 4c681b8bf0c..79f27ffb6c6 100644 --- a/src/current/v25.2/set-up-logical-data-replication.md +++ b/src/current/v25.2/set-up-logical-data-replication.md @@ -15,7 +15,7 @@ In this tutorial, you will set up [**logical data replication (LDR)**]({% link { In the following diagram, **LDR stream 1** creates a unidirectional LDR setup. Introducing **LDR stream 2** extends the setup to bidirectional. -Diagram showing bidirectional LDR from cluster A to B and back again from cluster B to A. +Diagram showing bidirectional LDR from cluster A to B and back again from cluster B to A. For more details on use cases, refer to the [Logical Data Replication Overview]({% link {{ page.version.version }}/logical-data-replication-overview.md %}). diff --git a/src/current/v25.2/show-trace.md b/src/current/v25.2/show-trace.md index a7dbeac0131..44b96c85267 100644 --- a/src/current/v25.2/show-trace.md +++ b/src/current/v25.2/show-trace.md @@ -48,7 +48,7 @@ Concept | Description Consider a visualization of a trace for one statement as [visualized by Jaeger]({% link {{ page.version.version }}/query-behavior-troubleshooting.md %}#visualize-statement-traces-in-jaeger). The image shows spans and log messages. You can see names of operations and sub-operations, along with parent-child relationships and timing information, and it's easy to see which operations are executed in parallel. -Jaeger Trace Log Messages +Jaeger Trace Log Messages ## Response diff --git a/src/current/v25.2/spatial-indexes.md b/src/current/v25.2/spatial-indexes.md index 8847faff652..23addd83816 100644 --- a/src/current/v25.2/spatial-indexes.md +++ b/src/current/v25.2/spatial-indexes.md @@ -56,15 +56,15 @@ Whichever approach to indexing is used, when an object is indexed, a "covering" Under the hood, CockroachDB uses the [S2 geometry library](https://s2geometry.io/) to divide the space being indexed into a [quadtree](https://wikipedia.org/wiki/Quadtree) data structure with a set number of levels and a data-independent shape. Each node in the quadtree (really, [S2 cell](https://s2geometry.io/devguide/s2cell_hierarchy.html)) represents some part of the indexed space and is divided once horizontally and once vertically to produce 4 child cells in the next level. The following image shows visually how a location (marked in red) is represented using levels of a quadtree: -Quadtree +Quadtree Visually, you can think of the S2 library as enclosing a sphere in a cube. We map from points on each face of the cube to points on the face of the sphere. As you can see in the following 2-dimensional picture, there is a projection that occurs in this mapping: the lines entering from the left mark points on the cube face, and are "refracted" by the material of the cube face before touching the surface of the sphere. This projection reduces the distortion that would occur if the points on the cube face were projected straight onto the sphere. -S2 Cubed Sphere - 2D +S2 Cubed Sphere - 2D Next, let's look at a 3-dimensional image that shows the cube and sphere more clearly. Each cube face is mapped to the quadtree data structure mentioned, and each node in the quadtree is numbered using a [Hilbert space-filling curve](https://wikipedia.org/wiki/Hilbert_curve) which preserves locality of reference. In the following image, you can imagine the points of the Hilbert curve on the rear face of the cube being projected onto the sphere in the center. The use of a space-filling curve means that two shapes that are near each other on the sphere are very likely to be near each other on the line that makes up the Hilbert curve. This is good for performance. -S2 Cubed Sphere - 3D +S2 Cubed Sphere - 3D When you index a spatial object, a covering is computed using some number of the cells in the quadtree. The number of covering cells can vary per indexed object by passing special arguments to `CREATE INDEX` that tell CockroachDB how many levels of S2 cells to use. The leaf nodes of the S2 quadtree are at level 30, and for `GEOGRAPHY` measure 1cm across the Earth's surface. By default, `GEOGRAPHY` indexes use up to level 30, and get this level of precision. We also use S2 cell coverings in a slightly different way for `GEOMETRY` indexes. The precision you get there is the bounding length of the `GEOMETRY` index divided by 4^30. For more information, see [Tuning spatial indexes](#tuning-spatial-indexes). @@ -99,11 +99,11 @@ We will generate coverings for the following geometry object, which describes a The animated following image shows the S2 coverings that are generated as we increase the `s2_max_cells` parameter from the 1 to 30 (minimum to maximum): -Animated GIF of S2 Coverings - Levels 1 to 30 +Animated GIF of S2 Coverings - Levels 1 to 30 Here are the same images presented in a grid. You can see that as we turn up the `s2_max_cells` parameter, more work is done by CockroachDB to discover a tighter and tighter covering (that is, a covering using more and smaller cells). The covering for this particular shape reaches a reasonable level of accuracy when `s2_max_cells` reaches 10, and stops improving much past 12. -Static image of S2 Coverings - Levels 1 to 30 +Static image of S2 Coverings - Levels 1 to 30 ### Index tuning parameters @@ -149,7 +149,7 @@ SELECT ST_AsGeoJSON(st_collect(geom)) FROM tmp_viz; When you paste the JSON output into [geojson.io](http://geojson.io), it generates the following picture, which shows both the `LINESTRING` and its S2 covering based on the options you passed to `st_s2covering`. -S2 LINESTRING example covering +S2 LINESTRING example covering ### Create a spatial index diff --git a/src/current/v25.2/spatial-tutorial.md b/src/current/v25.2/spatial-tutorial.md index a2f0e59af87..47dfc97568c 100644 --- a/src/current/v25.2/spatial-tutorial.md +++ b/src/current/v25.2/spatial-tutorial.md @@ -158,7 +158,7 @@ FROM Paste the result above into and you should see the following map, with gray markers for each loon sighting from the bird survey. -Common Loon sightings in the years 2000-2019 in NY state +Common Loon sightings in the years 2000-2019 in NY state ### (2) What is the total area of Loon sightings? @@ -561,7 +561,7 @@ WHERE Paste the result above into and you should see the following map: -Convex hull of bookstore locations within Common Loon habitat +Convex hull of bookstore locations within Common Loon habitat ### (10) What is the area of the shape of all bookstore locations that are in the Loon's habitat range within NY state? @@ -702,7 +702,7 @@ The result is a very large chunk of JSON: Paste the result above into and you should see the following map: -What does the route from Mysteries on Main Street in Johnstown, NY to The Book Nook in Saranac Lake, NY look like? +What does the route from Mysteries on Main Street in Johnstown, NY to The Book Nook in Saranac Lake, NY look like? ### (13) What were the 25 most-commonly-sighted birds in 2019 within 10 miles of the route between Mysteries on Main Street in Johnstown, NY and The Bookstore Plus in Lake Placid, NY? @@ -1687,7 +1687,7 @@ The `tutorial` database contains the following tables: Below is an entity-relationship diagram showing the `bookstores` and `bookstore_routes` tables (generated using [DBeaver]({% link {{ page.version.version }}/dbeaver.md %})): -tutorial.bookstores and tutorial.bookstore_routes ER diagrams +tutorial.bookstores and tutorial.bookstore_routes ER diagrams As mentioned above, the `bookstores` table was created by scraping web data from the [American Booksellers Association website's member directory](https://bookweb.org/member_directory/search/ABAmember). In addition, the `geom` column was constructed by doing some [address geocoding](https://wikipedia.org/wiki/Address_geocoding) that converted each bookstore's address to a lon/lat pair and converted to a spatial object using `ST_MakePoint`. For each bookstore, the script did a bit of parsing and geocoding and ran essentially the following query: @@ -1751,7 +1751,7 @@ There are multiple ways to do geocoding. You can use REST API-based services or Meanwhile, the `roads` table has many columns; the most important ones used in this tutorial are `state`, `geom`, `miles`, and `prime_name` (the human-readable name of the road). -tutorial.roads ER diagrams +tutorial.roads ER diagrams For more information about what the other columns in `roads` mean, see the [full data set description](https://www.sciencebase.gov/catalog/file/get/581d052be4b08da350d524ce?f=__disk__60%2F6b%2F4e%2F606b4e564884da8cca57ffeb229cd817006616e0&transform=1&allowOpen=true). @@ -1769,7 +1769,7 @@ The tables in the `birds` database are diagrammed below: - `routes` is a list of ~130 prescribed locations that the birdwatchers helping with the survey visit each year. The `geom` associated with each route is a [Point]({% link {{ page.version.version }}/point.md %}) marking the latitude and longitude of the route's starting point. For details, see the [schema](https://www.sciencebase.gov/catalog/file/get/5ea04e9a82cefae35a129d65?f=__disk__b4%2F2f%2Fcf%2Fb42fcfe28a799db6e8c97200829ea1ebaccbf8ea&transform=1&allowOpen=true) (search for the text "routes.csv"). - `observations` describes the ~85,000 times and places in which birds of various species were actually seen. The `bird_id` is a [foreign key]({% link {{ page.version.version }}/foreign-key.md %}) to the ID in the `birds` table, and the `route_id` points to the ID of the `routes` table. -birds.birds, birds.routes, and birds.observations ER diagrams +birds.birds, birds.routes, and birds.observations ER diagrams Each of these tables were populated using a script that parsed [the CSV files available for download](https://www.sciencebase.gov/catalog/item/52b1dfa8e4b0d9b325230cd9) and added the data using [`INSERT`]({% link {{ page.version.version }}/insert.md %}) statements. For the `routes` table, once again the `ST_MakePoint` function was used to create a geometry from the lon/lat values in the CSV as follows: diff --git a/src/current/v25.2/st_contains.md b/src/current/v25.2/st_contains.md index e8c2b895aff..27161ee2b86 100644 --- a/src/current/v25.2/st_contains.md +++ b/src/current/v25.2/st_contains.md @@ -53,7 +53,7 @@ SELECT ST_Contains(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95 (1 row) ~~~ -ST_Contains - true +ST_Contains - true ### False @@ -75,7 +75,7 @@ SELECT st_contains(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95 (1 row) ~~~ -ST_Contains - false +ST_Contains - false ## See also diff --git a/src/current/v25.2/st_convexhull.md b/src/current/v25.2/st_convexhull.md index 436acbf4692..284259a69bc 100644 --- a/src/current/v25.2/st_convexhull.md +++ b/src/current/v25.2/st_convexhull.md @@ -235,7 +235,7 @@ In this example, we will generate the convex hull of a single geometry. The geo 1. Paste the JSON emitted in the previous step into [geojson.io](http://geojson.io) and you should see an image like the following, which shows the convex hull surrounding the locations of [most of the independent bookstores in New York State](https://www.bookweb.org/member_directory/search/ABAmember/results/0/0/ny/0): - ST_ConvexHull example + ST_ConvexHull example 1. Finally, drop the temporary table if you no longer need it: diff --git a/src/current/v25.2/st_coveredby.md b/src/current/v25.2/st_coveredby.md index d0d0f4c05a3..c51f830daea 100644 --- a/src/current/v25.2/st_coveredby.md +++ b/src/current/v25.2/st_coveredby.md @@ -48,7 +48,7 @@ SELECT ST_CoveredBy(st_geomfromtext('SRID=4326;POLYGON((-87.623177 41.881832, -9 (1 row) ~~~ -ST_CoveredBy - true +ST_CoveredBy - true ### False @@ -68,7 +68,7 @@ SELECT ST_CoveredBy(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -9 (1 row) ~~~ -ST_CoveredBy - false +ST_CoveredBy - false ## See also diff --git a/src/current/v25.2/st_covers.md b/src/current/v25.2/st_covers.md index 886b5f4e2fb..55bcab6e885 100644 --- a/src/current/v25.2/st_covers.md +++ b/src/current/v25.2/st_covers.md @@ -50,7 +50,7 @@ SELECT ST_Covers(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.9 (1 row) ~~~ -ST_Covers - true +ST_Covers - true ### False @@ -70,7 +70,7 @@ SELECT ST_Covers(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.9 (1 row) ~~~ -ST_Covers - false +ST_Covers - false ## See also diff --git a/src/current/v25.2/st_disjoint.md b/src/current/v25.2/st_disjoint.md index ef75ccf54a1..3162f9eda3d 100644 --- a/src/current/v25.2/st_disjoint.md +++ b/src/current/v25.2/st_disjoint.md @@ -49,7 +49,7 @@ SELECT st_disjoint(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95 (1 row) ~~~ -ST_Disjoint - true +ST_Disjoint - true ### False @@ -69,7 +69,7 @@ SELECT st_disjoint(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95 (1 row) ~~~ -ST_Disjoint - false +ST_Disjoint - false ## See also diff --git a/src/current/v25.2/st_equals.md b/src/current/v25.2/st_equals.md index 11ed84ec677..4b7df966cba 100644 --- a/src/current/v25.2/st_equals.md +++ b/src/current/v25.2/st_equals.md @@ -45,7 +45,7 @@ SELECT st_equals(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.9 (1 row) ~~~ -ST_Equals - true +ST_Equals - true ### False @@ -65,7 +65,7 @@ SELECT st_equals(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.9 (1 row) ~~~ -ST_Equals - false +ST_Equals - false ## See also diff --git a/src/current/v25.2/st_intersects.md b/src/current/v25.2/st_intersects.md index fc24efdd871..08e7acfb16c 100644 --- a/src/current/v25.2/st_intersects.md +++ b/src/current/v25.2/st_intersects.md @@ -46,7 +46,7 @@ SELECT st_intersects(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, - (1 row) ~~~ -ST_Intersects - true +ST_Intersects - true ### False @@ -66,7 +66,7 @@ SELECT st_intersects(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, - (1 row) ~~~ -ST_Intersects - false +ST_Intersects - false ## See also diff --git a/src/current/v25.2/st_overlaps.md b/src/current/v25.2/st_overlaps.md index 58779fba333..7c535f12fe8 100644 --- a/src/current/v25.2/st_overlaps.md +++ b/src/current/v25.2/st_overlaps.md @@ -47,7 +47,7 @@ SELECT st_overlaps(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95 (1 row) ~~~ -ST_Overlaps - true +ST_Overlaps - true ### False @@ -67,7 +67,7 @@ SELECT st_overlaps(st_geomfromtext('SRID=4326;POLYGON((-79.995888 40.440624,-74. (1 row) ~~~ -ST_Overlaps - false +ST_Overlaps - false ## See also diff --git a/src/current/v25.2/st_touches.md b/src/current/v25.2/st_touches.md index e9e6f6bfd04..35329c3b0d3 100644 --- a/src/current/v25.2/st_touches.md +++ b/src/current/v25.2/st_touches.md @@ -47,7 +47,7 @@ SELECT st_touches(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95. (1 row) ~~~ -ST_Touches - true +ST_Touches - true ### False @@ -67,7 +67,7 @@ SELECT st_touches(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95. (1 row) ~~~ -ST_Touches - false +ST_Touches - false ## See also diff --git a/src/current/v25.2/st_union.md b/src/current/v25.2/st_union.md index e6558d445b2..5034f9dd363 100644 --- a/src/current/v25.2/st_union.md +++ b/src/current/v25.2/st_union.md @@ -236,7 +236,7 @@ In this example, we will generate a single geometry from many individual points 1. Paste the JSON emitted in the previous step into [geojson.io](http://geojson.io) and you should see an image like the following, which shows the location of [most of the independent bookstores in New York State](https://www.bookweb.org/member_directory/search/ABAmember/results/0/0/ny/0): - ST_Union example + ST_Union example 1. Finally, drop the temporary table if you no longer need it: diff --git a/src/current/v25.2/st_within.md b/src/current/v25.2/st_within.md index 94f6b25ff64..45a25255193 100644 --- a/src/current/v25.2/st_within.md +++ b/src/current/v25.2/st_within.md @@ -53,7 +53,7 @@ SELECT ST_Within(st_geomfromtext('SRID=4326;POLYGON((-87.623177 41.881832, -90.1 (1 row) ~~~ -ST_Within - true +ST_Within - true ### False @@ -73,7 +73,7 @@ SELECT ST_Within(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.9 (1 row) ~~~ -ST_Within - false +ST_Within - false ## See also diff --git a/src/current/v25.2/start-a-local-cluster-in-docker-windows.md b/src/current/v25.2/start-a-local-cluster-in-docker-windows.md index 5d704a7b5d7..a6e6ffe21c9 100644 --- a/src/current/v25.2/start-a-local-cluster-in-docker-windows.md +++ b/src/current/v25.2/start-a-local-cluster-in-docker-windows.md @@ -300,7 +300,7 @@ The [DB Console]({% link {{ page.version.version }}/ui-overview.md %}) gives you 1. On the [**Cluster Overview**]({% link {{ page.version.version }}/ui-cluster-overview-page.md %}), notice that three nodes are live, with an identical replica count on each node: - DB Console + DB Console This demonstrates CockroachDB's [automated replication]({% link {{ page.version.version }}/demo-replication-and-rebalancing.md %}) of data via the Raft consensus protocol. @@ -310,7 +310,7 @@ The [DB Console]({% link {{ page.version.version }}/ui-overview.md %}) gives you 1. Click [**Metrics**]({% link {{ page.version.version }}/ui-overview-dashboard.md %}) to access a variety of time series dashboards, including graphs of SQL queries and service latency over time: - DB Console + DB Console 1. Use the [**Databases**]({% link {{ page.version.version }}/ui-databases-page.md %}), [**Statements**]({% link {{ page.version.version }}/ui-statements-page.md %}), and [**Jobs**]({% link {{ page.version.version }}/ui-jobs-page.md %}) pages to view details about your databases and tables, to assess the performance of specific queries, and to monitor the status of long-running operations like schema changes, respectively. 1. Optionally verify that DB Console instances for `roach2` and `roach3` are reachable on ports 8081 and 8082 and show the same information as port 8080. @@ -321,7 +321,7 @@ The CockroachDB [DB Console]({% link {{ page.version.version }}/ui-overview.md % 1. On the [**Cluster Overview**]({% link {{ page.version.version }}/ui-cluster-overview-page.md %}), notice that three nodes are live, with an identical replica count on each node: - DB Console + DB Console This demonstrates CockroachDB's [automated replication]({% link {{ page.version.version }}/demo-replication-and-rebalancing.md %}) of data via the Raft consensus protocol. @@ -331,7 +331,7 @@ The CockroachDB [DB Console]({% link {{ page.version.version }}/ui-overview.md % 1. Click [**Metrics**]({% link {{ page.version.version }}/ui-overview-dashboard.md %}) to access a variety of time series dashboards, including graphs of SQL queries and service latency over time: - DB Console + DB Console 1. Use the [**Databases**]({% link {{ page.version.version }}/ui-databases-page.md %}), [**Statements**]({% link {{ page.version.version }}/ui-statements-page.md %}), and [**Jobs**]({% link {{ page.version.version }}/ui-jobs-page.md %}) pages to view details about your databases and tables, to assess the performance of specific queries, and to monitor the status of long-running operations like schema changes, respectively. diff --git a/src/current/v25.2/start-a-local-cluster.md b/src/current/v25.2/start-a-local-cluster.md index a38f33f08a4..e6d28a0b105 100644 --- a/src/current/v25.2/start-a-local-cluster.md +++ b/src/current/v25.2/start-a-local-cluster.md @@ -43,7 +43,7 @@ This section shows how to start a cluster interactively. In production, operator {{site.data.alerts.callout_info}} The `--background` flag is not recommended. If you decide to start nodes in the background, you must also pass the `--pid-file` argument. To stop a `cockroach` process running in the background, extract the process ID from the PID file and pass it to the command to [stop the node](#step-7-stop-the-cluster). - In production, operators usually use a process manager like `systemd` to start and manage the `cockroach` process on each node. Refer to [Deploy CockroachDB On-Premises]({% link v23.1/deploy-cockroachdb-on-premises.md %}?filters=systemd). + In production, operators usually use a process manager like `systemd` to start and manage the `cockroach` process on each node. Refer to [Deploy CockroachDB On-Premises]({% link {{ page.version.version }}/deploy-cockroachdb-on-premises.md %}?filters=systemd). {{site.data.alerts.end}} You'll see a message like the following: @@ -254,7 +254,7 @@ The CockroachDB [DB Console]({% link {{ page.version.version }}/ui-overview.md % 1. On the [**Cluster Overview**]({% link {{ page.version.version }}/ui-cluster-overview-page.md %}), notice that three nodes are live, with an identical replica count on each node: - DB Console + DB Console This demonstrates CockroachDB's [automated replication]({% link {{ page.version.version }}/demo-replication-and-rebalancing.md %}) of data via the Raft consensus protocol. @@ -264,7 +264,7 @@ The CockroachDB [DB Console]({% link {{ page.version.version }}/ui-overview.md % 1. Click [**Metrics**]({% link {{ page.version.version }}/ui-overview-dashboard.md %}) to access a variety of time series dashboards, including graphs of SQL queries and service latency over time: - DB Console + DB Console 1. Use the [**Databases**]({% link {{ page.version.version }}/ui-databases-page.md %}), [**Statements**]({% link {{ page.version.version }}/ui-statements-page.md %}), and [**Jobs**]({% link {{ page.version.version }}/ui-jobs-page.md %}) pages to view details about your databases and tables, to assess the performance of specific queries, and to monitor the status of long-running operations like schema changes, respectively. @@ -294,7 +294,7 @@ The CockroachDB [DB Console]({% link {{ page.version.version }}/ui-overview.md % 1. In the DB Console, despite one node being "suspect", notice the continued SQL traffic: - DB Console + DB Console 1. Go to the terminal window for `node3` and restart it: @@ -338,7 +338,7 @@ Adding capacity is as simple as starting more nodes with `cockroach start`. 1. In the DB Console **Cluster Overview** page, confirm that the cluster now has five nodes. - DB Console + DB Console At first, the replica count will be lower for `node4` and `node5`. Very soon, however, you'll see those numbers even out across all nodes, indicating that data is being [automatically rebalanced]({% link {{ page.version.version }}/demo-replication-and-rebalancing.md %}) to utilize the additional capacity of the new nodes. diff --git a/src/current/v25.2/stream-a-changefeed-to-a-confluent-cloud-kafka-cluster.md b/src/current/v25.2/stream-a-changefeed-to-a-confluent-cloud-kafka-cluster.md index 73f460242ac..483b748c244 100644 --- a/src/current/v25.2/stream-a-changefeed-to-a-confluent-cloud-kafka-cluster.md +++ b/src/current/v25.2/stream-a-changefeed-to-a-confluent-cloud-kafka-cluster.md @@ -331,11 +331,11 @@ Move to the terminal window in which you started the Kafka consumer. As the chan You can also view the messages for your cluster in the Confluent Cloud console in the **Topics** sidebar under the **Messages** tab. -Users topic messages in the Confluent Cloud console. +Users topic messages in the Confluent Cloud console. You can use the **Schema** tab to view the schema for a specific topic. -Users vale schema in the Confluent Cloud console. +Users vale schema in the Confluent Cloud console. ## See also diff --git a/src/current/v25.2/take-locality-restricted-backups.md b/src/current/v25.2/take-locality-restricted-backups.md index 8d46625ab4a..a10a11297d1 100644 --- a/src/current/v25.2/take-locality-restricted-backups.md +++ b/src/current/v25.2/take-locality-restricted-backups.md @@ -55,7 +55,7 @@ The following diagram shows a CockroachDB cluster where each of the nodes can co Instead, Node 3's locality does match the backup job's `EXECUTION LOCALITY`. Replicas that match a backup job's locality designation and hold the backup job's row data will begin reading and exporting to cloud storage. -Using execution locality when there is a network restriction between locality requirements +Using execution locality when there is a network restriction between locality requirements To execute the backup only on nodes in the same region as the cloud storage location, you can specify [locality filters]({% link {{ page.version.version }}/cockroach-start.md %}#locality) that a node must match to take part in the backup job's execution. @@ -81,7 +81,7 @@ Sometimes the execution of backup jobs can consume considerable resources when r This diagram shows a CockroachDB cluster in four regions. The node used to run the backup job was configured with [non-voting replicas]({% link {{ page.version.version }}/architecture/replication-layer.md %}#non-voting-replicas) to provide low-latency reads. The node in this region will complete the backup job coordination and data export to cloud storage. -Using execution locality to create a non-primary region for backup jobs +Using execution locality to create a non-primary region for backup jobs For details, refer to: diff --git a/src/current/v25.2/topology-basic-production.md b/src/current/v25.2/topology-basic-production.md index 0c3d51afda2..e93d0a6207b 100644 --- a/src/current/v25.2/topology-basic-production.md +++ b/src/current/v25.2/topology-basic-production.md @@ -17,7 +17,7 @@ If you haven't already, [review the full range of topology patterns]({% link {{ ## Configuration -Basic production topology +Basic production topology 1. Provision hardware as follows: - 1 region with 3 AZs @@ -56,7 +56,7 @@ For example, in the animation below: 1. The leaseholder retrieves the results and returns to the gateway node. 1. The gateway node returns the results to the client. -Basic production topology reads +Basic production topology reads #### Writes @@ -72,17 +72,17 @@ For example, in the animation below: 1. The leaseholders then return acknowledgement of the commit to the gateway node. 1. The gateway node returns the acknowledgement to the client. -Leaseholder preferences topology writes +Leaseholder preferences topology writes ### Resiliency Because each range is balanced across AZs, one AZ can fail without interrupting access to any data: -Basic production topology single zone failure +Basic production topology single zone failure However, if an additional AZ fails at the same time, the ranges that lose consensus become unavailable for reads and writes: -Basic production topology double zone failure +Basic production topology double zone failure ## See also diff --git a/src/current/v25.2/topology-development.md b/src/current/v25.2/topology-development.md index 3bf9d21906a..748a999305c 100644 --- a/src/current/v25.2/topology-development.md +++ b/src/current/v25.2/topology-development.md @@ -17,7 +17,7 @@ If you haven't already, [review the full range of topology patterns]({% link {{ ## Configuration -Development topology +Development topology For this pattern, you can either [run CockroachDB locally]({% link {{ page.version.version }}/start-a-local-cluster.md %}) or [deploy a single-node cluster on a cloud VM]({% link {{ page.version.version }}/manual-deployment.md %}). @@ -27,13 +27,13 @@ For this pattern, you can either [run CockroachDB locally]({% link {{ page.versi With the CockroachDB node in the same region as your client, and without the overhead of replication, both read and write latency are very low: -Development topology read and write latency +Development topology read and write latency ### Resiliency In a single-node cluster, CockroachDB does not replicate data and, therefore, is not resilient to failures. If the machine where the node is running fails, or if the region or availability zone containing the machine fails, the cluster becomes unavailable: -Development topology single failure +Development topology single failure ## See also diff --git a/src/current/v25.2/topology-follow-the-workload.md b/src/current/v25.2/topology-follow-the-workload.md index 431299750f3..86aa81e2d6c 100644 --- a/src/current/v25.2/topology-follow-the-workload.md +++ b/src/current/v25.2/topology-follow-the-workload.md @@ -32,7 +32,7 @@ Note that if you start using the [multi-region SQL abstractions]({% link {{ page Aside from [deploying a cluster across three regions](#cluster-setup) properly, with each node started with the [`--locality`]({% link {{ page.version.version }}/cockroach-start.md %}#locality) flag specifying its region and zone combination, this behavior requires no extra configuration. CockroachDB will balance the replicas for a table across the three regions and will assign the range lease to the replica in the region with the greatest demand at any given time (the follow-the-workload feature). This means that read latency in the active region will be low while read latency in other regions will be higher due to having to leave the region to reach the leaseholder. Write latency will be higher as well due to always involving replicas in multiple regions. -Follow-the-workload table replication +Follow-the-workload table replication {{site.data.alerts.callout_info}} Follow-the-workload is also used by [system ranges containing important internal data]({% link {{ page.version.version }}/configure-replication-zones.md %}#create-a-replication-zone-for-a-system-range). @@ -54,7 +54,7 @@ For example, in the animation below, the most active region is `us-east` and, th 1. The leaseholder retrieves the results and returns to the gateway node. 1. The gateway node returns the results to the client. In this case, reads in the `us-east` remain in the region and are lower latency than reads in other regions. -Follow-the-workload topology reads +Follow-the-workload topology reads #### Writes @@ -70,17 +70,17 @@ For example, in the animation below, assuming the most active region is still `u 1. The leaseholders then return acknowledgement of the commit to the gateway node. 1. The gateway node returns the acknowledgement to the client. -Follow-the-workload topology writes +Follow-the-workload topology writes ### Resiliency Because this pattern balances the replicas for the table across regions, one entire region can fail without interrupting access to the table: -Follow-the-workload topology region failure +Follow-the-workload topology region failure {% comment %} However, if an additional machine holding a replica for the table fails at the same time as the region failure, the range to which the replica belongs becomes unavailable for reads and writes: -Follow-the-workload topology {% endcomment %} +Follow-the-workload topology {% endcomment %} ## See also diff --git a/src/current/v25.2/topology-follower-reads.md b/src/current/v25.2/topology-follower-reads.md index 362a299e49f..ac218e0bb6b 100644 --- a/src/current/v25.2/topology-follower-reads.md +++ b/src/current/v25.2/topology-follower-reads.md @@ -30,7 +30,7 @@ If reads can use stale data, use [stale follower reads]({% link {{ page.version. With each node started with the [`--locality`]({% link {{ page.version.version }}/cockroach-start.md %}#locality) flag specifying its region and zone combination, CockroachDB will balance the replicas for a table across the three regions: -Follower reads table replication +Follower reads table replication ### Summary @@ -108,7 +108,7 @@ For example, in the following diagram: 1. The replica retrieves the results as of your preferred staleness interval in the past and returns to the gateway node. 1. The gateway node returns the results to the client. -Follower reads topology reads +Follower reads topology reads #### Writes @@ -124,13 +124,13 @@ For example, in the following animation: 1. The leaseholder then returns acknowledgement of the commit to the gateway node. 1. The gateway node returns the acknowledgement to the client. -Follower reads topology writes +Follower reads topology writes ### Resiliency Because this pattern balances the replicas for the table across regions, one entire region can fail without interrupting access to the table: -Follower reads topology region failure +Follower reads topology region failure ## See also diff --git a/src/current/v25.2/troubleshoot-lock-contention.md b/src/current/v25.2/troubleshoot-lock-contention.md index 9e246f38192..830d7fc3459 100644 --- a/src/current/v25.2/troubleshoot-lock-contention.md +++ b/src/current/v25.2/troubleshoot-lock-contention.md @@ -207,18 +207,18 @@ This step assumes you have already run the SQL statements from [Example 1](#exam After executing the transactions in the [previous section](#step-1-understand-lock-contention), open the [DB Console](#db-console) for the demo cluster. Navigate to the **Insights** page and select **Workload Insights** > **Transactions Executions**. -Transaction Executions view +Transaction Executions view Depending on when you [executed the transactions](#example-1), to display the transactions flagged with insights, you may have to select a longer time interval, such as **Past 6 Hours**. -Time interval +Time interval With an adequate time interval, two [**High Contention**]({% link {{ page.version.version }}/ui-insights-page.md %}#high-contention) insights will be listed for [Example 1](#example-1): - **Transaction 2** - **Transaction 3** -High Contention +High Contention ### Waiting statement @@ -226,21 +226,21 @@ To identify the exact statement in the transaction that experienced high content On the **Transaction Execution** page, navigate to the **Statement Executions** tab. In the list of statement executions, in the **Insights** column for `SELECT * FROM t where k = _`, there should be the **High Contention** insight. In [Example 1](#example-1), *Transaction 2* had one statement (other than `SHOW database`). In a transaction with multiple statements, use this page to pinpoint the exact statement that experienced high contention. -Waiting statement +Waiting statement ### Blocking transaction To identify the transaction that blocked **Transaction 2** and caused it to experience high contention, navigate back to the **Overview** tab. -Overview tab +Overview tab Scroll to the bottom of the Overview tab to the **Transaction with ID ... waited on** section that gives information about the blocking transaction. -Blocking transaction +Blocking transaction For more information about the blocking transaction, click the **Transaction Fingerprint ID** to open the [**Transaction Details** page]({% link {{ page.version.version }}/ui-transactions-page.md %}#transaction-details-page). -Blocking transaction details +Blocking transaction details ### Additional practice diff --git a/src/current/v25.2/ui-cdc-dashboard.md b/src/current/v25.2/ui-cdc-dashboard.md index e2c0ee5131b..fb1ad0ec771 100644 --- a/src/current/v25.2/ui-cdc-dashboard.md +++ b/src/current/v25.2/ui-cdc-dashboard.md @@ -23,7 +23,7 @@ The **Changefeeds** dashboard displays the following time series graphs: This graph displays the status of all running changefeeds. -DB Console Changefeed Status graph showing running, paused, and failed changefeeds. +DB Console Changefeed Status graph showing running, paused, and failed changefeeds. Metric | Description --------|---- @@ -39,7 +39,7 @@ In the case of a failed changefeed, you may want to use the [`cursor`]({% link { This graph displays the 99th, 90th, and 50th percentile of commit latency for running changefeeds. This is the difference between an event's MVCC timestamp and the time it was acknowledged as received by the [downstream sink]({% link {{ page.version.version }}/changefeed-sinks.md %}). -DB Console Commit Latency graph showing the 99th, 90th, and 50th percentile of commit latency. +DB Console Commit Latency graph showing the 99th, 90th, and 50th percentile of commit latency. If the sink batches events, then the difference between the oldest event in the batch and acknowledgement is recorded. Latency during backfill is excluded. @@ -51,7 +51,7 @@ This graph shows the number of bytes emitted by CockroachDB into the changefeed' In v23.1 and earlier, the **Emitted Bytes** graph was named **Sink Byte Traffic**. If you want to customize charts, including how metrics are named, use the [**Custom Chart** debug page]({% link {{ page.version.version }}/ui-custom-chart-debug-page.md %}). {{site.data.alerts.end}} -DB Console Emitted Bytes Graph showing the time and emitted bites +DB Console Emitted Bytes Graph showing the time and emitted bites Metric | Description --------|---- @@ -64,7 +64,7 @@ This graph displays data relating to the number of messages and flushes at the c - The number of messages that CockroachDB sent to the sink. - The number of flushes that the sink performed for changefeeds. -DB Console Sink Counts graph +DB Console Sink Counts graph Metric | Description --------|---- @@ -79,7 +79,7 @@ This graph displays the most any changefeed's persisted [checkpoint]({% link {{ In v23.1 and earlier, the **Max Checkpoint Latency** graph was named **Max Changefeed Latency**. If you want to customize charts, including how metrics are named, use the [**Custom Chart** debug page]({% link {{ page.version.version }}/ui-custom-chart-debug-page.md %}). {{site.data.alerts.end}} -DB Console Max Checkpoint Latency graph +DB Console Max Checkpoint Latency graph {{site.data.alerts.callout_info}} The maximum checkpoint latency is distinct from, and slower than, the commit latency for individual change messages. For more information about resolved timestamps, refer to the [Changefeed Messages]({% link {{ page.version.version }}/changefeed-messages.md %}#resolved-messages) page. @@ -89,7 +89,7 @@ The maximum checkpoint latency is distinct from, and slower than, the commit lat This graph displays the number of times changefeeds restarted due to [retryable errors]({% link {{ page.version.version }}/monitor-and-debug-changefeeds.md %}#changefeed-retry-errors). -DB Console Changefeed Restarts graph +DB Console Changefeed Restarts graph Metric | Description --------|---- @@ -99,7 +99,7 @@ Metric | Description This graph displays the oldest [protected timestamp]({% link {{ page.version.version }}/architecture/storage-layer.md %}#protected-timestamps) of any running changefeed on the cluster. -DB Console Oldest Protected Timestamp graph +DB Console Oldest Protected Timestamp graph Metric | Description --------|---- @@ -109,7 +109,7 @@ Metric | Description This graph displays the number of ranges being backfilled that are yet to enter the changefeed pipeline. An [initial scan]({% link {{ page.version.version }}/create-changefeed.md %}#initial-scan) or [schema change]({% link {{ page.version.version }}/online-schema-changes.md %}) can cause a backfill. -DB Console Backfill Pending Ranges graph +DB Console Backfill Pending Ranges graph Metric | Description --------|---- @@ -119,7 +119,7 @@ Metric | Description This graph displays the rate of schema registration requests made by CockroachDB nodes to a configured schema registry endpoint. For example, a [Kafka sink]({% link {{ page.version.version }}/changefeed-sinks.md %}#kafka) pointing to a [Confluent Schema Registry]({% link {{ page.version.version }}/stream-a-changefeed-to-a-confluent-cloud-kafka-cluster.md %}). -DB Console Schema Registry Registrations graph +DB Console Schema Registry Registrations graph Metric | Description --------|---- @@ -129,7 +129,7 @@ Metric | Description This graph displays the total number of ranges with an active [rangefeed]({% link {{ page.version.version }}/create-and-configure-changefeeds.md %}#enable-rangefeeds) that is performing a catchup scan. -DB Console Ranges in Catchup Mode graph +DB Console Ranges in Catchup Mode graph Metric | Description --------|---- @@ -139,7 +139,7 @@ Metric | Description This graph displays the duration of catchup scans that changefeeds are performing. -DB Console Rangefeed Catchup Scans Duration graph +DB Console Rangefeed Catchup Scans Duration graph Metric | Description --------|---- diff --git a/src/current/v25.2/ui-cluster-overview-page.md b/src/current/v25.2/ui-cluster-overview-page.md index 57c4c816de9..02a68ce5816 100644 --- a/src/current/v25.2/ui-cluster-overview-page.md +++ b/src/current/v25.2/ui-cluster-overview-page.md @@ -18,7 +18,7 @@ Enable the [Node Map](#node-map) view for a visual representation of your cluste Use the **Cluster Overview** panel to quickly assess the capacity and health of your cluster. -DB Console cluster overview +DB Console cluster overview Metric | Description --------|---- @@ -110,7 +110,7 @@ The **Node Map** visualizes the geographical configuration of your cluster. It r For guidance on enabling and configuring the node map, see [Enable the Node Map]({% link {{ page.version.version }}/enable-node-map.md %}). -DB Console Summary Panel +DB Console Summary Panel The Node Map uses the longitude and latitude of each locality to position the components on the map. The map is populated with [**locality components**](#locality-component) and [**node components**](#node-component). @@ -122,7 +122,7 @@ The map shows the components for the highest-level locality tier (e.g., region). For details on how **Capacity Usage** is calculated, see [Capacity metrics](#capacity-metrics). -DB Console Summary Panel +DB Console Summary Panel {{site.data.alerts.callout_info}} On multi-core systems, the displayed CPU usage can be greater than 100%. Full utilization of 1 core is considered as 100% CPU usage. If you have _n_ cores, then CPU usage can range from 0% (indicating an idle system) to (_n_ * 100)% (indicating full utilization). @@ -136,7 +136,7 @@ Node components are accessed by clicking on the **Node Count** of the lowest-lev For details on how **Capacity Usage** is calculated, see [Capacity metrics](#capacity-metrics). -DB Console Summary Panel +DB Console Summary Panel {{site.data.alerts.callout_info}} On multi-core systems, the displayed CPU usage can be greater than 100%. Full utilization of 1 core is considered as 100% CPU usage. If you have _n_ cores, then CPU usage can range from 0% (indicating an idle system) to (_n_ * 100)% (indicating full utilization). diff --git a/src/current/v25.2/ui-custom-chart-debug-page.md b/src/current/v25.2/ui-custom-chart-debug-page.md index 0d32554b01b..c8cff4702af 100644 --- a/src/current/v25.2/ui-custom-chart-debug-page.md +++ b/src/current/v25.2/ui-custom-chart-debug-page.md @@ -13,7 +13,7 @@ To view the Custom Chart page, [access the DB Console]({% link {{ page.version.v ## Use the Custom Chart page -DB Console +DB Console On the **Custom Chart** page, you can set the time span for all charts, add new custom charts, and customize each chart: @@ -28,7 +28,7 @@ On the **Custom Chart** page, you can set the time span for all charts, add new ### Query user and system CPU usage -DB Console +DB Console To compare system vs. userspace CPU usage, select the following values under **Metric Name**: diff --git a/src/current/v25.2/ui-hardware-dashboard.md b/src/current/v25.2/ui-hardware-dashboard.md index 4dde08b301a..49aa444244e 100644 --- a/src/current/v25.2/ui-hardware-dashboard.md +++ b/src/current/v25.2/ui-hardware-dashboard.md @@ -21,7 +21,7 @@ The **Hardware** dashboard displays the following time series graphs: ## Host CPU Percent -DB Console CPU Percent graph +DB Console CPU Percent graph The **Host CPU Percent** graph displays the current user and system CPU percentage consumed by all processes on the host OS, normalized by number of cores, as tracked by the [`sys.cpu.host.combined.percent-normalized`]({% link {{ page.version.version }}/essential-metrics-self-hosted.md %}#sys-cpu-host-combined-percent-normalized) metric. If the CockroachDB process is run in a containerized environment, the host OS is the container since the CockroachDB process cannot inspect CPU usage beyond the container. @@ -35,7 +35,7 @@ For multi-core systems, the percentage of CPU usage is calculated by normalizing ## Memory Usage -DB Console Memory Usage graph +DB Console Memory Usage graph {{site.data.alerts.callout_info}} This graph shows the memory consumption by the CockroachDB process only and is useful as long as there are no other processes consuming significant memory on the node. In case you have other processes running on the node, use a separate monitoring tool to measure the total memory consumption across all processes. @@ -47,7 +47,7 @@ This graph shows the memory consumption by the CockroachDB process only and is u ## Disk Read Bytes -DB Console Disk Read Bytes graph +DB Console Disk Read Bytes graph - In the node view, the graph shows the 10-second average of the number of bytes read per second by all processes, including CockroachDB, for the selected node. @@ -55,7 +55,7 @@ This graph shows the memory consumption by the CockroachDB process only and is u ## Disk Write Bytes -DB Console Disk Write Bytes graph +DB Console Disk Write Bytes graph - In the node view, the graph shows the 10-second average of the number of bytes written per second by all processes, including CockroachDB, for the node. @@ -63,7 +63,7 @@ This graph shows the memory consumption by the CockroachDB process only and is u ## Disk Read Ops -DB Console Disk Read Ops graph +DB Console Disk Read Ops graph - In the node view, the graph shows the 10-second average of the number of disk read ops per second for all processes, including CockroachDB, for the selected node. @@ -71,7 +71,7 @@ This graph shows the memory consumption by the CockroachDB process only and is u ## Disk Write Ops -DB Console Disk Write Ops graph +DB Console Disk Write Ops graph - In the node view, the graph shows the 10-second average of the number of disk write ops per second for all processes, including CockroachDB, for the node. @@ -93,7 +93,7 @@ On macOS, this graph is currently not populated and shows zero disk ops in progr ## Available Disk Capacity -DB Console Disk Capacity graph +DB Console Disk Capacity graph Metric | Description --------|-------- diff --git a/src/current/v25.2/ui-key-visualizer.md b/src/current/v25.2/ui-key-visualizer.md index 2f35ae23eeb..1c65d3cb95a 100644 --- a/src/current/v25.2/ui-key-visualizer.md +++ b/src/current/v25.2/ui-key-visualizer.md @@ -39,7 +39,7 @@ Once you have enabled the Key Visualizer, CockroachDB will begin monitoring keys When navigating to the **Key Visualizer** page in the DB Console, after a brief loading time, CockroachDB will present the collected data in a visualization designed to help you see data traffic trends at a glance. -Key Visualizer showing hot range +Key Visualizer showing hot range The Key Visualizer presents the following information: @@ -82,7 +82,7 @@ The Key Visualizer was designed to make potentially problematic ranges stand out The following image shows the Key Visualizer highlighting a series of [hotspots]({% link {{ page.version.version }}/understand-hotspots.md %}): ranges with much higher-than-average write rates as compared to the rest of the cluster. -Key Visualizer showing range split +Key Visualizer showing range split **Remediation:** If you've identified a potentially-problematic range as a hotspot, follow the recommended best practices to [reduce hotspots]({% link {{ page.version.version }}/understand-hotspots.md %}#reduce-hotspots). In the case of the screenshot above, the increased write cadence is due to a series of [range splits]({% link {{ page.version.version }}/architecture/distribution-layer.md %}#range-splits), where a range experiencing a large volume of incoming writes is splitting its keyspace to accommodate the growing range. This is often part of normal operation, but can be indicative of a data modeling issue if the range split is unexpected or causing cluster performance issues. @@ -90,7 +90,7 @@ The following image shows the Key Visualizer highlighting a series of [hotspots] The following image shows the Key Visualizer highlighting a [full-table scan]({% link {{ page.version.version }}/make-queries-fast.md %}), where the lack of an appropriate index causes the query planner to need to scan the entire table to find the requested records in a query. This can be seen most clearly by the cascading series of bright red ranges that proceed in diagonal fashion to each other, such as the series of three shown at the mouse cursor. This cascade represents the sequential scan of contiguous ranges in the keyspace as the query planner attempts to locate requested data without an index. -Key Visualizer showing table scan +Key Visualizer showing table scan **Remediation:** If you've identified a full table scan, follow the guidance to [optimize statement performance]({% link {{ page.version.version }}/make-queries-fast.md %}). You can also [analyze your queries with `EXPLAIN`]({% link {{ page.version.version }}/sql-tuning-with-explain.md %}) to investigate if an index was used in the execution of the query. diff --git a/src/current/v25.2/ui-network-latency-page.md b/src/current/v25.2/ui-network-latency-page.md index afc78fd280a..d5a35d351c6 100644 --- a/src/current/v25.2/ui-network-latency-page.md +++ b/src/current/v25.2/ui-network-latency-page.md @@ -20,7 +20,7 @@ Select **Collapse Nodes** to display the mean latencies of each locality, depend Each cell in the matrix displays the round-trip latency in milliseconds between two nodes in your cluster. Round-trip latency includes the return time of a packet. Latencies are color-coded by their standard deviation from the mean latency on the network: green for lower values, and blue for higher. Nodes with the lowest latency are displayed in darker green, and nodes with the highest latency are displayed in darker blue. -DB Console Network Latency matrix +DB Console Network Latency matrix Rows represent origin nodes, and columns represent destination nodes. Hover over a cell to display more details: @@ -34,7 +34,7 @@ On a [typical multi-region cluster]({% link {{ page.version.version }}/demo-low- For instance, the cluster shown above has nodes in `us-west1`, `us-east1`, and `europe-west2`. Latencies are highest between nodes in `us-west1` and `europe-west2`, which span the greatest distance. This is especially clear when sorting by region or availability zone and collapsing nodes: -DB Console Network Latency collapsed nodes +DB Console Network Latency collapsed nodes ### No connections @@ -45,7 +45,7 @@ Nodes that have completely lost connectivity are color-coded depending on connec This information can help you diagnose a network partition in your cluster. -DB Console Network Latency suspect node +DB Console Network Latency suspect node Hover over a cell to display more details: diff --git a/src/current/v25.2/ui-physical-cluster-replication-dashboard.md b/src/current/v25.2/ui-physical-cluster-replication-dashboard.md index 409d791f304..3ed3cb9193f 100644 --- a/src/current/v25.2/ui-physical-cluster-replication-dashboard.md +++ b/src/current/v25.2/ui-physical-cluster-replication-dashboard.md @@ -21,7 +21,7 @@ The **Physical Cluster Replication** dashboard displays the following time-serie ## Logical bytes -DB Console Logical Bytes graph showing results over the past hour +DB Console Logical Bytes graph showing results over the past hour The **Logical Bytes** graph displays the throughput of the replicated bytes. The graph displays the rate at which the logical bytes (sum of keys + values) are ingested by all replication jobs. @@ -36,7 +36,7 @@ When you [start a replication stream]({% link {{ page.version.version }}/set-up- ## Replication lag -DB Console Replication Lag graph showing results over the past hour +DB Console Replication Lag graph showing results over the past hour The **Replication Lag** graph displays the [replication lag]({% link {{ page.version.version }}/physical-cluster-replication-technical-overview.md %}) between the primary and standby cluster. This is the time between the most up-to-date replicated time and the actual time. diff --git a/src/current/v25.2/ui-queues-dashboard.md b/src/current/v25.2/ui-queues-dashboard.md index 0cb96401158..1a300547eb9 100644 --- a/src/current/v25.2/ui-queues-dashboard.md +++ b/src/current/v25.2/ui-queues-dashboard.md @@ -171,7 +171,7 @@ Pending Actions | The number of pending replicas in the time series maintenance ## MVCC GC Queue -DB Console GC queue graph +DB Console GC queue graph The **MVCC GC Queue** graph displays various details about the health and performance of the [garbage collection]({% link {{ page.version.version }}/architecture/storage-layer.md %}#garbage-collection) queue. @@ -184,7 +184,7 @@ Pending Actions | The number of pending replicas in the [garbage collection]({% ## Protected Timestamp Records -DB Console GC queue graph +DB Console GC queue graph The **Protected Timestamp Records** graph displays the number of [protected timestamp]({% link {{ page.version.version }}/architecture/storage-layer.md %}#protected-timestamps) records (used by backups, changefeeds, etc. to prevent MVCC GC) per node, as tracked by the `spanconfig.kvsubscriber.protected_record_count` metric. diff --git a/src/current/v25.2/ui-replication-dashboard.md b/src/current/v25.2/ui-replication-dashboard.md index d5c0ab4edaa..e4a261a572a 100644 --- a/src/current/v25.2/ui-replication-dashboard.md +++ b/src/current/v25.2/ui-replication-dashboard.md @@ -31,7 +31,7 @@ The **Replication** dashboard displays the following time series graphs: ## Ranges -DB Console Ranges +DB Console Ranges The **Ranges** graph shows you various details about the status of ranges. @@ -52,7 +52,7 @@ Under-replicated | The number of under-replicated ranges. Non-voting replicas ar ## Logical Bytes per Store -DB Console Logical Bytes per Store +DB Console Logical Bytes per Store Metric | Description --------|-------- @@ -64,7 +64,7 @@ Metric | Description ## Replicas Per Store -DB Console Replicas per Store +DB Console Replicas per Store - In the node view, the graph shows the number of range replicas on the store. @@ -74,7 +74,7 @@ You can [Replication Controls]({% link {{ page.version.version }}/configure-repl ## Replica Quiescence -DB Console Replica Quiescence +DB Console Replica Quiescence - In the node view, the graph shows the number of replicas on the node. @@ -104,7 +104,7 @@ Load-based Range Rebalances | `rebalancing.range.rebalances` | Number of range r ## Snapshots -DB Console Replica Snapshots +DB Console Replica Snapshots Usually the nodes in a [Raft group]({% link {{ page.version.version }}/architecture/replication-layer.md %}#raft) stay synchronized by following along with the log message by message. However, if a node is far enough behind the log (e.g., if it was offline or is a new node getting up to speed), rather than send all the individual messages that changed the range, the cluster can send it a snapshot of the range and it can start following along from there. Commonly this is done preemptively, when the cluster can predict that a node will need to catch up, but occasionally the Raft protocol itself will request the snapshot. @@ -118,7 +118,7 @@ Reserved | The number of slots reserved per second for incoming snapshots that w ## Snapshot Data Received -DB Console Replica Snapshot Data Received +DB Console Replica Snapshot Data Received The **Snapshot Data Received** graph shows the rate per second of data received in bytes by each node via [Raft snapshot transfers]({% link {{ page.version.version }}/architecture/replication-layer.md %}#snapshots). Data is split into recovery and rebalancing snapshot data received: recovery includes all upreplication due to decommissioning or node failure, and rebalancing includes all other snapshot data received. @@ -131,7 +131,7 @@ Metric | Description ## Receiver Snapshots Queued -DB Console Replica Receiver Snapshots Queued +DB Console Replica Receiver Snapshots Queued The **Receiver Snapshots Queued** graph shows the number of [Raft snapshot transfers]({% link {{ page.version.version }}/architecture/replication-layer.md %}#snapshots) queued to be applied on a receiving node, which can only accept one snapshot at a time per store. @@ -143,7 +143,7 @@ Metric | Description ## Circuit Breaker Tripped Replicas -DB Console Circuit Breaker Tripped Replicas +DB Console Circuit Breaker Tripped Replicas When individual ranges become temporarily unavailable, requests to those ranges are refused by a [per-replica circuit breaker]({% link {{ page.version.version }}/architecture/replication-layer.md %}#per-replica-circuit-breaker-overview) instead of hanging indefinitely. @@ -159,7 +159,7 @@ Metric | Description ## Circuit Breaker Tripped Events -DB Console Circuit Breaker Tripped Events +DB Console Circuit Breaker Tripped Events When individual ranges become temporarily unavailable, requests to those ranges are refused by a [per-replica circuit breaker]({% link {{ page.version.version }}/architecture/replication-layer.md %}#per-replica-circuit-breaker-overview) instead of hanging indefinitely. While a range's per-replica circuit breaker remains tripped, each incoming request to that range triggers a `ReplicaUnavailableError` event until the range becomes available again. @@ -173,7 +173,7 @@ Metric | Description ## Replicate Queue Actions: Successes -DB Console Replicate Queue Actions: Successes +DB Console Replicate Queue Actions: Successes The **Replicate Queue Actions: Successes** graph shows the rate of various successful replication queue actions per second. @@ -194,7 +194,7 @@ Decommissioning Replicas Removed / Sec | The number of successful decommissionin ## Replicate Queue Actions: Failures -DB Console Replicate Queue Actions: Failures +DB Console Replicate Queue Actions: Failures The **Replicate Queue Actions: Failures** graph shows the rate of various failed replication queue actions per second. @@ -215,7 +215,7 @@ Decommissioning Replicas Removed Errors / Sec | The number of failed decommissio ## Decommissioning Errors -DB Console Replica Decommissioning Errors +DB Console Replica Decommissioning Errors The **Decommissioning Errors** graph shows the rate per second of decommissioning replica replacement failures experienced by the replication queue, by node. diff --git a/src/current/v25.2/ui-runtime-dashboard.md b/src/current/v25.2/ui-runtime-dashboard.md index 7e29d3f218b..df55ad38436 100644 --- a/src/current/v25.2/ui-runtime-dashboard.md +++ b/src/current/v25.2/ui-runtime-dashboard.md @@ -17,7 +17,7 @@ The **Runtime** dashboard displays the following time series graphs: ## Live Node Count -DB Console Node Count +DB Console Node Count In the node view as well as the cluster view, the graph shows the number of live nodes in the cluster. @@ -25,7 +25,7 @@ A dip in the graph indicates decommissioned nodes, dead nodes, or nodes that are ## Memory Usage -DB Console Memory Usage +DB Console Memory Usage - In the node view, the graph shows the memory in use for the selected node. @@ -49,7 +49,7 @@ CGo Total | Total memory managed by the C layer. ## CPU Time -DB Console CPU Time +DB Console CPU Time - In the node view, the graph shows the [CPU time](https://wikipedia.org/wiki/CPU_time) used by CockroachDB user and system-level operations for the selected node. - In the cluster view, the graph shows the [CPU time](https://wikipedia.org/wiki/CPU_time) used by CockroachDB user and system-level operations across all nodes in the cluster. @@ -63,7 +63,7 @@ Sys CPU Time | Total CPU seconds per second used for CockroachDB system-level op ## Clock Offset -DB Console Clock Offset +DB Console Clock Offset - In the node view, the graph shows the mean clock offset of the node against the rest of the cluster. - In the cluster view, the graph shows the mean clock offset of each node against the rest of the cluster. diff --git a/src/current/v25.2/ui-schedules-page.md b/src/current/v25.2/ui-schedules-page.md index a04014d08aa..eeb4496d71e 100644 --- a/src/current/v25.2/ui-schedules-page.md +++ b/src/current/v25.2/ui-schedules-page.md @@ -27,7 +27,7 @@ Use the **Schedules** list to see your active and paused schedules. The following screenshot shows a list of backups and automated statistics compaction schedules: -Schedules Page UI in the DB Console showing a list of schedules +Schedules Page UI in the DB Console showing a list of schedules Column | Description ---------------------+-------------- @@ -44,7 +44,7 @@ Creation Time (UTC) | The time at which the user originally created the sc Click on a schedule ID to view the full SQL statement that the schedule runs. For example, the following screenshot shows the resulting [`BACKUP`]({% link {{ page.version.version }}/backup.md %}) statement for a full cluster backup recurring every day: -UI for each individual schedule ID displaying the CREATE SCHEDULE SQL statement +UI for each individual schedule ID displaying the CREATE SCHEDULE SQL statement You may also view a `protected_timestamp_record` on this page. This indicates that the schedule is actively managing its own [protected timestamp]({% link {{ page.version.version }}/architecture/storage-layer.md %}#protected-timestamps) records independently of [GC TTL]({% link {{ page.version.version }}/configure-replication-zones.md %}#gc-ttlseconds). See [Protected timestamps and scheduled backups]({% link {{ page.version.version }}/create-schedule-for-backup.md %}#protected-timestamps-and-scheduled-backups) for more detail. diff --git a/src/current/v25.2/ui-ttl-dashboard.md b/src/current/v25.2/ui-ttl-dashboard.md index 4a9e5e95f7d..f32d1e550db 100644 --- a/src/current/v25.2/ui-ttl-dashboard.md +++ b/src/current/v25.2/ui-ttl-dashboard.md @@ -19,7 +19,7 @@ The **TTL** dashboard displays the following time series graphs: You can monitor the **Processing Rate** graph to see how many rows per second are being processed by [TTL jobs]({% link {{ page.version.version }}/row-level-ttl.md %}#view-running-ttl-jobs). -TTL processing rate graph +TTL processing rate graph | Metric | Description | |---------------+---------------------------------------------| @@ -30,7 +30,7 @@ You can monitor the **Processing Rate** graph to see how many rows per second ar Monitor the **Estimated Rows** graph to see approximately how many rows are on the TTL table. -TTL estimated rows graph +TTL estimated rows graph | Metric | Description | |------------------------------------+-----------------------------------------------------------------| @@ -41,13 +41,13 @@ Monitor the **Estimated Rows** graph to see approximately how many rows are on t Monitor the **Job Latency** graph to see the latency of scanning and deleting within your cluster's [TTL jobs]({% link {{ page.version.version }}/row-level-ttl.md %}#view-running-ttl-jobs). -TTL job latency graph +TTL job latency graph ## Ranges in Progress Monitor the **Ranges in Progress** graph to see the number of ranges currently being processed by [TTL jobs]({% link {{ page.version.version }}/row-level-ttl.md %}#view-running-ttl-jobs). -TTL ranges in progress graph +TTL ranges in progress graph | Metric | Description | |----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------| diff --git a/src/current/v25.2/understand-hotspots.md b/src/current/v25.2/understand-hotspots.md index 7f5df31ba44..9b85ca4b6ea 100644 --- a/src/current/v25.2/understand-hotspots.md +++ b/src/current/v25.2/understand-hotspots.md @@ -35,7 +35,7 @@ All hotspot types described on this page will create hot nodes, as long as the c The following image is a graph of [CPU Percent]({% link {{ page.version.version }}/ui-hardware-dashboard.md %}#cpu-percent) utilization per node. Most of the nodes hover around 25%, while one hot node is around 95%. Since the hot node keeps changing, it means the hotspot is moving from one node to another as the [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#range) containing writes fill up and split. For more information, refer to [hot range](#hot-range) and [moving hotspot](#moving-hotspot). -graph of CPU Percent utilization per node showing hot nodes +graph of CPU Percent utilization per node showing hot nodes ### Hot range @@ -106,7 +106,7 @@ An _index hotspot_ is a hotspot on an [index]({% link {{ page.version.version }} Consider a table `users` that contains a [primary key]({% link {{ page.version.version }}/primary-key.md %}) `user_id`, which is an incrementing integer value. Each new key will be the current maximum key + 1. In this way, all writes appear at the index tail. The following image visualizes writes to the `users` table using an incrementing `INT` primary key. Note how all writes are focused at the tail of the index, represented by the red section in Range 4. -incrementing INT primary key +incrementing INT primary key Even if performance degradation in Range 4 is mitigated, the system remains constrained by the number of writes a single range can handle. As a result, CockroachDB could be limited to the performance of a single node, which goes against the purpose of a distributed database. @@ -116,7 +116,7 @@ In the ideal operation of a distributed SQL database, inserts into an index shou Consider a table `users` that contains a primary key `user_uuid` of type [`UUID`]({% link {{ page.version.version }}/uuid.md %}). Because `UUID`s are pseudo-random, new rows are inserted into the keyspace at random locations. The following image visualizes writes to the `users` table using a `UUID` primary key. Red lines indicate an insert into the keyspace. Note how the red lines are distributed evenly. -UUID primary key +UUID primary key Inserts are not the only way that index hotspots can occur. Consider the same table `users` that now has a [secondary index]({% link {{ page.version.version }}/schema-design-indexes.md %}) on a `TIMESTAMP` column: @@ -145,7 +145,7 @@ The resolution of the index hotspot often depends on your requirements for the d If inserting in sequential order is important, the index itself can be [hash-sharded]({% link {{ page.version.version }}/hash-sharded-indexes.md %}), which means that it is still stored in order, albeit in some number of shards. Consider a `users` table, with a primary key `id INT`, which is hash-sharded with 4 shards, and a hashing function of modulo 4. The following image illustrates this example: -Hash-sharded index example +Hash-sharded index example Now the writes are distributed into the tails of the shards, rather than the tail of the whole index. This benefits write performance but makes reads more challenging. If you need to read a subset of the data, you will have to scan each shard of the index. @@ -183,7 +183,7 @@ A _queueing hotspot_ is a type of index hotspot that occurs when a workload trea Queues, such as logs, generally require data to be ordered by write, which necessitates indexing in a way that is likely to create a hotspot. An outbox where data is deleted as it is read has an additional problem: it tends to accumulate an ordered set of [garbage data]({% link {{ page.version.version }}/operational-faqs.md %}#why-is-my-disk-usage-not-decreasing-after-deleting-data) behind the live data. Since the system cannot determine whether any live rows exist within the garbage data, what appears to be a small table scan to the user can actually result in an unexpectedly intensive scan on the garbage data. -Outbox hotspot example +Outbox hotspot example To mitigate this issue, it is advisable to use [Change Data Capture (CDC)]({% link {{ page.version.version }}/cdc-queries.md %}) to ensure subscription to updates instead of using Outbox tables. If using CDC is not possible, sharding the index that the outbox uses for ordering can reduce the likelihood of a hotspot within the cluster. @@ -220,13 +220,13 @@ UPDATE User SET follower_count = follower_count+1 WHERE id=2; This simple design works well until it encounters an unexpected surge in activity. For example, consider user 471, who suddenly gains millions of followers within an hour. This sudden increase in followers causes a significant amount of write traffic to the range responsible for this user, which the system may not be able to handle efficiently. The following image visualizes a hot row in the keyspace. Note how writes are focused on a single point, which cannot be split. -Single row hotspot example +Single row hotspot example Without changing the default behavior of the system, the load will not be distributed because it needs to be served by a single range. This behavior is not just temporary; certain users may consistently experience a high volume of activity compared to the average user. This can result in a system with multiple hotspots, each of which can potentially overload the system at any moment. The following image visualizes a keyspace with multiple hot rows. In a large enough cluster, each of these rows can burden the range they live in, leading to multiple burdened nodes. -Multiple row hotspots example +Multiple row hotspots example ### Hot sequence @@ -248,7 +248,7 @@ Because the primary key index is [hash-sharded]({% link {{ page.version.version The following image visualizes writes in the `products` keyspace using hash-sharded rows. With five shards, the writes are better distributed into the keyspace, but the `id` sequence row becomes the limiting factor. -Multiple row hotspots example +Multiple row hotspots example Because sequences avoid user expressions, optimizations can be made to improve their performance, but unfortunately the write volume on the sequence is still that of the sum total of all its accesses. @@ -278,7 +278,7 @@ country_id UUID REFERENCES countries(id) SELECT * FROM posts p JOIN countries c ON p.country_id=c.id; ~~~ -Table hotspot example +Table hotspot example Reads in the `posts` table may be evenly distributed, but joining the `countries` table becomes a bottleneck, since it exists in so few ranges. Splitting the `countries` table ranges can relieve pressure, but only to a limit as the indivisible rows experience high throughput. [Global tables]({% link {{ page.version.version }}/global-tables.md %}) and [follower reads]({% link {{ page.version.version }}/follower-reads.md %}) can help scaling in this case, especially when write throughput is low. @@ -303,7 +303,7 @@ By doing this, you have limited the traffic from the highest throughput table to The following image visualizes the regional breakout of data in the `orders` table. Because of the domiciling policy, reads and writes to the `orders` table will be focused on the `us-east-1` nodes. -Locality hotspot example +Locality hotspot example ### Temporal hotspot diff --git a/src/current/v25.2/wal-failover.md b/src/current/v25.2/wal-failover.md index 009eb29fa21..32e2688cc3c 100644 --- a/src/current/v25.2/wal-failover.md +++ b/src/current/v25.2/wal-failover.md @@ -29,7 +29,7 @@ WAL failover uses a secondary disk to fail over WAL writes to when transient dis The following diagram shows how WAL failover works at a high level. For more information about the WAL, memtables, and SSTables, refer to the [Architecture » Storage Layer documentation]({% link {{ page.version.version }}/architecture/storage-layer.md %}). -WAL failover overview diagram +WAL failover overview diagram ## Create and configure a cluster to be ready for WAL failover @@ -280,7 +280,7 @@ In [DB Console's **Advanced Debug** page]({% link {{ page.version.version }}/ui- Set the source of these metrics to be the node where you are running the disk stall/unstall script. -WAL Failover Metrics Chart +WAL Failover Metrics Chart Notice there is a switchover followed by each stall. The node with the stalled disk continues to perform normal operations during and after WAL failover, as the stalls are transient and shorter than the current value of [`COCKROACH_ENGINE_MAX_SYNC_DURATION_DEFAULT`](#important-environment-variables). @@ -377,7 +377,7 @@ In a [multi-store](#multi-store-config) cluster, if a disk for a store has a tra The following diagram shows the behavior of WAL writes during a disk stall with and without WAL failover enabled. -how long WAL writes take during a disk stall with and without WAL failover enabled +how long WAL writes take during a disk stall with and without WAL failover enabled ## FAQs diff --git a/src/current/v25.2/window-functions.md b/src/current/v25.2/window-functions.md index b56b3c4e4e5..a042d751204 100644 --- a/src/current/v25.2/window-functions.md +++ b/src/current/v25.2/window-functions.md @@ -94,7 +94,7 @@ Its operation can be described as follows (numbered steps listed here correspond 1. The window function `SUM(revenue) OVER ()` operates on a window frame containing all rows of the query output. 1. The window function `SUM(revenue) OVER (PARTITION BY city)` operates on several window frames in turn; each frame contains the `revenue` columns for a different city [partition]({% link {{ page.version.version }}/partitioning.md %}) (Amsterdam, Boston, L.A., etc.). -Window function diagram +Window function diagram ### Caveats