mypipe icon indicating copy to clipboard operation
mypipe copied to clipboard

Failure to deal with tableMap events

Open daveey opened this issue 9 years ago • 1 comments

It looks like CacheableTableMapBehaviour doesn't properly deal with tableMap events.

We have a table Foo that was mapped to id 71 for a while. We then had a failover, and the next binary log file has it mapped to 81. The table-map events are correct in the bin-log, and are being processed by the trait, but the tableCache doesn't register the new id->name and continues to return Foo for id=71

I had to work around in my code by adding:

... extends AbstractMySQLBinaryLogConsumer {
    var tableCacheBinLogPosition: Option[String] = None
    override protected def handleEvent(binaryLogEvent: MEvent): Unit = {
      if (Some(getBinaryLogPosition.get.filename) != tableCacheBinLogPosition) {
        logger.info("resetting table cache")
        this.tableCache = new TableCache(hostname, port, username, password)
      }
      super.handleEvent(binaryLogEvent)
      tableCacheBinLogPosition = Some(getBinaryLogPosition.get.filename)
    }
}

but it would be nice to have that logic go into the CacheableTableMapBehaviour behaviour

daveey avatar Jun 29 '15 20:06 daveey

It seems like adding a layer of inderiction to TableCache where we go from (db,table_name) -> table and table_id->(db,table_name) would fix this pretty cleanly

daveey avatar Jun 29 '15 21:06 daveey