Details
-
Bug
-
Resolution: Done
-
Major
-
0.3.1
-
None
Description
See MODE-115 for the original motivation. Basically, the MySQL connector should do a bit more checking upon startup to provide useful info/warn messages or fail if certain requirements are not met. For example:
- Upon startup check the MySQL server to verify that it is using a row-level binlog, and if not either warn or fail, depending upon the situation. For example, if the connector is configured to just perform a snapshot and then stop, the connect can just issue a warning message if the server does not have the row-level binlog enabled. On the other hand, when starting and needing to read the binlog, if the server does not have the row-level binlog enabled then the connector should fail.
- Upon initial startup and not performing an initial snapshot, the connector should verify whether the MySQL server is likely to have purged binlog files, meaning the binlog likely doesn't have the complete history for all the databases. In this case, the connector should issue a warning, since it is technically possible to enable the row-level binlog on a server that's been running a while, create a new database, and then use the MySQL connector to capture the changes on just that database. In this case, the binlog does contain the complete history of that database, but there's no way of verifying this.
Attachments
Issue Links
- is related to
-
DBZ-115 Producer does not send any new events to Kafka after snapshot when using MySQL 5.5
- Closed