couldn't find table after table rename

[bmichaud]

Maxwell 1.3.0 After renaming a table in the replicated schema, like this: ALTER TABLE myOldTable RENAME TO myNewTable;

We sometimes, but not every time it seems, get this error in the logs:

com.zendesk.maxwell.schema.ddl.InvalidSchemaError: Couldn't find table 'myOldTable' in database 'rso_01 at com.zendesk.maxwell.schema.Database.findTableOrThrow(Database.java:55) at com.zendesk.maxwell.schema.ddl.TableAlter.resolve(TableAlter.java:37) ... at com.zendesk.maxwell.Maxwell.main(Maxwell.java:181) 09:24:38,376 INFO Maxwell - starting shutdown

[osheroff]

does this happen near to schema-capture-time like your other issue? Or is this maxwell running in a steady state?

I'm very tempted to go poke at some multi-client code-paths, but I'm not quite sure where to start...

[bmichaud]

I am sure this was not during schema-capture. A DDL script was executing during normal capture operations. There were two log messages prior to this that indicate that other statements from the script were executed. Here they are (names changed to avoid complications by way of complicating and confusing things):

09:24:38,096 INFO AbstractSchemaStore - storing schema @BinlogPosition[binarylog.000011:59240385] after applying "CREATE TABLE myOtherTablePlan (myOtherTablePlanID BIGINT (19) , myOtherTableTimelineID BIGINT (19) , personID BIGINT (15) , subscriberID BIGINT (19) , tableFourOptionID BIGINT (19) , tableFiveID BIGINT (19) , somethingOnlyInd SMALLINT (1) , thingaMaJigSequence SMALLINT (3) , somethingthingaMaJigSequence SMALLINT (3) , personblahID BIGINT (19) , blahSequence SMALLINT (3) , masterSequence SMALLINT (3) , changeDateTime TIMESTAMP (3) , changeUserID VARCHAR (20) , createDateTime TIMESTAMP (3) , createUserID VARCHAR (20) , updateVersion INT (10) , PRIMARY KEY (myOtherTablePlanID))" 09:24:38,264 INFO AbstractSchemaStore - storing schema @BinlogPosition[binarylog.000011:59240848] after applying "CREATE TABLE myOtherTableTimeline (myOtherTableTimelineID BIGINT (19) , myOtherTableColumnTimelineID BIGINT (19) , myThirdTableTimelineID BIGINT (19) , personID BIGINT (15) , effectiveDate DATE , expirationDate DATE , changeDateTime TIMESTAMP (3) , changeUserID VARCHAR (20) , createDateTime TIMESTAMP (3) , createUserID VARCHAR (20) , updateVersion INT (10) , PRIMARY KEY (myOtherTableTimelineID))"

There were two Maxwell instances (clients) capturing on the same database node using the same maxwell schema in this case as well.

[osheroff]

pretty sure this was also a result of a different bug that de-synced the schema.