Uploaded image for project: 'Debezium'
  1. Debezium
  2. DBZ-5627

Handling two simultaneous incremental snapshot triggers.

    XMLWordPrintable

Details

    • False
    • None
    • False

    Description

      In order to make your issue reports as actionable as possible, please provide the following information, depending on the issue type.

      Bug report

      For bug reports, provide this information, please:

      When two queries for signalling incremental snapshot is executed, the connector goes dormant periodically but does not stop completely, rather it goes into a really slow mode and causes really heavy IO costs on the database.

      In the logs, it basically ignores the request to open window. The following messages shows up:

      ```Received request to open window with id = 'df6d8877-ebef-47ec-95a0-bdab58828955-open', expected = '87cea1ea-5ece-4a9b-9a2d-d1fac0dc1a31', request ignored```

      What Debezium connector do you use and what version?

      Postgres 1.8.1

      What is the connector configuration?

      ```

      {{

      {"connector.class": "io.debezium.connector.postgresql.PostgresConnector","value.converter.schemaAutoRegistrationEnabled": "true","slot.name": "debezium","tasks.max": "1","publication.name": "debezium_publication","key.converter.region": "****","value.converter.avroRecordType": "GENERIC_RECORD","heartbeat.action.query": "INSERT INTO public.debezium_heartbeat_table (text) VALUES ('heartbeat')","signal.data.collection": "public.debezium_signal_1","key.converter.avroRecordType": "GENERIC_RECORD","value.converter": "com.amazonaws.services.schemaregistry.kafkaconnect.AWSKafkaAvroConverter","key.converter": "com.amazonaws.services.schemaregistry.kafkaconnect.AWSKafkaAvroConverter","database.user": "user","database.dbname": "db","slot.drop.on.stop": "false","database.server.name": "om","value.converter.registry.name": "value-schema-registry","heartbeat.interval.ms": "1000","input.data.format": "AVRO","column.include.list": "public.sales_order_item.updated_at,public.sales_order_item.revision,public.sales_order_item.shipment_details,....,public.debezium_signal_1.id,public.debezium_signal_1.type,public.debezium_signal_1.data","value.converter.region": "****","key.converter.registry.name": "key-schema-registry","database.port": "*****","plugin.name": "pgoutput","key.converter.schemaAutoRegistrationEnabled": "true","database.hostname": "****","database.password": "****","name": "debezium-connector-01","table.include.list": "public.sales_order_item,public.debezium_signal_1","snapshot.mode": "never","incremental.snapshot.chunk.size": 25000}

      }}

      ```

      What is the captured database version and mode of depoyment?

      (E.g. on-premises, with a specific cloud provider, etc.)

      Aurora RDS 12.x

      What behaviour do you expect?

      If there are multiple snapshots triggered by mistake, it should keep other requests on hold/ignore until the first one is completed.

      What behaviour do you see?

      It does not completely stop. On one hand, it says, request ignored but somehow keeps snapshotting at a very low throughput rate. In my case, I was exporting a table of 74 million records and the throughput I was getting was ~85 events per second and also incurring really high io costs on aurora rds postgres.

      Do you see the same behaviour using the latest released Debezium version?

      (Ideally, also verify with latest Alpha/Beta/CR version)

      <Your answer>

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

      (You might be asked later to provide DEBUG/TRACE level log)

      Not from start to finish, but it basically goes into "flushing 0 outstanding messages for offset commit"

      I have enough to provide context.

      How to reproduce the issue using our tutorial deployment?

      Trigger snapshot twice with unique id and notice the behaviour.

      Feature request or enhancement

      For feature requests or enhancements, provide this information, please:

      Which use case/requirement will be addressed by the proposed feature?

      Gracefully handling multiple triggers through signal table.

      Implementation ideas (optional)

      Possibly ignore similar signals that cannot be executed together.

      For example, incremental snapshot for same table does not make sense to do it twice until one is completed.

      But maybe, there is other way of handling it better or let it fail!

      debezium connector logs.txt

      Attachments

        Activity

          People

            Unassigned Unassigned
            tkarmarkar Tanay Karmarkar (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: