IBM Db2 LUW CDC: change data capture and real-time data replication

• Db2 DBAs who must approve it: the log-based agent needs libdb2.so on the Db2 server host and a reader account with DBADM, and the setup guide lists each privilege, file, and restart step before anything goes live
• Data platform leads feeding Snowflake, BigQuery, data lakes, Kafka, MongoDB, or Couchbase from Db2 systems of record, who want one control plane for sources and targets instead of a Kafka Connect mesh
• Teams comparing IBM InfoSphere Data Replication, Qlik Replicate, Fivetran HVR, or AWS DMS renewals who need a commercial Db2 path with a choice of capture technique and best-in-class enterprise support from MOLO17, rated 4.9/5 by customers
• Engineers who prototyped the Debezium Db2 connector or a log-reading script and now own the connector, the Kafka Connect cluster, and on-call for a pipeline the business treats as infrastructure

Transaction log on 11.5.8.0 and later, triggers on 11.5 and later

Two capture techniques cover Db2 for LUW. The log-based agent reads the transaction log through Db2's log reader API. The triggers agent records changes with triggers on the source tables.

• Log-based CDC agent: a stored procedure, GS_SP_LOGMINER, polls at a configurable interval. It calls a native library, libdb2.so, that uses Db2's db2ReadLog API, and writes what it reads to CDC tables in a dedicated Gluesync schema, one per source table, with the operation type (I, U, or D) and a transaction ID. CDC agent docs ↗
• Triggers agent: triggers on INSERT, UPDATE, and DELETE record each changed row identifier and action type in a CDC table in a dedicated Gluesync schema, which the agent then reads. The table name is configurable. This path does not require complex transaction log configuration. Triggers agent docs ↗

What your DBA sets up for the log-based agent

These steps come from the setup guide. Each one is a fact your DBA can check before approving the agent.

• Triggers agent: a dedicated user that can read the source tables and create triggers on them.

1. Confirm Db2 for LUW is 11.5.8.0 or later, including 12.1 and later. Earlier 11.5 releases use the triggers agent instead.
2. Copy libdb2.so to the Db2 server host, by default to /function/libdb2.so with mode 755. The file must sit on the database server, not on the Gluesync host.
3. Create a Gluesync user with CONNECT on the database and the SELECTIN, INSERTIN, UPDATEIN, DELETEIN, and EXECUTEIN schema privileges on the schema that holds Gluesync's CDC tables and on each application schema.
4. Create a reader account with DBADM on the database. db2ReadLog requires DBADM or SYSADM.
5. Store the reader's DBNAME, DB_HOST, DB_PORT, DB_USER, and DB_PASSWORD in a file readable only by the instance owner, list those variables in DB2ENVLIST, and restart the instance. The restart stops the database, so plan a maintenance window.

Editions, connectivity, and topology

• Editions: the log-based agent covers single-instance and partitioned database environments, including Community Edition. The triggers agent covers any release from 11.5 onward, Community Edition included.
• Connectivity: both agents use the bundled JDBC driver, type 4 over TCP/IP, on port 50000 by default.
• Character encoding: UTF-8 by default, changeable per connection for databases that use another encoding.
• Snapshots: both agents support full snapshot loads before CDC starts, so the target is seeded before changes stream.

Checkpoints, errors, and large transactions

• Checkpoints: the log-based agent resets its checkpoint on first start if requested, advances it as transactions are processed, and purges processed change data after a configurable retention period.
• Errors: stored procedure errors are reported as notifications, and the polling loop continues after a failed invocation.
• Large transactions: the log reader buffers the row events of each source transaction and spills large transactions to staging tables.

Architecture around Core Hub

Lightweight agents sit close to each system. Core Hub hosts the web UI and REST APIs and routes changes between source and target agents; a pipeline groups the Db2 source agent, its target agents, and the entities they replicate. Both Db2 LUW agents support full snapshots before CDC and the source and target role. Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes.

Explore the general CDC streaming architecture →

Use the integrations directory to pair Db2 for LUW as a source with relational engines, NoSQL stores, cloud warehouses, object and lake storage, or event streams, subject to each agent's documented source and target role. Both Db2 LUW agents also support the target role over JDBC, with snapshot loads, on Db2 for LUW 11.5 and later.

Gluesync keeps pace with your change volume at any scale. MOLO17 Professional Services can size the deployment with your team.

Target agents write in optimized batches, never row by row, and switch to native bulk load for both snapshots and CDC on targets such as Snowflake, Google BigQuery, Amazon Redshift, Microsoft SQL Server, and PostgreSQL.

• Offload reads from Db2 to PostgreSQL, SQL Server, or a NoSQL store: see database offload
• Feed Snowflake, BigQuery, or a data lake continuously: see warehouse sync
• Publish Db2 changes to Apache Kafka, Google Pub/Sub, or Solace PubSub+ for event-driven services
• Keep Db2 and a cloud target aligned through snapshot plus CDC until cutover: see cloud migration