yugabyte · def- · Mar 2, 2022
diff --git a/docs/content/latest/api/ysql/datatypes/type_datetime/conceptual-background.md b/docs/content/latest/api/ysql/datatypes/type_datetime/conceptual-background.md
@@ -12,7 +12,7 @@ isTocNested: true
 showAsideToc: true
 ---
 
-The following subsections provide the conceptual background for the accounts of the _date-time_ data types that the table shown in the [Synopsis](../intro/#synopsis) lists and for the operations that the _date-time_ operators and built-in SQL functions perform.
+The following subsections provide the conceptual background for the accounts of the _date-time_ data types that the table shown in the [Synopsis](../#synopsis) lists and for the operations that the _date-time_ operators and built-in SQL functions perform.
 
 - [Absolute time and the UTC Time Standard](#absolute-time-and-the-utc-time-standard)
 - [Wall-clock-time and local time](#wall-clock-time-and-local-time)
@@ -73,7 +73,7 @@ It quietly succeeds and produces the obvious result. (The _::text_ typecast of a
  4713-01-01 00:00:00 BC | 294276-01-01 00:00:00
 ```
 
-The values, _4713 BC_ and _294276_ AD, are given in the [table](../intro/#synopsis) in the _"Introduction"_ section to the present _date-time_ data types major section.
+The values, _4713 BC_ and _294276_ AD, are given in the [table](../#synopsis) in the _"Introduction"_ section to the present _date-time_ data types major section.
 
 ## Wall-clock-time and local time
 

diff --git a/...ype_datetime/date-time-data-types-semantics/type-interval/interval-utilities.md b/...ype_datetime/date-time-data-types-semantics/type-interval/interval-utilities.md
@@ -67,7 +67,7 @@ Here's an example of such a _text_ literal:
 
 PostgreSQL defines two fundamentally different data type families for representing real numbers and for supporting arithmetic using their values. Of course, YSQL inherits this regime.
 
-The PostgreSQL documentation uses the terms [Arbitrary Precision Numbers](https://www.postgresql.org/docs/11/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL) and [Floating-Point Numbers](https://www.postgresql.org/docs/11/datatype-numeric.html#DATATYPE-FLOAT) for these two kinds of data type. The first kind is exemplified by the data type _numeric_. And the second kind is exemplified by _double precision_. There are other variants in each class. But the entire _[date_time](../../../type_datetime/)_ section uses only these two (and uses only the unconstraint _numeric_ variant). Moreover, it uses _numeric_ only under duress. For example, you can easily round a _numeric_ value to some desired number of decimal places like this:
+The PostgreSQL documentation uses the terms [Arbitrary Precision Numbers](https://www.postgresql.org/docs/11/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL) and [Floating-Point Numbers](https://www.postgresql.org/docs/11/datatype-numeric.html#DATATYPE-FLOAT) for these two kinds of data type. The first kind is exemplified by the data type _numeric_. And the second kind is exemplified by _double precision_. There are other variants in each class. But the entire _[date_time](../../../)_ section uses only these two (and uses only the unconstraint _numeric_ variant). Moreover, it uses _numeric_ only under duress. For example, you can easily round a _numeric_ value to some desired number of decimal places like this:
 
 ```plpgsql
 select round(12.3456789::numeric, 3::int);

diff --git a/docs/content/latest/develop/docker/run-sample-apps.md b/docs/content/latest/develop/docker/run-sample-apps.md
@@ -34,8 +34,8 @@ Now you can observe the effects of the read/write operations generated by the lo
 
 ## 5. Review Yugastore architecture and code
 
-Details of Yugastore architecture are documented [here](../../develop/realworld-apps/ecommerce-app/). Source code is available in the [Yugastore GitHub repo](https://github.com/yugabyte/yugastore).
+Details of Yugastore architecture are documented [here](../../../realworld-apps/ecommerce-app/). Source code is available in the [Yugastore GitHub repo](https://github.com/yugabyte/yugastore).
 
 ## 6. Run IoT Fleet Management app
 
-After running Yugastore, Yugabyte recommends running the [IoT Fleet Management](../realworld-apps/iot-spark-kafka-ksql/) app. This app is built on top of YugabyteDB as the database (using the YCQL API), Confluent Kafka as the message broker, KSQL or Apache Spark Streaming for real-time analytics and Spring Boot as the application framework.
+After running Yugastore, Yugabyte recommends running the [IoT Fleet Management](../../../realworld-apps/iot-spark-kafka-ksql/) app. This app is built on top of YugabyteDB as the database (using the YCQL API), Confluent Kafka as the message broker, KSQL or Apache Spark Streaming for real-time analytics and Spring Boot as the application framework.
diff --git a/docs/content/latest/develop/kubernetes/run-sample-apps.md b/docs/content/latest/develop/kubernetes/run-sample-apps.md
@@ -85,8 +85,8 @@ The above output is the Admin UI URL and visiting the Tablet Servers page there
 
 ## 5. Review Yugastore architecture and code
 
-Details of Yugastore architecture are documented [here](../realworld-apps/ecommerce-app/). Source code is available in the [Yugastore GitHub repo](https://github.com/yugabyte/yugastore).
+Details of Yugastore architecture are documented [here](../../../realworld-apps/ecommerce-app/). Source code is available in the [Yugastore GitHub repo](https://github.com/yugabyte/yugastore).
 
 ## 6. Run IoT Fleet Management app
 
-After running Yugastore, Yugabyte recommends running the [IoT Fleet Management](../realworld-apps/iot-spark-kafka-ksql/) app. This app is built on top of YugabyteDB as the database (using the YCQL API), Confluent Kafka as the message broker, KSQL or Apache Spark Streaming for real-time analytics and Spring Boot as the application framework.
+After running Yugastore, Yugabyte recommends running the [IoT Fleet Management](../../../realworld-apps/iot-spark-kafka-ksql/) app. This app is built on top of YugabyteDB as the database (using the YCQL API), Confluent Kafka as the message broker, KSQL or Apache Spark Streaming for real-time analytics and Spring Boot as the application framework.
diff --git a/docs/content/latest/explore/indexes-constraints/gin.md b/docs/content/latest/explore/indexes-constraints/gin.md
@@ -16,7 +16,7 @@ showAsideToc: true
 
 <ul class="nav nav-tabs-alt nav-tabs-yb">
   <li >
-    <a href="../indexes-constraints-gin/" class="nav-link active">
+    <a href="../../indexes-constraints/gin/" class="nav-link active">
       <i class="icon-postgres" aria-hidden="true"></i>
       YSQL
     </a>

diff --git a/docs/content/latest/explore/indexes-constraints/primary-key-ysql.md b/docs/content/latest/explore/indexes-constraints/primary-key-ysql.md
@@ -38,7 +38,7 @@ The Primary Key constraint is a means to identify a specific row in a table uniq
 
 - To run the examples below, follow these steps to create a local [cluster](/latest/quick-start/) or in [Yugabyte Cloud](/latest/yugabyte-cloud/cloud-connect/).
 
-- Use the [YSQL shell](/latest/admin/ysqlsh/) for local clusters, or [Connect using Cloud shell](/latest/yugabyte-cloud/cloud-connect/connect-cloud-shell/) for Yugabyte Cloud, and create the yb_demo [database](latest/yugabyte-cloud/cloud-quickstart/qs-data/#create-a-database).
+- Use the [YSQL shell](/latest/admin/ysqlsh/) for local clusters, or [Connect using Cloud shell](/latest/yugabyte-cloud/cloud-connect/connect-cloud-shell/) for Yugabyte Cloud, and create the yb_demo [database](/latest/yugabyte-cloud/cloud-quickstart/qs-data/#create-a-database).
 
 ### Primary key for a single column
 

diff --git a/docs/content/latest/explore/multi-region-deployments/row-level-geo-partitioning.md b/docs/content/latest/explore/multi-region-deployments/row-level-geo-partitioning.md
@@ -395,7 +395,7 @@ created_at    | 2020-11-07 21:28:11.056236
 
 ## Step 5. Running distributed transactions
 
-So far, we have only been running `SELECT` and [single-row transactions](../../architecture/transactions/transactions-overview/#single-row-transactions). Geo-partitioning introduces a new complication for general distributed transactions.
+So far, we have only been running `SELECT` and [single-row transactions](../../../architecture/transactions/transactions-overview/#single-row-transactions). Geo-partitioning introduces a new complication for general distributed transactions.
 
 Let's say we want to run the following transaction:
 

diff --git a/docs/content/latest/explore/observability/grafana-dashboard/macos.md b/docs/content/latest/explore/observability/grafana-dashboard/macos.md
@@ -61,7 +61,7 @@ There are different ways to create a dashboard in Grafana. For this tutorial, yo
 
   ![Grafana dashboard](/images/ce/graf-server-status.png)
 
-- Since this example uses the `CassandraKeyValue` workload generator from the [Prometheus Integration](../../../../observability/prometheus-integration/macos/) page, you can see different YCQL related metrics in addition to the master and t-server statuses. The [source code](https://github.com/yugabyte/yugabyte-db/blob/master/java/yb-loadtester/src/main/java/com/yugabyte/sample/apps/CassandraSparkKeyValueCopy.java) of the application uses only SELECT statements for reads and INSERT statements for writes (aside from the initial CREATE TABLE). This means that throughput and latency can be measured using the metrics corresponding to the SELECT and INSERT statements.
+- Since this example uses the `CassandraKeyValue` workload generator from the [Prometheus Integration](../../../../explore/observability/prometheus-integration/macos/) page, you can see different YCQL related metrics in addition to the master and t-server statuses. The [source code](https://github.com/yugabyte/yugabyte-db/blob/master/java/yb-loadtester/src/main/java/com/yugabyte/sample/apps/CassandraSparkKeyValueCopy.java) of the application uses only SELECT statements for reads and INSERT statements for writes (aside from the initial CREATE TABLE). This means that throughput and latency can be measured using the metrics corresponding to the SELECT and INSERT statements.
 The following is a YCQL OPS and latency metrics :
 
   ![Grafana YCQL-OPS](/images/ce/graf-ycql-ops.png "YCQL-OPS")

diff --git a/docs/content/latest/explore/observability/prometheus-integration/kubernetes.md b/docs/content/latest/explore/observability/prometheus-integration/kubernetes.md
@@ -46,9 +46,9 @@ showAsideToc: true
 
 You can monitor your local YugabyteDB cluster with a local instance of [Prometheus](https://prometheus.io/), a popular standard for time-series monitoring of cloud native infrastructure. YugabyteDB services and APIs expose metrics in the Prometheus format at the `/prometheus-metrics` endpoint.
 
-For details on the metrics targets for YugabyteDB, see [Monitoring with Prometheus](../../../reference/configuration/default-ports/#monitoring-with-prometheus).
+For details on the metrics targets for YugabyteDB, see [Monitoring with Prometheus](../../../../reference/configuration/default-ports/#monitoring-with-prometheus).
 
-If you haven't installed YugabyteDB yet, do so first by following the [Quick Start](../../../quick-start/install/) guide.
+If you haven't installed YugabyteDB yet, do so first by following the [Quick Start](../../../../quick-start/install/) guide.
 
 ## 1. Create universe
 

diff --git a/docs/content/latest/explore/ysql-language-features/advanced-features/savepoints.md b/docs/content/latest/explore/ysql-language-features/advanced-features/savepoints.md
@@ -24,11 +24,11 @@ Savepoints are implemented in PostgreSQL using subtransactions.
 
 The relevant savepoint commands are:
 
-* [`SAVEPOINT <name>`](../../../api/ysql/the-sql-language/statements/savepoint_create) creates a savepoint.
+* [`SAVEPOINT <name>`](../../../../api/ysql/the-sql-language/statements/savepoint_create) creates a savepoint.
 
-* [`RELEASE SAVEPOINT <name>`](../../../api/ysql/the-sql-language/statements/savepoint_release) forgets about a savepoint. Note that you can use the same savepoint name more than once, so if there was an earlier savepoint with the same name, the name will now refer to that earlier savepoint. (In other words, the new savepoint gets popped off the stack of savepoints for that name.)
+* [`RELEASE SAVEPOINT <name>`](../../../../api/ysql/the-sql-language/statements/savepoint_release) forgets about a savepoint. Note that you can use the same savepoint name more than once, so if there was an earlier savepoint with the same name, the name will now refer to that earlier savepoint. (In other words, the new savepoint gets popped off the stack of savepoints for that name.)
 
-* [`ROLLBACK TO SAVEPOINT <name>`](../../../api/ysql/the-sql-language/statements/savepoint_rollback) rolls back to the database state as of the given savepoint, discarding all changes created after that savepoint, including the creation of new savepoints. Preserves the referenced savepoint, so that after one rollback it can be rolled back to again.
+* [`ROLLBACK TO SAVEPOINT <name>`](../../../../api/ysql/the-sql-language/statements/savepoint_rollback) rolls back to the database state as of the given savepoint, discarding all changes created after that savepoint, including the creation of new savepoints. Preserves the referenced savepoint, so that after one rollback it can be rolled back to again.
 
 ## Example
 

diff --git a/...t/latest/explore/ysql-language-features/going-beyond-sql/follower-reads-ycql.md b/...t/latest/explore/ysql-language-features/going-beyond-sql/follower-reads-ycql.md
@@ -34,7 +34,7 @@ showAsideToc: true
 
 With YugabyteDB, you can use follower reads to lower read latencies since the DB now has less work to do at read time including serving the read from the tablet followers. Follower reads is similar to reading from a cache, which can give more read IOPS with low latency but might have slightly stale yet timeline-consistent data (that is, no out of order is possible). In this tutorial, you will update a single key-value over and over, and read it from the tablet leader. While that workload is running, you will start another workload to read from a follower and verify that you are able to read from a tablet follower.
 
-YugabyteDB also allows you to specify the maximum staleness of data when reading from tablet followers. If the follower hasn't heard from the leader for  10 seconds (by default), the read request is forwarded to the leader. When there is a long distance between the tablet follower and the tablet leader, you might need to increase the duration. To change the duration for maximum staleness, add the [`yb-tserver` `--max_stale_read_bound_time_ms`](../../../reference/configuration/yb-tserver/#max-stale-read-bound-time-ms) flag and increase the value (default is 10 seconds). For details on how to add this flag when using `yb-ctl`, see [Creating a local cluster with custom flags](../../../admin/yb-ctl/#create-a-local-cluster-with-custom-flags).
+YugabyteDB also allows you to specify the maximum staleness of data when reading from tablet followers. If the follower hasn't heard from the leader for  10 seconds (by default), the read request is forwarded to the leader. When there is a long distance between the tablet follower and the tablet leader, you might need to increase the duration. To change the duration for maximum staleness, add the [`yb-tserver` `--max_stale_read_bound_time_ms`](../../../../reference/configuration/yb-tserver/#max-stale-read-bound-time-ms) flag and increase the value (default is 10 seconds). For details on how to add this flag when using `yb-ctl`, see [Creating a local cluster with custom flags](../../../../admin/yb-ctl/#create-a-local-cluster-with-custom-flags).
 
 ## 1. Create universe
 

diff --git a/docs/content/latest/integrations/apache-spark/scala.md b/docs/content/latest/integrations/apache-spark/scala.md
@@ -51,7 +51,7 @@ libraryDependencies += "com.yugabyte.spark" %% "spark-cassandra-connector" % "2.
 
 This tutorial assumes that you have:
 
-- installed YugabyteDB, created a universe, and are able to interact with it using the YCQL shell (`ycqlsh`). If not, please follow instructions in the [Quick start guide](../../quick-start/explore/ycql/).
+- installed YugabyteDB, created a universe, and are able to interact with it using the YCQL shell (`ycqlsh`). If not, please follow instructions in the [Quick start guide](../../../quick-start/explore/ycql/).
 
 - installed Scala version 2.12 or later and sbt 1.3.8 or later.
 

diff --git a/docs/content/latest/integrations/hasura/hasura-1.md b/docs/content/latest/integrations/hasura/hasura-1.md
@@ -20,7 +20,7 @@ For details on using Hasura, see the [Hasura GraphQL engine documentation](https
 
 Before using Hasura with YugabyteDB, perform the following:
 
-- Install and start YugabyteDB, as described in [Quick Start Guide](../../quick-start/).
+- Install and start YugabyteDB, as described in [Quick Start Guide](../../../quick-start/).
 
 - Install and start Hasura by following instructions provided in the Hasura [Quick Start with Docker](https://hasura.io/docs/latest/graphql/core/deployment/deployment-guides/docker.html). The configuration should be similar to PostgreSQL, except that the port should be `5433`. For a local Mac setup, the configuration should be as follows:
 
@@ -158,4 +158,4 @@ To list running containers, execute the following command:
 
 ```sh
 docker ps
-```
+```
diff --git a/docs/content/latest/integrations/liquibase.md b/docs/content/latest/integrations/liquibase.md
@@ -28,7 +28,7 @@ Before you can start using Liquibase, ensure that you have the following install
   ./bin/yugabyted status
   ```
 
-- Liquibase (see [Download Liquibase](https://www.liquibase.org/download)). For information on how to extract the package and configure Liquibase, see [Configuring Liquibase](configuring-liquibase).
+- Liquibase (see [Download Liquibase](https://www.liquibase.org/download)). For information on how to extract the package and configure Liquibase, see [Configuring Liquibase](#configuring-liquibase).
 
 - Liquibase-YugabyteDB extension JAR (access [liquibase-yugabytedb repository](https://github.com/liquibase/liquibase-yugabytedb) and download the latest `liquibase-yugabytedb-.jar`). The driver must be located in the `/lib` sub-directory of the directory to which you extracted Liquibase.
 
@@ -134,4 +134,4 @@ Upon successful migration, the following is displayed :
 
 ![img](/images/ee/liquibase.png)
 
-After migration of the first changelog, among other artifacts Liquibase creates a `databasechangelog` table within the database. This table keeps a detailed track of all the changesets that have been successfully completed.
+After migration of the first changelog, among other artifacts Liquibase creates a `databasechangelog` table within the database. This table keeps a detailed track of all the changesets that have been successfully completed.
diff --git a/docs/content/latest/releases/earlier-releases/v2.2.0.md b/docs/content/latest/releases/earlier-releases/v2.2.0.md
@@ -512,7 +512,7 @@ docker pull yugabytedb/yugabyte:2.2.0.0-b80
 * [CDC] Check for table properties equivalence when comparing schemas in 2DC setups and ignore properties that don't need to be the same. [#4233](https://github.com/yugabyte/yugabyte-db/issues/4233)
 * [DocDB] Allow multiple indexes to backfill or delete simultaneously. [#2784](https://github.com/yugabyte/yugabyte-db/issues/2784)
 * [DocDB] Transition to new leader gracefully during a leader stepdown. When a leader stepdown happens with no new leader candidate specified in the stepdown request, the peer simply steps down leaving the group with no leader until regular heartbeat timeouts are triggered. This change makes it so that the leader attempts to transition to the most up-to-date peer, if possible. [#4298](https://github.com/yugabyte/yugabyte-db/issues/4298)
-* Update [`yb-admin list_snapshots`](../../../admin/yb-admin/#list-snapshots) command to use `not_show_restored` option to exclude fully RESTORED entries. [#4351](ttps://github.com/yugabyte/yugabyte-db/issues/4351)
+* Update [`yb-admin list_snapshots`](../../../admin/yb-admin/#list-snapshots) command to use `not_show_restored` option to exclude fully RESTORED entries. [#4351](https://github.com/yugabyte/yugabyte-db/issues/4351)
 * [DocDB] Clean up leftover snapshot files from failed snapshots that resulted in remote bootstrap getting stuck in a failure loop. [#4745](https://github.com/yugabyte/yugabyte-db/issues/4745)
 * [DocDB] Clean up metadata in memory after deleting snapshots. [#4887](https://github.com/yugabyte/yugabyte-db/issues/4877)
 * [DocDB] Fix snapshots getting stuck in retry loop with deleted table. [#4610](https://github.com/yugabyte/yugabyte-db/issues/4877) and [#4302](https://github.com/yugabyte/yugabyte-db/issues/4302)

diff --git a/docs/content/latest/releases/earlier-releases/v2.3.1.md b/docs/content/latest/releases/earlier-releases/v2.3.1.md
@@ -46,7 +46,7 @@ docker pull yugabytedb/yugabyte:2.3.1.0-b15
 - Fixes OOM when using `COPY <table> FROM <file>` to load data from a large file to a table. [#5453](https://github.com/yugabyte/yugabyte-db/issues/5453)
 - Enable 2DC replication bootstrap for YSQL tables. This allows the producer to know where to start replicating from. [#5601](https://github.com/yugabyte/yugabyte-db/issues/5601)
 - Fix `CREATE TABLE` is 4-5x slower using Docker on Mac than not using Docker. Speeds up table creation by buffering writes to postgres system tables, caching pinned objects, and significantly reducing write RPC calls. [#3503](https://github.com/yugabyte/yugabyte-db/issues/3503)
-- Roll back the catalog version made in commit `46f3701` so that 2.3 upgrades can proceed. [#5408](ttps://github.com/yugabyte/yugabyte-db/issues/5408)
+- Roll back the catalog version made in commit `46f3701` so that 2.3 upgrades can proceed. [#5408](https://github.com/yugabyte/yugabyte-db/issues/5408)
 
 ### Core database
 

diff --git a/docs/content/latest/secure/tls-encryption/tls-authentication.md b/docs/content/latest/secure/tls-encryption/tls-authentication.md
@@ -16,7 +16,7 @@ showAsideToc: true
 
 <ul class="nav nav-tabs-alt nav-tabs-yb">
   <li >
-    <a href="/latest/secure/authentication/tls-authentication" class="nav-link active">
+    <a href="/latest/secure/tls-encryption/tls-authentication/" class="nav-link active">
       <i class="icon-postgres" aria-hidden="true"></i>
       YSQL
     </a>