vitessio · mattlord · Jan 30, 2023 · Jan 30, 2023
diff --git a/content/en/docs/archive/11.0/get-started/_index.md b/content/en/docs/archive/11.0/get-started/_index.md
@@ -5,4 +5,4 @@ weight: 2
 aliases: ['/docs/tutorials/']
 ---
 
-Vitess supports binary deployment on the following platforms. See also [Build On CentOS](../contributing/build-on-centos), [Build on MacOS](../contributing/build-on-macos), or [Build on Ubuntu](../contributing/build-on-ubuntu) if you are interesting in building your own binary, or contributing to Vitess.
+Vitess supports binary deployment on the following platforms. See also [Build On CentOS](../../../contributing/build-on-centos), [Build on MacOS](../../../contributing/build-on-macos), or [Build on Ubuntu](../../../contributing/build-on-ubuntu) if you are interesting in building your own binary, or contributing to Vitess.
diff --git a/content/en/docs/archive/11.0/reference/features/schema-management.md b/content/en/docs/archive/11.0/reference/features/schema-management.md
@@ -31,9 +31,9 @@ This section describes the following vtctl commands, which let you look at the s
 
 ### GetSchema
 
-The [GetSchema](../../../reference/programs/vtctl/#getschema) command displays the full schema for a tablet or a subset of the tablet's tables. When you call `GetSchema`, you specify the tablet alias that uniquely identifies the tablet. The `<tablet alias>` argument value has the format `<cell name>-<uid>`.
+The [GetSchema](../../programs/vtctl/schema-version-permissions#getschema) command displays the full schema for a tablet or a subset of the tablet's tables. When you call `GetSchema`, you specify the tablet alias that uniquely identifies the tablet. The `<tablet alias>` argument value has the format `<cell name>-<uid>`.
 
-**Note**: You can use the [`vtctl ListAllTablets`](../../../reference/programs/vtctl/#listalltablets) command to retrieve a list of tablets in a cell and their unique IDs.
+**Note**: You can use the [`vtctl ListAllTablets`](../../programs/vtctl/generic#listalltablets) command to retrieve a list of tablets in a cell and their unique IDs.
 
 The following example retrieves the schema for the tablet with the unique ID test-000000100:
 
@@ -43,7 +43,7 @@ GetSchema test-000000100
 
 ### ValidateSchemaShard
 
-The [`ValidateSchemaShard`](../../../reference/programs/vtctl/#validateschemashard) command confirms that for a given keyspace, all of the replica tablets in a specified shard have the same schema as the primary tablet in that shard. When you call `ValidateSchemaShard`, you specify both the keyspace and the shard that you are validating.
+The [`ValidateSchemaShard`](../../programs/vtctl/schema-version-permissions#validateschemashard) command confirms that for a given keyspace, all of the replica tablets in a specified shard have the same schema as the primary tablet in that shard. When you call `ValidateSchemaShard`, you specify both the keyspace and the shard that you are validating.
 
 The following command confirms that the primary and replica tablets in shard `0` all have the same schema for the `user` keyspace:
 
@@ -53,7 +53,7 @@ ValidateSchemaShard user/0
 
 ### ValidateSchemaKeyspace
 
-The [`ValidateSchemaKeyspace`](../../../reference/programs/vtctl/#validateschemakeyspace) command confirms that all of the tablets in a given keyspace have the the same schema as the primary tablet on shard `0` in that keyspace. Thus, whereas the `ValidateSchemaShard` command confirms the consistency of the schema on tablets within a shard for a given keyspace, `ValidateSchemaKeyspace` confirms the consistency across all tablets in all shards for that keyspace.
+The [`ValidateSchemaKeyspace`](../../programs/vtctl/schema-version-permissions#validateschemakeyspace) command confirms that all of the tablets in a given keyspace have the the same schema as the primary tablet on shard `0` in that keyspace. Thus, whereas the `ValidateSchemaShard` command confirms the consistency of the schema on tablets within a shard for a given keyspace, `ValidateSchemaKeyspace` confirms the consistency across all tablets in all shards for that keyspace.
 
 The following command confirms that all tablets in all shards have the same schema as the primary tablet in shard 0 for the user keyspace:
 
@@ -63,11 +63,11 @@ ValidateSchemaKeyspace user
 
 ### GetVSchema
 
-The [`GetVSchema`](../../../reference/programs/vtctl/#getvschema) command displays the global VSchema for the specified keyspace.
+The [`GetVSchema`](../../programs/vtctl/schema-version-permissions#getvschema) command displays the global VSchema for the specified keyspace.
 
 ### GetSrvVSchema
 
-The [`GetSrvVSchema`](../../../reference/programs/vtctl/#getsrvvschema) command displays the combined VSchema for a given cell.
+The [`GetSrvVSchema`](../../programs/vtctl/serving-graph#getsrvvschema) command displays the combined VSchema for a given cell.
 
 ## Changing your schema
 
@@ -128,8 +128,8 @@ If a schema change gets rejected because it affects too many rows, you can speci
 
 ### ApplyVSchema
 
-The [`ApplyVSchema`](../../../reference/programs/vtctl/#applyvschema) command applies the specified VSchema to the keyspace. The VSchema can be specified as a string or in a file.
+The [`ApplyVSchema`](../../programs/vtctl/schema-version-permissions#applyvschema) command applies the specified VSchema to the keyspace. The VSchema can be specified as a string or in a file.
 
 ### RebuildVSchemaGraph
 
-The [`RebuildVSchemaGraph`](../../../reference/programs/vtctl/#rebuildvschemagraph) command propagates the global VSchema to a specific cell or the list of specified cells.
+The [`RebuildVSchemaGraph`](../../programs/vtctl/schema-version-permissions#rebuildvschemagraph) command propagates the global VSchema to a specific cell or the list of specified cells.
diff --git a/content/en/docs/archive/11.0/reference/features/vindexes.md b/content/en/docs/archive/11.0/reference/features/vindexes.md
@@ -64,7 +64,7 @@ The lookup table that implements a Lookup Vindex can be sharded or unsharded.  N
 
 Vitess allows for the transparent population of these lookup table rows by assigning an owner table, which is the main table that requires this lookup. When a row is inserted into this owner table, the lookup row for it is created in the lookup table. The lookup row is also deleted upon a delete of the corresponding row in the owner table. These essentially result in distributed transactions, which traditionally require 2PC to guarantee atomicity.
 
-Consistent lookup vindexes use an alternate approach that makes use of careful locking and transaction sequences to guarantee consistency without using 2PC. This gives the best of both worlds, with the benefit of a consistent cross-shard vindex without paying the price of 2PC. To read more about what makes a consistent lookup vindex different from a standard lookup vindex read our [consistent lookup vindexes design documentation](../../../design-docs/query-serving/clookup-vindex/).
+Consistent lookup vindexes use an alternate approach that makes use of careful locking and transaction sequences to guarantee consistency without using 2PC. This gives the best of both worlds, with the benefit of a consistent cross-shard vindex without paying the price of 2PC. To read more about what makes a consistent lookup vindex different from a standard lookup vindex read our [consistent lookup vindexes design documentation](https://github.com/vitessio/vitess/issues/4855).
 
 There are currently two vindex types in Vitess for consistent lookup:
 

diff --git a/content/en/docs/archive/11.0/reference/programs/vtctl/_index.md b/content/en/docs/archive/11.0/reference/programs/vtctl/_index.md
@@ -68,7 +68,7 @@ aliases: ['/docs/reference/vitess-api/','/docs/reference/vtctl/']
 | :-------- | :--------------- |
 | [CreateKeyspace](../vtctl/keyspaces#createkeyspace) | `CreateKeyspace  [-sharding_column_name=name] [-sharding_column_type=type] [-served_from=tablettype1:ks1,tablettype2:ks2,...] [-force] [-keyspace_type=type] [-base_keyspace=base_keyspace] [-snapshot_time=time] <keyspace name>` |
 | [DeleteKeyspace](../vtctl/keyspaces#deletekeyspace) | `DeleteKeyspace  [-recursive] <keyspace>` |
-| [RemoveKeyspaceCell](../vtctl/keyspaces#removekeyspacesell) | `RemoveKeyspaceCell  [-force] [-recursive] <keyspace> <cell>` |
+| [RemoveKeyspaceCell](../vtctl/keyspaces#removekeyspacecell) | `RemoveKeyspaceCell  [-force] [-recursive] <keyspace> <cell>` |
 | [GetKeyspace](../vtctl/keyspaces#getkeyspace) | `GetKeyspace  <keyspace>` |
 | [GetKeyspaces](../vtctl/keyspaces#getkeyspaces) | `GetKeyspaces  ` |
 | [SetKeyspaceShardingInfo](../vtctl/keyspaces#setkeyspaceshardinginfo) | `SetKeyspaceShardingInfo  [-force] <keyspace name> [<column name>] [<column type>]` |
@@ -80,12 +80,12 @@ aliases: ['/docs/reference/vitess-api/','/docs/reference/vtctl/']
 | [MoveTables (v1)](../../vreplication/v1/movetables) | `MoveTables  -v1 [-cell=<cell>] [-tablet_types=<source_tablet_types>] -workflow=<workflow> <source_keyspace> <target_keyspace> <table_specs>` |
 | [MoveTables (v2)](../../vreplication/movetables) | `MoveTables  <options> <action> <workflow identifier>` |
 | [DropSources](../../vreplication/v1/dropsources) | `DropSources  [-dry_run] <keyspace.workflow>` |
-| [CreateLookupVindex](../vtctl/keyspaces#createLookupvindex) | `CreateLookupVindex  [-cell=<cell>] [-tablet_types=<source_tablet_types>] <keyspace> <json_spec>` |
+| [CreateLookupVindex](../vtctl/keyspaces#createlookupvindex) | `CreateLookupVindex  [-cell=<cell>] [-tablet_types=<source_tablet_types>] <keyspace> <json_spec>` |
 | [ExternalizeVindex](../vtctl/keyspaces#externalizevindex) | `ExternalizeVindex  <keyspace>.<vindex>` |
 | [Materialize](../vtctl/keyspaces#materialize) | `Materialize  <json_spec>, example : '{"workflow": "aaa", "source_keyspace": "source", "target_keyspace": "target", "table_settings": [{"target_table": "customer", "source_expression": "select * from customer", "create_ddl": "copy"}]}'` |
 | [SplitClone](../vtctl/keyspaces#splitclone) | `SplitClone  <keyspace> <from_shards> <to_shards>` |
 | [VerticalSplitClone](../vtctl/keyspaces#verticalsplitclone) | `VerticalSplitClone  <from_keyspace> <to_keyspace> <tables>` |
-| [VDiff](../vtctl/keyspaces#VDiff) | `VDiff  [-source_cell=<cell>] [-target_cell=<cell>] [-tablet_types=<source_tablet_types>] [-filtered_replication_wait_time=30s] <keyspace.workflow>` |
+| [VDiff](../vtctl/keyspaces#vdiff) | `VDiff  [-source_cell=<cell>] [-target_cell=<cell>] [-tablet_types=<source_tablet_types>] [-filtered_replication_wait_time=30s] <keyspace.workflow>` |
 | [MigrateServedTypes](../vtctl/keyspaces#migrateservedtypes) | `MigrateServedTypes  [-cells=c1,c2,...] [-reverse] [-skip-refresh-state] <keyspace/shard> <served tablet type>` |
 | [MigrateServedFrom](../vtctl/keyspaces#migrateservedfrom) | `MigrateServedFrom  [-cells=c1,c2,...] [-reverse] <destination keyspace/shard> <served tablet type>` |
 | [SwitchReads](../../vreplication/v1/switchreads) | `SwitchReads  [-cells=c1,c2,...] [-reverse] -tablet_type={replica\|rdonly} [-dry-run] <keyspace.workflow>` |
@@ -133,7 +133,7 @@ aliases: ['/docs/reference/vitess-api/','/docs/reference/vtctl/']
 | :-------- | :--------------- |
 | [GetSrvKeyspaceNames](../vtctl/serving-graph#getsrvkeyspacenames) | `GetSrvKeyspaceNames  <cell>` |
 | [GetSrvKeyspace](../vtctl/serving-graph#getsrvkeyspace) | `GetSrvKeyspace  <cell> <keyspace>` |
-| [GetSrvVSchema](../vtctl/serving-graph#getsrvsvchema) | `GetSrvVSchema  <cell>` |
+| [GetSrvVSchema](../vtctl/serving-graph#getsrvvschema) | `GetSrvVSchema  <cell>` |
 | [DeleteSrvVSchema](../vtctl/serving-graph#deletesrvvschema) | `DeleteSrvVSchema  <cell>` |
 
 ### Replication Graph

diff --git a/content/en/docs/archive/11.0/reference/vreplication/flags.md b/content/en/docs/archive/11.0/reference/vreplication/flags.md
@@ -84,7 +84,7 @@ When enabled, vttablet will start the _watcher_ which streams the MySQL replicat
 **Default** false\
 **Applicable on** source
 
-All vstreams on a tablet share a common engine. vstreams that are lagging might see a newer (and hence incorrect) version of the schema in case DDLs were applied in between. Also, reloading schemas is an expensive operation. If there are multiple vstreams, each of them will separately receive a DDL event resulting in multiple reloads for the same DDL. The [tracker](../../../design-docs/vreplication/vstream/tracker/) addresses these issues.
+All vstreams on a tablet share a common engine. vstreams that are lagging might see a newer (and hence incorrect) version of the schema in case DDLs were applied in between. Also, reloading schemas is an expensive operation. If there are multiple vstreams, each of them will separately receive a DDL event resulting in multiple reloads for the same DDL. The [tracker](../internal/tracker) addresses these issues.
 
 When enabled, vttablet will start the _tracker_ which runs a separate vstream that monitors DDLs and stores the version of the schema at the position that a DDL is applied in the schema version table. So if we are streaming events from the past we can get the corresponding schema and interpret the fields from the event correctly.
 

diff --git a/content/en/docs/archive/11.0/reference/vreplication/metrics.md b/content/en/docs/archive/11.0/reference/vreplication/metrics.md
@@ -4,7 +4,7 @@ description: Metrics related to vreplication functionality
 weight: 85
 ---
 
-VReplication exports several metrics using the expvars interface. These are available at the `debug/vars` endpoint of vttablet's http status pages. [More details here](../../features/monitoring/#3-push-based-metrics-system#3-push-based-metrics-system)
+VReplication exports several metrics using the expvars interface. These are available at the `debug/vars` endpoint of vttablet's http status pages. [More details here](../../features/monitoring/#3-push-based-metrics-system)
 
 ## Target Metrics
 

diff --git a/content/en/docs/archive/11.0/reference/vreplication/movetables.md b/content/en/docs/archive/11.0/reference/vreplication/movetables.md
@@ -211,14 +211,14 @@ All workflows are identified by `targetKeyspace.workflow` where `targetKeyspace`
 
 For those wanting to try out Vitess for the first time, MoveTables provides an easy way to route part of their workload to Vitess with the ability to migrate back at any time without any risk. You point a vttablet to your existing MySQL installation, spin up an unsharded Vitess cluster and use a MoveTables workflow to start serving some tables from Vitess. You can also go further and use a Reshard workflow to experiment with a sharded version of a part of your database.
 
-See this [user guide](../../../../../docs/user-guides/configuration-advanced/unmanaged-tablet/#move-legacytable-to-the-commerce-keyspace) for detailed steps.
+See this [user guide](../../../user-guides/configuration-advanced/unmanaged-tablet#move-legacytable-to-the-commerce-keyspace) for detailed steps.
 
 ### Vertical Sharding
 
 For existing Vitess users you can easily move one or more tables to another keyspace, either for balancing load or as preparation for sharding your tables.
 
-See this [user guide](../../../../../docs/user-guides/migration/move-tables/) which describes how MoveTables works in the local example provided in the Vitess repo.
+See this [user guide](../../../user-guides/migration/move-tables) which describes how MoveTables works in the local example provided in the Vitess repo.
 
 ### More Reading
 
-* [MoveTables in practice](../../../../../docs/concepts/move-tables/)
+* [MoveTables in practice](../../../concepts/move-tables)
diff --git a/...n/docs/archive/11.0/user-guides/schema-changes/managed-online-schema-changes.md b/...n/docs/archive/11.0/user-guides/schema-changes/managed-online-schema-changes.md
@@ -27,7 +27,7 @@ As general overview:
 - Tablets will independently run schema migrations:
   - `ALTER TABLE` statements run via `VReplication`, `gh-ost` or `pt-online-schema-change`, as per selected [strategy](../ddl-strategies)
   - `CREATE TABLE` statements run directly.
-  - `DROP TABLE` statements run [safely and lazily](../../../design-docs/table-lifecycle/safe-lazy-drop-tables/).
+  - `DROP TABLE` statements run [safely and lazily](https://github.com/vitessio/vitess/blob/main/doc/design-docs/SafeLazyDropTables.md).
 - Vitess provides the user a mechanism to view migration status, cancel or retry migrations, based on the job ID.
 
 ## Syntax
@@ -149,7 +149,7 @@ A migration can be in any one of these states:
 
 A migration is said to be _pending_ if we expect it to run and complete. Pending migrations are those in `queued`, `ready` and `running` states.
 
-For more about internals of the scheduler and how migration states are controlled, see [Online DDL Scheduler](../../../design-docs/online-ddl/scheduler)
+For more about internals of the scheduler and how migration states are controlled, see [Online DDL Scheduler](https://github.com/vitessio/vitess/blob/main/doc/design-docs/OnlineDDLScheduler.md)
 
 ## Configuration
 

diff --git a/content/en/docs/archive/11.0/user-guides/schema-changes/recoverable-migrations.md b/content/en/docs/archive/11.0/user-guides/schema-changes/recoverable-migrations.md
@@ -23,7 +23,7 @@ Whether by planned operation or an unplanned failure, an `online` migration's VR
 
 When a replica tablet is promoted as `primary`, it notices the VReplication stream, which is meant to be active and running. It sets up the connections and processes to resume its work. It is possible that some retries will take place as the stream re-evaluates its source of data.
 
-The [Online DDL Scheduler](../../../design-docs/online-ddl/scheduler) detects the running stream, and identifies it as having been created by a different tablet. It assumes ownership of the stream and proceeds to follow its progress till completion.
+The [Online DDL Scheduler](https://github.com/vitessio/vitess/blob/main/doc/design-docs/OnlineDDLScheduler.md) detects the running stream, and identifies it as having been created by a different tablet. It assumes ownership of the stream and proceeds to follow its progress till completion.
 
 The stream must be no more than `10` minutes stale, otherwise the scheduler marks the migration as failed.
 

diff --git a/content/en/docs/archive/11.0/user-guides/sql/vtexplain-in-bulk.md b/content/en/docs/archive/11.0/user-guides/sql/vtexplain-in-bulk.md
@@ -12,7 +12,7 @@ This document covers the way the [VTexplain tool](../../../reference/programs/vt
 
 You can find a prebuilt binary version of the VTexplain tool in [the most recent release of Vitess](https://github.com/vitessio/vitess/releases/).
 
-You can also build the `vtexplain` binary in your environment. To build this binary, refer to the [build guide](../../../contributing) for your OS.
+You can also build the `vtexplain` binary in your environment. To build this binary, refer to the [build guide](../../../../contributing) for your OS.
 
 ## Overview
 

diff --git a/content/en/docs/archive/12.0/get-started/_index.md b/content/en/docs/archive/12.0/get-started/_index.md
@@ -5,4 +5,4 @@ weight: 2
 aliases: ['/docs/tutorials/']
 ---
 
-Vitess supports binary deployment on the following platforms. See also [Build On CentOS](../contributing/build-on-centos), [Build on MacOS](../contributing/build-on-macos), or [Build on Ubuntu](../contributing/build-on-ubuntu) if you are interesting in building your own binary, or contributing to Vitess.
+Vitess supports binary deployment on the following platforms. SSee also [Build On CentOS](../../contributing/build-on-centos), [Build on MacOS](../../../contributing/build-on-macos.md), or [Build on Ubuntu](../../../contributing/build-on-ubuntu) if you are interesting in building your own binary, or contributing to Vitess.