Migration Failback

On this page

If issues arise during the migration, you can start MOLT Fetch in failback mode after stopping replication and before sending new writes to CockroachDB. Failing back to the source database ensures that data remains consistent on the source, in case you need to roll back the migration.

Before you begin

Enable rangefeeds in the CockroachDB SQL shell:

SET CLUSTER SETTING kv.rangefeed.enabled = true;

Select the source dialect you migrated to CockroachDB:

Step 1. Stop replication to CockroachDB

Cancel replication to CockroachDB by entering ctrl-c to issue a SIGTERM signal to the fetch process. This returns an exit code 0.

Step 2. Fail back from CockroachDB

The following example watches the employees table for change events.

1. Issue the MOLT Fetch command to fail back to the source database, specifying --mode failback. For details on this mode, refer to the MOLT Fetch page.

   Tip:

   Be mindful when specifying the connection strings: --source is the CockroachDB connection string and --target is the connection string of the database you migrated from.

   Use the --stagingSchema replication flag to provide the name of the staging schema. This is found in the staging database name message that is written at the beginning of the replication task.

   molt fetch \
   --source 'postgres://root@localhost:26257/defaultdb?sslmode=verify-full' \
   --target 'postgres://postgres:postgres@localhost:5432/molt?sslmode=verify-full' \
   --table-filter 'employees' \
   --non-interactive \
   --replicator-flags "--stagingSchema _replicator_1739996035106984000" \
   --mode failback \
   --changefeeds-path 'changefeed-secure.json'
   

   molt fetch \
   --source 'postgres://root@localhost:26257/defaultdb?sslmode=verify-full' \
   --target 'mysql://user:password@localhost/molt?sslcert=.%2fsource_certs%2fclient.root.crt&sslkey=.%2fsource_certs%2fclient.root.key&sslmode=verify-full&sslrootcert=.%2fsource_certs%2fca.crt' \
   --table-filter 'employees' \
   --non-interactive \
   --replicator-flags "--stagingSchema _replicator_1739996035106984000" \
   --mode failback \
   --changefeeds-path 'changefeed-secure.json'
   

   --changefeeds-path specifies a path to changefeed-secure.json, which should contain the following setting override:

   {
       "sink_query_parameters": "client_cert={base64 cert}&client_key={base64 key}&ca_cert={base64 CA cert}"
   }
   

   client_cert, client_key, and ca_cert are webhook sink parameters that must be base64- and URL-encoded (for example, use the command base64 -i ./client.crt | jq -R -r '@uri').

   Tip:

   For details on the default changefeed settings and how to override them, refer to Changefeed override settings.

2. Check the output to observe fetch progress.

   A starting replicator message indicates that the task has started:

   {"level":"info","time":"2025-02-20T15:55:44-05:00","message":"starting replicator"}
   

   The staging database name message contains the name of the staging schema:

    {"level":"info","time":"2025-02-11T14:56:20-05:00","message":"staging database name: _replicator_1739303283084207000"}
   

   A creating changefeed message indicates that a changefeed will be passing change events from CockroachDB to the failback target:

   {"level":"info","time":"2025-02-20T15:55:44-05:00","message":"creating changefeed on the source CRDB database"}
   

See also

• Migration Overview
• MOLT Schema Conversion Tool
• MOLT Fetch
• MOLT Verify
• Migration Overview
• Migrate to CockroachDB
• Migrate to CockroachDB in Phases

Was this helpful?