MySQL treats the REAL data type as a synonym for DOUBLE PRECISION or DOUBLE in JDBC terms.

During the snapshot phase of the connector, if a table already exists with such a column, the connector resolves the column's data type and JDBC type from the JDBC metadata. The driver return shtis column as a "DOUBLE", mapping the final value as a FLOAT64 data type in the event's schema.

During the streaming phase, if the table existed during the snapshot where the Table in-memory model was prepared from the JDBC driver metadata, then the streaming phase will emit the value s ti was during the snapshot, which is correct.

However, the problem arises if the table is created after streaming has started and the include/exclude filters allow the table to be captured. In this case, the table's structure and JDBC type metadata are evaluated from the DDL event itself, and the ANTLR parser maps a REAL to a JDBC type of REAL rather than DOUBLE. This means that the final event will specify the schema type as FLOAT32 and the column type as REAL; which is different than if the table had been captured during snapshot.

To reproduce, start the MySQL connector with the table.include.list allowing the "test_real_table". Then, once the connector has started the streaming phase, create the following table, insert a row into the table, and note the field "r1" schema. Then repeat the process except where the following table is created before the connector starts with an existing row. Then, compare the schema of "r1" to the previous schema when the table was created during streaming, and they differ drastically.

CREATE TABLE test_real_table ( r1 real );

Regardless of when the table is created, REAL data types should be treated as a DOUBLE to conform with the JDBC driver, and the database as MySQL does not technically have REAL data type support and treats these explicitly as DOUBLE internally.