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.
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.
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.