The first schema field is part of the event key. Overview of change event basic content Item If you do not specify a type value, the signal fails to stop the incremental snapshot. If this component of the data field is omitted, the signal stops the entire incremental snapshot that is in progress.Ī required component of the data field of a signal that specifies the kind of snapshot operation that is to be stopped.Ĭurrently, the only valid option is incremental. Descriptions of fields in a SQL command for sending a stop incremental snapshot signal to the signaling table ItemĪn optional component of the data field of a signal that specifies an array of table names or regular expressions to match table names to remove from the snapshot. The following table describes the parameters in the example: Table 6. If you do not specify a value, the connector runs an incremental snapshot.Īn optional string, which specifies a condition based on the column(s) of the table(s), to capture aįor more information about the additional-condition parameter, see Ad hoc incremental snapshots with additional-condition. The array lists regular expressions which match tables by their fully-qualified names, using the same format as you use to specify the name of the connector’s signaling table in the configuration property.Īn optional type component of the data field of a signal that specifies the kind of snapshot operation to run.Ĭurrently, the only valid option is the default value, incremental. Specifies type parameter specifies the operation that the signal is intended to trigger.Ī required component of the data field of a signal that specifies an array of table names or regular expressions to match table names to include in the snapshot. Rather, during the snapshot, Debezium generates its own id string as a watermarking signal. Use this string to identify logging messages to entries in the signaling table. The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Specifies the fully-qualified name of the signaling table on the source database. Descriptions of fields in a SQL command for sending an incremental snapshot signal to the signaling table Item The following table describes the parameters in the example: Table 5. If MySQL applies them individually, the connector creates a separate schema change event for each statement.Īn array of one or more items that contain the schema changes generated by a DDL command. If MySQL applies them atomically, the connector takes the DDL statements in order, groups them by database, and creates a schema change event for each group. Multiple DDL statements appear in the order in which they were applied to the database.Ĭlients can submit multiple DDL statements that apply to multiple databases.
The ddl field can contain multiple DDL statements.Įach statement applies to the database in the databaseName field. This field contains the DDL that is responsible for the schema change. The value of the databaseName field is used as the message key for the record. Identifies the database and the schema that contains the change.
Mysql database server name select update#
By comparing the value for _ms with the value for payload.ts_ms, you can determine the lag between the source database update and Debezium. In the source object, ts_ms indicates the time that the change was made in the database. The time is based on the system clock in the JVM running the Kafka Connect task. Optional field that displays the time at which the connector processed the event. This field is useful to correlate events on different topics. The source field is structured exactly as standard data change events that the connector writes to table-specific topics. Descriptions of fields in messages emitted to the schema change topic Item
"ddl": "ALTER TABLE customers ADD middle_name varchar(255) AFTER first_name", (4)
0 kommentar(er)
