How the change selector works - Connect_CDC - aws_mainframe_modernization_service - connect_cdc_mimix_share - 6.x

Connect CDC Getting Started Guide

Product type
Software
Portfolio
Integrate
Product family
Connect
Product
Connect > Connect CDC (MIMIX Share)
Version
6.x
Language
English
Product name
Connect CDC
Title
Connect CDC Getting Started Guide
Copyright
2024
First publish date
2003
Last updated
2024-10-15
Published on
2024-10-15T20:38:41.117981

The Change Selector process is created when journaled tables are distributed and journal operations are successfully completed. The Change Selector name is the journal name and each journal has at least one Change Selector.

When you commit the model in Connect CDC Director and the tables have capture enabled, when you start the kernel the Change Selector will start automatically.

Note: This is the default behavior. To not automatically start the Change Selector, place an empty file named CSSwitchFile.txt in the Connect CDC kernel directory of the source host.

The kernel also checks the status and starts the Change Selector on receiving a command to enable capture or to start a request (you can do this from Connect CDC MonCon).

When Enable Capture is turned on, the Change Selector:

  • is informed which rows have changed and need to be captured from the transaction logs or journals of the source tables.

  • copies the changed data to the metabase for intermediate storage during replication.

  • removes data that are no longer needed.

  • updates shadow tables.

To ensure minimal impact on a sending server’s performance, the Change Selector only captures changed records and leaves further processing of replica data to other processes.

The Change Selector is DBMS-specific and is capable of establishing and exchanging control information only with its native DBMS.

The Change Selector is log-based, examining system journals or logs to identify changes, and moving the data to be sent into the replication queue. On other DBMS servers, the change data capture mechanism consists of a number of triggers and procedures written when you enable change capture.

Note: For self-committing transactions, the Change Selector reads the log and groups them into groups with a maximum of 100-row pseudo transactions.

When updates occur while the Change Selector is active (real-time), another criterion determines when to commit a pseudo transaction. A timer ensures that a pseudo transaction is not open too long. This prevents having nothing but self-committing operations in a system with low activity, which could leave a transaction open for a long period of time.

A Change Selector is required for any source server that captures replica data. A server that simply transmits data does not need a Change Selector.

For IBM i, multiple Change Selectors can exist within a replication system, each having a unique process number and configuration and log file with that number.

The kernel does not automatically shut down any Change Selector, so you are still responsible for shutting them down through a monitoring and control tool, when necessary. See Stop the change selector.