Frequently Asked Questions
This document answers some frequently asked questions about the MSR (Multi-Session Replay) module.
Change Data Capture Issues
My database changes are not being captured by Debezium. What's wrong?
The most common cause is forgetting to set REPLICA IDENTITY FULL
on your database tables. Without this setting,
PostgreSQL doesn't provide enough information for Debezium to capture all changes.
Solution:
ALTER TABLE <schema>.<table_name> REPLICA IDENTITY FULL;
Examples:
ALTER TABLE gis.geo_entity REPLICA IDENTITY FULL;
ALTER TABLE gis.bookmark REPLICA IDENTITY FULL;
I see "slot does not exist" errors in Kafka Connect logs
This usually means the replication slot name is already in use or wasn't created properly. Each source connector needs a
unique slot.name
across the entire Kafka Connect cluster.
Solution:
- Ensure
slot.name
is unique for each connector - Check PostgreSQL for existing slots:
SELECT * FROM pg_replication_slots;
- Drop unused slots if necessary:
SELECT pg_drop_replication_slot('slot_name');
No data is appearing in the MSR CDC events table
This could be due to several issues:
- Source connector not running: Check Kafka Connect status at
http://localhost:8083/connectors
- Sink connector misconfigured: Verify the sink connector is consuming from the correct topics
- Transform errors: Check Kafka Connect logs for JSLT transformation errors
- Topic permissions: Ensure Kafka Connect has permission to read/write topics
I'm getting "permission denied" errors when setting up connectors
Verify that:
- Database user has replication permissions:
ALTER USER admin REPLICATION;
- Database user can access the required tables
- Kafka Connect can reach both source and target databases
Performance Issues
CDC processing is slow or lagging behind
Consider these optimizations:
- Increase
batch.size
in sink connector configuration - Adjust
snapshot.fetch.size
for source connectors - Monitor database
work_mem
settings:SET work_mem = '256MB';
- Check network latency between components
High memory usage in Kafka Connect containers
This is often caused by:
- Large batch sizes processing too much data at once
- JSLT transformations on very large JSON payloads
- Insufficient memory allocation to Kafka Connect JVM
Solution: Tune JVM heap size and connector batch configurations.
Configuration Issues
My JSLT transformation is failing with parsing errors
Common JSLT issues include:
- Incorrect JSON escaping in connector configuration
- Missing fields in the source data structure
- Type mismatches between expected and actual data types
Debug by:
- Testing JSLT expressions separately
- Checking source data structure in Kafka topics
- Validating JSON syntax in connector configuration
Connector keeps restarting or failing
Check these common causes:
- Database connection timeouts
- Insufficient database connection limits
- Missing required permissions
- Network connectivity issues between services
Development and Debugging
How do add logs to the MSR Web Worker
The MSR Web Worker uses a custom logging system that sends all log messages to the main browser thread for proper
console output. The worker includes a workerLog
object with different log levels:
// Available log levels in the Web Worker
workerLog.debug("Debug message", { additionalData });
workerLog.info("Info message", { sessionData });
workerLog.warn("Warning message", { errorDetails });
workerLog.error("Error message", { errorContext });
To see Web Worker logs in your browser console:
- Open browser Developer Tools (F12)
- Go to the Console tab
- Worker logs will appear with
[MSR Worker]
prefix - Use console filtering to show only MSR logs:
[MSR Worker]
Common log messages to look for:
"Session created successfully"
- Confirms session initialization"Loaded entities into worker state"
- Shows initial data loading"Starting data polling"
- Indicates background polling started"Buffering changes"
- Shows CDC data being processed"Buffer size limit reached"
- Warning about memory usage