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

Allow reading from Oracle read-write Logical standby when guard_status is STANDBY using log Miner from oracle db to kafka

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not a Bug
    • Icon: Major Major
    • None
    • 2.5.4.GA
    • oracle-connector
    • True
    • Hide
      As logical stand by feature is not working for kafka if dataguard is standby.

      customer env missing deadline to promote production
      Show
      As logical stand by feature is not working for kafka if dataguard is standby. customer env missing deadline to promote production
    • False
    • High
    • Hide

      Conector steps:
      1. Start Zookeeper and the Kafka server.
      2. Start Kafka Connect using the distributed properties file with the required plugin and connector configuration.
      3. Load the connector configuration into Kafka Connect via the REST API.
      4. Download and configure the necessary JAR files to ensure a successful connection to the database.
      5. Verify that the connector is running successfully.
      6. If the connector is in the RUNNING state, check the Connect worker logs to confirm the successful

      6. If the connector is in the RUNNING state, check the Connect worker logs to confirm the successful ingestion of data from Oracle to Kafka.
      7. Once the connector is successfully started and running, it will create topics and stream live data changes to these Kafka topics.

      Database Steps:
      Connect to logical stand by database

      --Display the database status
      select name, database_role,open_mode from v$database;

      NAME DATABASE_ROLE OPEN_MODE
      --------- ---------------- --------
      LOGSTBY LOGICAL STANDBY READ WRITE Display the guard

      --Display the database guard_status
      select guard_status from v$database;
      GUARD_S
      -------
      STANDBY

      setting the guard on a database

      alter database guard standby;
      or
      alter database guard none;

      A database guard can have three possible values
      • NONE - users are free to modify any schema or table (the primary database will be in this mode)
      • STANDBY - users cannot modify any replicated schemas or tables, but they are free to create
      there own schemas, tables or views
      • ALL - this is the most restrictive no modifications are allowed

      Note: When guard_status set to NONE streaming works with or without setting "internal.log.mining.read.only=true"

      Show
      Conector steps: 1. Start Zookeeper and the Kafka server. 2. Start Kafka Connect using the distributed properties file with the required plugin and connector configuration. 3. Load the connector configuration into Kafka Connect via the REST API. 4. Download and configure the necessary JAR files to ensure a successful connection to the database. 5. Verify that the connector is running successfully. 6. If the connector is in the RUNNING state, check the Connect worker logs to confirm the successful 6. If the connector is in the RUNNING state, check the Connect worker logs to confirm the successful ingestion of data from Oracle to Kafka. 7. Once the connector is successfully started and running, it will create topics and stream live data changes to these Kafka topics. Database Steps: Connect to logical stand by database --Display the database status select name, database_role,open_mode from v$database; NAME DATABASE_ROLE OPEN_MODE --------- ---------------- -------- LOGSTBY LOGICAL STANDBY READ WRITE Display the guard --Display the database guard_status select guard_status from v$database; GUARD_S ------- STANDBY setting the guard on a database alter database guard standby; or alter database guard none; A database guard can have three possible values • NONE - users are free to modify any schema or table (the primary database will be in this mode) • STANDBY - users cannot modify any replicated schemas or tables, but they are free to create there own schemas, tables or views • ALL - this is the most restrictive no modifications are allowed Note: When guard_status set to NONE streaming works with or without setting "internal.log.mining.read.only=true"
    • Critical

      For bug reports, provide this information, please:

      What Debezium connector do you use and what version?

      Debezium 2.5.4

      What is the connector configuration?

      curl -i -X POST -H "Accept:application/json" -H "Content-Type:application/json" \
      http://localhost:8083/connectors/ -d '{
      "name": "debezium-ora-001",
      "config":

      { "connector.class": "io.debezium.connector.oracle.OracleConnector", "tasks.max": "1", "topic.prefix": "server1", "database.server.name": "ip-10-0-23-62", "database.tablename.case.insensitive":"true", "database.hostname": "3.93.192.48", "database.port": "1623", "database.user": "dbzuser", "database.password": "SysPassword1", "database.dbname": "logstby", "schema.include.list": "LOCAL", "table.include.list": "LOCAL.CUSTOMER_ORDER,LOCAL.CUSTOMER_ORDER_ITEM,LOCAL.REGIONS", "schema.history.internal.kafka.bootstrap.servers": "localhost:9092", "schema.history.internal.kafka.topic": "debezium.oracle", "database.connection.adapter": "logminer", "internal.log.mining.read.only": "true" }

      }'

      What is the captured database version and mode of deployment?

      On-premises Oracle EE 19.0.0.0

      What behavior do you expect?

      it should work for STANDBY

      What behavior do you see?

      Connector Error during snapshot in step 3
      [2024-05-23 16:26:45,532] INFO [debezium-ora-001|task-0] Snapshot step 3 - Locking captured tables [LOGSTBY.LOCAL.CUSTOMER_ORDER, LOGSTBY.LOCAL.CUSTOMER_ORDER_ITEM, LOGSTBY.LOCAL.REGIONS] (io.debezium.relational.RelationalSnapshotChangeEventSource:139)
      [2024-05-23 16:26:46,690] ERROR [debezium-ora-001|task-0] Error during snapshot (io.debezium.relational.RelationalSnapshotChangeEventSource:179)
      java.sql.SQLException: ORA-1622
      java.sql.SQLException: ORA-16224: Database Guard is enabled

      select guard_status from v$database;

      GUARD_S
      -------
      STANDBY

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

      Yes

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

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

      yes

      How to reproduce the issue using our tutorial deployment?

      Feature request or enhancement

      BUG

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

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

      With the LogMiner with read/write access with gaurd status set as "STANDBY" it is NOT working with Debezium 2.5.4

        1. connector_config
          2 kB
        2. kafka_2.5.4_debezium.log
          165 kB
        3. kafka_2.5.4_debezium_debug.log
          6.66 MB

              Unassigned Unassigned
              rhn-support-kkakarla kodandaRamu kakarla
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: