update MOLT diagram; clean up MOLT docs

Author: taroface

src/current/images/molt/migration_flow.svg

@@ -38,10 +38,10 @@ These instructions assume you have already started replication at least once. To
 	</section>
 
 	<section class="filter-content" markdown="1" data-scope="mysql">
-	Replicator will automatically use the saved GTID (Global Transaction Identifier) from the `memo` table in the staging schema (in this example, `_replicator.memo`) and track advancing GTID checkpoints there. Do **not** specify `--defaultGTIDSet` when resuming.
+	Replicator will automatically use the saved GTID (Global Transaction Identifier) from the `memo` table in the staging schema (in this example, `_replicator.memo`) and track advancing GTID checkpoints there. To have Replicator start from a different GTID instead of resuming from the checkpoint, clear the `memo` table with `DELETE FROM _replicator.memo;` and run the `replicator` command with a new `--defaultGTIDSet` value.
 
 	{{site.data.alerts.callout_success}}
-	When resuming replication, the `--defaultGTIDSet` flag is optional and only used as a fallback if no saved GTID exists. To have Replicator start from a different GTID instead of resuming from the checkpoint, clear the `memo` table with `DELETE FROM _replicator.memo;` and run the `replicator` command with a new `--defaultGTIDSet` value.
+	For MySQL versions that do not support `binlog_row_metadata`, include `--fetchMetadata` to explicitly fetch column metadata. This requires additional permissions on the source MySQL database. Grant `SELECT` permissions with `GRANT SELECT ON source_database.* TO 'migration_user'@'localhost';`. If that is insufficient for your deployment, use `GRANT PROCESS ON *.* TO 'migration_user'@'localhost';`, though this is more permissive and allows seeing processes and server status.
 	{{site.data.alerts.end}}
 
 	{% include_cached copy-clipboard.html %}
@@ -55,10 +55,6 @@ These instructions assume you have already started replication at least once. To
 	--userscript table_filter.ts \
 	--verbose
 	~~~
-
-	{{site.data.alerts.callout_success}}
-	For MySQL versions that do not support `binlog_row_metadata`, include `--fetchMetadata` to explicitly fetch column metadata. This requires additional permissions on the source MySQL database. Grant `SELECT` permissions with `GRANT SELECT ON source_database.* TO 'migration_user'@'localhost';`. If that is insufficient for your deployment, use `GRANT PROCESS ON *.* TO 'migration_user'@'localhost';`, though this is more permissive and allows seeing processes and server status.
-	{{site.data.alerts.end}}
 	</section>
 
 	<section class="filter-content" markdown="1" data-scope="oracle">
@@ -83,12 +79,6 @@ These instructions assume you have already started replication at least once. To
 
 	Replication resumes from the last checkpoint without performing a fresh load. Monitor the metrics endpoint at `http://localhost:30005/_/varz` to track replication progress.
 
-<section class="filter-content" markdown="1" data-scope="postgres oracle">
-## Tuning parameters
-
-{% include molt/optimize-replicator-performance.md %}
-</section>
-
 ## Troubleshooting
 
 {% include molt/molt-troubleshooting-replication.md %}