Test and validate
To verify that your connections and configuration work properly, run MOLT Replicator in a staging environment before replicating any data in production. Use a test or development environment that closely resembles production.Optimize performance
Configure the following to optimize replication throughput and resource usage. Test different combinations in a pre-production environment to find the optimal balance of stability and performance for your workload.The following parameters apply to PostgreSQL, Oracle, and CockroachDB (failback) sources.
Docker performance
MOLT Replicator is 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.Security
Cockroach Labs strongly recommends the following:Connection security and credentials
-
To keep your database credentials out of shell history and logs, follow these best practices when specifying your source and target connection strings:
- Avoid plaintext connection strings.
-
Provide your connection strings as environment variables. For example:
Afterward, reference the environment variables in MOLT commands:
- If possible, use an external secrets manager to load the environment variables from stored secrets.
-
Use TLS-enabled connection strings to encrypt data in transit from MOLT to the database. When using TLS certificates, ensure certificate files are accessible to the MOLT binary on the same machine.
For example, a PostgreSQL connection string with TLS certificates:
-
URL-encode connection strings for the source database and so special characters in passwords are handled correctly.
-
Given a password
a$52&, pass it to themolt escape-passwordcommand with single quotes:Use the encoded password in your connection string. For example:
-
Given a password
-
Remove
sslmode=disablefrom production connection strings.
CockroachDB changefeed security
For failback scenarios, secure the connection from CockroachDB to MOLT Replicator using TLS certificates. Generate TLS certificates using self-signed certificates, certificate authorities like Let’s Encrypt, or your organization’s certificate management system.TLS from CockroachDB to Replicator
Configure MOLT Replicator with server certificates using the and flags to specify the certificate and private key file paths. For example:- Webhook URLs: Use both URL encoding and base64 encoding:
base64 -i ./client.crt | jq -R -r '@uri' - Non-webhook contexts: Use base64 encoding only:
base64 -w 0 ca.cert
JWT authentication
You can use JSON Web Tokens (JWT) to authorize incoming changefeed connections and restrict writes to a subset of SQL databases or user-defined schemas in the target cluster. Replicator accepts any JWT token that meets the following requirements:- Tokens must be signed using RSA or EC keys. HMAC and
Nonesignatures are automatically rejected. - Tokens must include a
jti(JWT ID) claim for revocation support. - Tokens must include a custom claim with the schema authorization list.
-
Add PEM-formatted public signing keys to the
_replicator.jwt_public_keystable in the staging database. -
To revoke a specific token, add its
jtivalue to the_replicator.jwt_revoked_idstable in the staging database.
Generate JWT tokens
Themake-jwt command generates JWT tokens or claims for authorizing changefeed connections. It requires a signing key () and the database or schema to authorize (). You can output a signed token to a file () or generate an unsigned claim () for signing with an external JWT provider.
The format of the -a argument depends on your target database. For CockroachDB and PostgreSQL, which have a schema concept, use the database.schema format:
Token quickstart
The following example usesOpenSSL to generate keys, but any PEM-encoded RSA or EC keys will work. When using this example, ensure the -a argument format matches your target database as specified in Generate JWT tokens.
External JWT providers
To use an external JWT provider, generate a claim with the--claim flag. The PEM-formatted public key or keys for that provider must be inserted into the _replicator.jwt_public_keys table. The iss (issuers) and jti (token id) fields will likely be specific to your auth provider, but the custom claim must be retained in its entirety:
Production considerations
- Avoid and flags in production environments. These flags should only be used for testing or development purposes.
Supply chain security
Use theversion command to verify the integrity of your MOLT Replicator build and identify potential upstream vulnerabilities.
- Module name
- go.mod checksum
- Version

