moved the splitting up of Fetch into a separate PR, fixed links for this PR

Author: bsanchez-the-roach

src/current/_includes/molt/molt-docker.md

@@ -2,7 +2,7 @@
 
 MOLT Fetch, Verify, and Replicator are likely to run more slowly in a Docker container than on a local machine. To improve performance, increase the memory or compute resources, or both, on your Docker container.
 
-{% if page.name == "molt-fetch.md" or page.name == "molt-fetch-install.md" %}
+{% if page.name == "molt-fetch.md" %}
 #### Authentication
 
 When using MOLT Fetch with [cloud storage](#bucket-path), it is necessary to specify volumes and environment variables, as described in the following sections for [Google Cloud Storage](#google-cloud-storage) and [Amazon S3](#amazon-s3). 

src/current/_includes/molt/molt-drop-constraints-indexes.md

@@ -1,5 +1,5 @@
 To optimize data load performance, drop all non-`PRIMARY KEY` [constraints]({% link {{ site.current_cloud_version }}/alter-table.md %}#drop-constraint) and [indexes]({% link {{site.current_cloud_version}}/drop-index.md %}) on the target CockroachDB database before migrating:
-{% if page.name == "molt-fetch.md" or page.name == "molt-fetch-best-practices.md" %}
+{% if page.name == "molt-fetch.md" %}
 	- [`FOREIGN KEY`]({% link {{ site.current_cloud_version }}/foreign-key.md %})
 	- [`UNIQUE`]({% link {{ site.current_cloud_version }}/unique.md %})
 	- [Secondary indexes]({% link {{ site.current_cloud_version }}/schema-design-indexes.md %})

src/current/_includes/molt/molt-install.md

@@ -22,7 +22,7 @@ To display the current version of each binary, run `molt --version` and `replica
 
 For previous binaries, refer to the [MOLT version manifest](https://molt.cockroachdb.com/molt/cli/versions.html). {% if page.name != "molt.md" %}For release details, refer to the [MOLT changelog]({% link releases/molt.md %}).{% endif %}
 
-{% if page.name == "molt-fetch.md" or page.name == "molt.md"  or page.name == "molt-fetch-install" %}
+{% if page.name == "molt-fetch.md" or page.name == "molt.md" %}
 {{site.data.alerts.callout_info}}
 MOLT Fetch is supported on Red Hat Enterprise Linux (RHEL) 9 and above.
 {{site.data.alerts.end}}
@@ -55,7 +55,7 @@ docker pull cockroachdb/molt:oracle-latest
 ~~~
 {% endif %}
 
-{% if page.name != "molt-fetch.md" and page.name != "molt-fetch-install.md" %}
+{% if page.name != "molt-fetch.md" %}
 #### MOLT Replicator
 
 [Docker images for MOLT Replicator](https://hub.docker.com/r/cockroachdb/replicator/tags) are also available as a standalone binary:

src/current/molt/migrate-bulk-load.md

@@ -21,7 +21,7 @@ Perform a one-time bulk load of source data into CockroachDB.
 
 Perform the bulk load of the source data.
 
-1. Run the [MOLT Fetch]({% link molt/molt-fetch-overview.md %}) command to move the source data into CockroachDB. This example command passes the source and target connection strings [as environment variables](#secure-connections), writes [intermediate files](#intermediate-file-storage) to S3 storage, and uses the `truncate-if-exists` [table handling mode](#table-handling-mode) to truncate the target tables before loading data. It limits the migration to a single schema and filters for three specific tables. The [data load mode](#data-load-mode) defaults to `IMPORT INTO`. Include the `--ignore-replication-check` flag to skip replication checkpoint queries, which eliminates the need to configure the source database for logical replication.
+1. Run the [MOLT Fetch]({% link molt/molt-fetch.md %}) command to move the source data into CockroachDB. This example command passes the source and target connection strings [as environment variables](#secure-connections), writes [intermediate files](#intermediate-file-storage) to S3 storage, and uses the `truncate-if-exists` [table handling mode](#table-handling-mode) to truncate the target tables before loading data. It limits the migration to a single schema and filters for three specific tables. The [data load mode](#data-load-mode) defaults to `IMPORT INTO`. Include the `--ignore-replication-check` flag to skip replication checkpoint queries, which eliminates the need to configure the source database for logical replication.
 
 	<section class="filter-content" markdown="1" data-scope="postgres">
 	{% include_cached copy-clipboard.html %}
@@ -91,6 +91,6 @@ Perform a cutover by resuming application traffic, now to CockroachDB.
 - [Migration Overview]({% link molt/migration-overview.md %})
 - [Migration Strategy]({% link molt/migration-strategy.md %})
 - [MOLT Schema Conversion Tool]({% link cockroachcloud/migrations-page.md %})
-- [MOLT Fetch]({% link molt/molt-fetch-overview.md %})
+- [MOLT Fetch]({% link molt/molt-fetch.md %})
 - [MOLT Verify]({% link molt/molt-verify.md %})
 - [Migration Failback]({% link molt/migrate-failback.md %})

src/current/molt/migrate-to-cockroachdb.md

@@ -11,8 +11,8 @@ MOLT Fetch supports various migration flows using [MOLT Fetch modes]({% link mol
 
 |                            Migration flow                           |             Mode             |                                         Description                                         |                                                 Best for                                                |
 |---------------------------------------------------------------------|------------------------------|---------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|
-| [Bulk load]({% link molt/migrate-bulk-load.md %})                   | `--mode data-load`           | Perform a one-time bulk load of source data into CockroachDB.                               | Testing, migrations with [planned downtime]({% link molt/migration-strategy.md %}#approach-to-downtime) |
-| [Load and replicate]({% link molt/migrate-load-replicate.md %})     | MOLT Fetch + MOLT Replicator | Load source data using MOLT Fetch, then replicate subsequent changes using MOLT Replicator. | [Minimal downtime]({% link molt/migration-strategy.md %}#approach-to-downtime) migrations               |
+| [Bulk load]({% link molt/migrate-bulk-load.md %})                   | `--mode data-load`           | Perform a one-time bulk load of source data into CockroachDB.                               | Testing, migrations with [planned downtime]({% link molt/migration-considerations.md %}#permissible-downtime) |
+| [Load and replicate]({% link molt/migrate-load-replicate.md %})     | MOLT Fetch + MOLT Replicator | Load source data using MOLT Fetch, then replicate subsequent changes using MOLT Replicator. | [Minimal downtime]({% link molt/migration-considerations.md %}#permissible-downtime) migrations               |
 | [Resume replication]({% link molt/migrate-resume-replication.md %}) | `--mode replication-only`    | Resume replication from a checkpoint after interruption.                                    | Resuming interrupted migrations, post-load sync                                                         |
 | [Failback]({% link molt/migrate-failback.md %})                     | `--mode failback`            | Replicate changes from CockroachDB back to the source database.                             | [Rollback]({% link molt/migrate-failback.md %}) scenarios                                               |
 

src/current/molt/migration-considerations-phases.md

@@ -48,11 +48,11 @@ Tips for picking slices:
 
 Phased and unphased migrations are both supported natively by MOLT.
 
-By default, [MOLT Fetch]() moves all data from the source database to CockroachDB. However, you can use the `--schema-filter`, `--table-filter`, and `--filter-path` flags to selective migrate data from the source to the target. Learn more about [schema and table selection]({% link molt/molt-fetch-usage.md %}#schema-and-table-selection) and [selective data movement]({% link molt/molt-fetch-usage.md %}#selective-data-movement), both of which can enable a phased migration.
+By default, [MOLT Fetch]({% link molt/molt-fetch.md %}) moves all data from the source database to CockroachDB. However, you can use the `--schema-filter`, `--table-filter`, and `--filter-path` flags to selective migrate data from the source to the target. Learn more about [schema and table selection]({% link molt/molt-fetch.md %}#schema-and-table-selection) and [selective data movement]({% link molt/molt-fetch.md %}#selective-data-movement), both of which can enable a phased migration.
 
-Similarly, you can use [MOLT Verify]()'s `--schema-filter` and `--table-filter` flags to run validation checks on subsets of the data in your source and target databases. In a phased migration, you will likely want to verify data at the end of each migration phase, rather than at the end of the entire migration.
+Similarly, you can use [MOLT Verify]({% link molt/molt-verify.md %})'s `--schema-filter` and `--table-filter` flags to run validation checks on subsets of the data in your source and target databases. In a phased migration, you will likely want to verify data at the end of each migration phase, rather than at the end of the entire migration.
 
-[MOLT Replicator]() replicates full tables by default. If you choose to combine phased migration with [continuous replication]({% link molt/migration-considerations-replication.md %}), you will either need to select phases that include whole tables, or else use [userscripts]({% link molt/molt-replicator.md %}#flags) to select rows to replicate.
+[MOLT Replicator]({% link molt/molt-replicator.md %}) replicates full tables by default. If you choose to combine phased migration with [continuous replication]({% link molt/migration-considerations-replication.md %}), you will either need to select phases that include whole tables, or else use [userscripts]({% link molt/molt-replicator.md %}#flags) to select rows to replicate.
 
 ## Example sequences
 
@@ -73,4 +73,4 @@ Similarly, you can use [MOLT Verify]()'s `--schema-filter` and `--table-filter`
 - [Migration Overview]({% link molt/migration-overview.md %})
 - [Migration Considerations]({% link molt/migration-considerations.md %})
 - [Continuous Replication]({% link molt/migration-considerations-replication.md %})
-- [MOLT Fetch]({% link molt/molt-fetch-overview.md %})
+- [MOLT Fetch]({% link molt/molt-fetch.md %})

src/current/molt/migration-considerations.md

@@ -30,7 +30,7 @@ When deciding on the options for each migration variable, consider the following
 
 ### Permissible downtime
 
-How much downtime can your application tolerate during the migration? This is one of the most critical factors in determining your migration approach, and it may influence your choices for [migration granularity](), [continuous replication](), and [cutover strategy]().
+How much downtime can your application tolerate during the migration? This is one of the most critical factors in determining your migration approach, and it may influence your choices for [migration granularity]({% link molt/migration-considerations-phases.md %}), [continuous replication]({% link molt/migration-considerations-replication.md %}), and [cutover strategy]({% link molt/migration-considerations-cutover.md %}).
 
 - **Planned downtime** is made known to your users in advance. It involves taking the application offline, conducting the migration, and bginging the application back online on CockroachDB.
 
@@ -40,29 +40,29 @@ How much downtime can your application tolerate during the migration? This is on
 
 - **Minimal downtime** impacts as few customers as possible, ideally without impacting their regular usage. If your application is intentionally offline at certain times (e.g., outside business hours), you can migrate the data without users noticing. Alternatively, if your application's functionality is not time-sensitive (e.g., it sends batched messages or emails), you can queue requests while the system is offline and process them after completing the migration to CockroachDB.
 
-- **Near-zero downtime** is necessary for mission-critical applications. For these migrations, consider cutover strategies that keep applications online for as long as possible, and which utilize [continuous replication]().
+- **Near-zero downtime** is necessary for mission-critical applications. For these migrations, consider cutover strategies that keep applications online for as long as possible, and which utilize [continuous replication]({% link molt/migration-considerations-replication.md %}).
 
 In addition to downtime duration, consider whether your application could support windows of **reduced functionality** in which some, but not all, application functionality is brought offline. For example, you can disable writes but not reads while you migrate the application data, and queue data to be written after completing the migration.
 
 ### Migration timeframe and allowable complexity
 
-When do you need to complete the migration? How many team members can be allocated for this effort? How much complex orchestration can your team manage? These factors may influence your choices for [migration granularity](), [continuous replication](), and [cutover strategy]().
+When do you need to complete the migration? How many team members can be allocated for this effort? How much complex orchestration can your team manage? These factors may influence your choices for [migration granularity]({% link molt/migration-considerations-phases.md %}), [continuous replication]({% link molt/migration-considerations-replication.md %}), and [cutover strategy]({% link molt/migration-considerations-cutover.md %}).
 
-- Migrations with a short timeline, or which cannot accommodate high complexity, may want to migrate data [all at once](), without utilizing [continuous replication](), and requiring [manual reconciliation]() in the event of migration failure.
+- Migrations with a short timeline, or which cannot accommodate high complexity, may want to migrate data [all at once]({% link molt/migration-considerations-phases.md %}), without utilizing [continuous replication]({% link molt/migration-considerations-replication.md %}), and requiring [manual reconciliation]({% link molt/migration-considerations-rollback.md %}) in the event of migration failure.
 
-- Migrations with a long timeline, or which can accomodate complexity, may want to migrate data [in phases](). If the migration requires minimal downtime, these migrations may also want to utilize [continuous replication](). If the migration is low in risk-tolerance, these migrations may also want to enable [failback]().
+- Migrations with a long timeline, or which can accomodate complexity, may want to migrate data [in phases]({% link molt/migration-considerations-phases.md %}). If the migration requires minimal downtime, these migrations may also want to utilize [continuous replication]({% link molt/migration-considerations-replication.md %}). If the migration is low in risk-tolerance, these migrations may also want to enable [failback]({% link molt/migration-considerations-rollback.md %}).
 
 ### Risk tolerance
 
-How much risk is your organization willing to accept during the migration? This may influence your choices for [migration granularity](), [validation strategy](), and [rollback plan]().
+How much risk is your organization willing to accept during the migration? This may influence your choices for [migration granularity]({% link molt/migration-considerations-phases.md %}), [validation strategy]({% link molt/migration-considerations-validation.md %}), and [rollback plan]({% link molt/migration-considerations-rollback.md %}).
 
-- Risk-averse migrations should prefer [phased migrations]() that limit the blast radius of any issues. Start with low-risk slices (e.g., a small cohort of tenants or a non-critical service), [validate thoroughly](), and progressively expand to higher-value workloads. These migrations may also prefer [rollback plans]() that enable quick recovery in the event of migration issues.
+- Risk-averse migrations should prefer [phased migrations]({% link molt/migration-considerations-phases.md %}) that limit the blast radius of any issues. Start with low-risk slices (e.g., a small cohort of tenants or a non-critical service), [validate thoroughly]({% link molt/migration-considerations-validation.md %}), and progressively expand to higher-value workloads. These migrations may also prefer [rollback plans]({% link molt/migration-considerations-rollback.md %}) that enable quick recovery in the event of migration issues.
 
-- For risk-tolerant migrations, it may be acceptable to migrate [all of your data at once](). Less stringent [validation strategies]() and [manual reconciliation]() in the event of a migration failure may also be acceptable.
+- For risk-tolerant migrations, it may be acceptable to migrate [all of your data at once]({% link molt/migration-considerations-phases.md %}). Less stringent [validation strategies]({% link molt/migration-considerations-validation.md %}) and [manual reconciliation]({% link molt/migration-considerations-rollback.md %}) in the event of a migration failure may also be acceptable.
 
 ___
 
-These above factors are only a subset of all of what you'll want to consider in the decision-making about your CockroachDB migration, along with your specific business requirements and technical constraints. It's recommended that you document these decisions and the reasoning behind them as part of your [migration plan]().
+These above factors are only a subset of all of what you'll want to consider in the decision-making about your CockroachDB migration, along with your specific business requirements and technical constraints. It's recommended that you document these decisions and the reasoning behind them as part of your [migration plan]({% link molt/migration-strategy.md %}#develop-a-migration-plan).
 
 ## See also
 

src/current/molt/migration-overview.md

@@ -13,7 +13,6 @@ This page provides an overview of the following:
 
 - Overall [migration sequence](#migration-sequence)
 - [MOLT tools](#molt-tools)
-- Supported [migration flows](#migration-flows)
 
 ## Migration sequence
 
@@ -48,8 +47,6 @@ The MOLT (Migrate Off Legacy Technology) toolkit enables safe, minimal-downtime
 <img src="{{ 'images/molt/molt_flows_1.svg' | relative_url }}" alt="MOLT tooling overview" style="max-width:100%" />
 </div>
 
-For more details, refer to [Migration flows](#migration-flows).
-
 ## MOLT tools
 
 [MOLT (Migrate Off Legacy Technology)]({% link releases/molt.md %}) is a set of tools for schema conversion, data load, replication, and validation. Migrations with MOLT are resilient, restartable, and scalable to large data sets.
@@ -103,7 +100,7 @@ The [MOLT Schema Conversion Tool]({% link cockroachcloud/migrations-page.md %})
 
 [MOLT Fetch]({% link molt/molt-fetch.md %}) performs the initial data load to CockroachDB. It supports:
 
-- [Multiple migration flows](#migration-flows) via `IMPORT INTO` or `COPY FROM`.
+- Multiple migration flows via `IMPORT INTO` or `COPY FROM`.
 - Data movement via [cloud storage, local file servers, or direct copy]({% link molt/molt-fetch.md %}#data-path).
 - [Concurrent data export]({% link molt/molt-fetch.md %}#best-practices) from multiple source tables and shards.
 - [Schema transformation rules]({% link molt/molt-fetch.md %}#transformations).