MOLT Replicator Troubleshooting

This page describes common issues that can occur while using and suggests ways to troubleshoot those issues.

Some of the contents of this page are specific to your source database (PostgreSQL, MySQL, or Oracle). Select your source using the dropdown at the top right of this page.

Forward replication issues

Performance troubleshooting

If MOLT Replicator appears hung or performs poorly:

1. Enable trace logging with -vv to get more visibility into the replicator’s state and behavior.

2. If MOLT Replicator is in an unknown, hung, or erroneous state, collect performance profiles to include with support tickets. Replace {host} and {metrics-port} with your Replicator host and the port specified by :

   curl '{host}:{metrics-port}/debug/pprof/trace?seconds=15' > trace.out
   curl '{host}:{metrics-port}/debug/pprof/profile?seconds=15' > profile.out
   curl '{host}:{metrics-port}/debug/pprof/goroutine?seconds=15' > gr.out
   curl '{host}:{metrics-port}/debug/pprof/heap?seconds=15' > heap.out
   

3. Monitor lag metrics and adjust performance parameters as needed.

For details on configuring the webhook sink URI, refer to .

GC threshold error

batch timestamp * must be after replica GC threshold

This indicates starting from an invalid cursor that has been garbage collected.

Resolution: Double-check the cursor to ensure it represents a valid range that has not been garbage collected, or extend the GC TTL on the source CockroachDB cluster:

ALTER DATABASE defaultdb CONFIGURE ZONE USING gc.ttlseconds = {gc_ttl_in_seconds};

Duplicated data re-application

This occurs when resuming a changefeed from a cursor causes excessive data duplication.

Resolution: Clear the staging database to prevent duplication. This deletes all checkpoints and buffered data, so use with caution:

DROP DATABASE _replicator;

For more targeted cleanup, delete mutations from specific staging tables:

DELETE FROM _replicator.employees WHERE true;

See also