The default Debezium Oracle images are pre-configured with archive log mode
enabled and this isn't something we can simply turn off and back on in the
test suite proper. This test must be invoked manually and separately, so it
is disabled by default in the overall test suite execution.
This avoids a scenario where we want to increment the batch size; however, the
current batch size is equal to the max and therefore triggers a decrement and
the next iteration increments. The new behavior will be that we don't trigger
this ping pong. With this change, we can track specifically when we reach the
max batch size and only log the warning once. If the batch size drops, and it
later increments, the warning will be logged again but this should be expected.
Using current batch size for comparison is wrong in case that when currentScn is topScn as described in DBZ-6155.
In the other case (when topScn is behind currentScn) can eventually lead to this situation.
when topScn would fall behind currentScn more and more as we would compare currentScn - topScn with bigger and bigger number (current batch size).
Comapring with logMiningBatchSizeMin could result in very small window which would mean we will send many small queries instead of several bigger ones during mining.
Therefore reverting back to do the adjustments based on the defaultBatchSize.
The "fetch-state" attribute was deprecated and is no longer a valid option
with Infinispan 14, which causes the tests to fail to execute. Additionally,
the "segmented" attribute must be set to true going forward as the file
store implementation no longer supports non-segmented configurations.
We load all the schemas of the captured tables when the connector
starts. If we process a record from a table which schema is not
available, this means we have some bug in the intial schema loading.
Don't fail in such case, but print a warning about that.
When taking a snapshot, the Oracle connector was converting the TIMESTAMP
WITH TIME ZONE value to GMT and per the documentation, the value should
be emitted in the time zone of the data.
The snapshot emitted value in GMT is temporally accurate, so there is no
data inconsistency, but the emitted format itself was inconsistent when
looking at how the column data was emitted during a snapshot versus in a
streaming event.
DBZ-5648 introduced a regression where transaction start, commit, and rollback
events were only being read from within the scope of the configured PDB that
the connector was capturing changes instead of the entire Oracle database.
This can lead to situations where the offsets may not be advanced as quickly
in a low traffic PDB environment, potentially causing stale offsets.
