Bug report

For bug reports, provide this information, please:

What Debezium connector do you use and what version?

I am using Debezium Informix Source connector, and the version is 2.6.0.

What is the connector configuration?

{     "connector.class": "io.debezium.connector.informix.InformixConnector",     "errors.log.include.messages": "true",     "topic.creation.default.partitions": "1",     "value.converter.schema.registry.subject.name.strategy": "io.confluent.kafka.serializers.subject.TopicNameStrategy",     "tasks.max": "1",     "key.converter.schema.registry.subject.name.strategy": "io.confluent.kafka.serializers.subject.TopicNameStrategy",     "transforms": "unwrap,TSF1",     "transforms.TSF1.static.field": "instance_id",     "errors.deadletterqueue.context.headers.enable": "true",     "database.connection.retry.interval.ms": "1000",     "schema.history.internal.store.only.captured.tables.ddl": "true",     "schema.history.internal.store.only.captured.databases.ddl": "true",     "transforms.TSF1.type": "org.apache.kafka.connect.transforms.InsertField$Value",     "tombstones.on.delete": "true",     "topic.prefix": "mcp_kafka_net_21",     "decimal.handling.mode": "double",     "schema.history.internal.kafka.topic": "informixschemahistory",     "transforms.unwrap.drop.tombstones": "false",     "topic.creation.default.replication.factor": "1",     "errors.deadletterqueue.topic.replication.factor": "1",     "transforms.unwrap.type": "io.debezium.transforms.ExtractNewRecordState",     "value.converter": "io.confluent.connect.avro.AvroConverter",     "errors.log.enable": "true",     "key.converter": "io.confluent.connect.avro.AvroConverter",     "database.user": "kafka",     "database.dbname": "cards_1952",     "topic.creation.default.compression.type": "lz4",     "topic.creation.default.cleanup.policy": "compact",     "time.precision.mode": "connect",     "database.server.name": "mcp_kafka_net_21",     "snapshot.isolation.mode": "read_committed",     "schema.history.internal.kafka.bootstrap.servers": "192.168.151.201:9092,192.168.151.202:9092,192.168.151.203:9092",     "database.port": "9260",     "value.converter.schema.registry.url": "http://192.168.151.201:8081",     "transforms.TSF1.static.value": "150",     "errors.max.retries": "10",     "database.hostname": "192.168.151.101",     "errors.deadletterqueue.topic.name": "informix-gpdb-source-errors",     "database.connection.retries": "5",     "database.password": "*******",     "name": "n_source",     "errors.tolerance": "all",     "table.include.list": "cards_1952.mcp.trans_requests_reps",     "pk.mode": "primary_key",     "key.converter.schema.registry.url": "http://192.168.151.201:8081",     "snapshot.mode": "schema_only" }

What is the captured database version and mode of deployment?

I am using the below versions of Informix and I am using the KAFKA Connect UI for Debezium connector deployment.

Informix Dynamic Server
14.10.FC10W1X2
Informix JDBC Driver for Informix Dynamic Server
4.50.JC10

KAFKA Version: 7.4.1-ce

What behaviour do you expect?

Scenario:

Due to some limitations, structural changes on tables with extremely large data volume are hard to be done. Thus, the DBA creates a replica of the table (that includes the structural change) with a new name and put a lock on both the original and new table and dumps the old data in this table and rename the table once the old data has been dumped. 

 

Expected Behavior: 

A new table "trans_requests_new" is created in the Informix database which is a replica of "trans_requests". Change data capturing was already enabled by Debezium informix source connector on trans_requests and in order to rename this table, KAFKA Connect is stopped and the function cdc_set_fullrowlogging is executed to disable CDC on trans_requests. The table trans_requests is renamed to trans_requests_old. The old data existing in trans_requests_old is now dumped into the new table "trans_requests_new". After the old data has been dumped, trans_requests_new is renamed to trans_requests and new data is inserted in this table. KAFKA Connect is started and the Debezium connectors are back online which enables the CDC on the newly renamed table trans_requests. The Informix Connector should only capture the new data inserted when the table name was "trans_requests" inserted during KAFKA downtime and should continue to only capture events that is being executed on trans_requests only after KAFKA was restarted. 

What behaviour do you see? ** 

A new table "trans_requests_new" is created in the Informix database which is a replica of "trans_requests". Change data capturing was already enabled by Debezium informix source connector on trans_requests and in order to rename this table, KAFKA Connect is stopped and the function cdc_set_fullrowlogging is executed to disable CDC on trans_requests. The table trans_requests is renamed to trans_requests_old. The old data existing in trans_requests_old is now dumped into the new table "trans_requests_new". After the old data has been dumped, trans_requests_new is renamed to trans_requests and new data is inserted in this table. KAFKA Connect is started and the Debezium connectors are back online which enables the CDC on the newly renamed table trans_requests. However, it has been observed that the Informix source connector is capturing events generated in the logical logs by both the old data that was dumped when the table name was trans_requests_new and the new data inserted when the table name was trans_requests. Thus, KAFKA is publishing messages in the same existing topic made specifically for trans_requests for both the old data which is not desirable and new data which is required and expected.

Do you have the connector logs, ideally from start till finish?

The complete KAFKA Connect logs has been attached.