Question

I am trying to manually decode the mysql binary log ROW format. Every update/insert/delete event is preceeded by an TABLE_MAP_EVENT.

This event contains a table_id. I am using this id to build up an cache for the column definition of this table.

From time to time I am having errors in said cache, because mismatch of column information. I am currently not able to reproduce these problems in short living connections, only in log connections where binary log file rotation occurs.

I am suspecting that the table_id is only unique for one binary log file. Does anyone knows if this assumption holds true? Does anyone know where to find the documentation which declares what I can expect from the table_id?

Thanks in advance Björn

Was it helpful?

Solution 2

Since I cannot see your actual implementation, this is just a blind guess, but take a look at the bug below, maybe that causes your headache: http://bugs.mysql.com/bug.php?id=67352

        Table IDs used in replication were defined as type ulong on the 
        master and uint on the slave. In addition, the maximum value for 
        table IDs in binary log events is 6 bytes (281474976710655). This 
        combination of factors led to the following issues:

            Data could be lost on the slave when a table was assigned an 
            ID greater than uint.

            *Table IDs greater than 281474976710655 were written to the 
            binary log as 281474976710655.*
            (...)

OTHER TIPS

No, there aren't any lookup tables for binary log table id values.

You have to process WRITE/UPDATE/DELETE binlog events with respect to their previous TABLE_MAP events.

Actually there is a TABLE_ID column inside INFORMATION_SCHEMA.INNODB_SYS_TABLES but those numbers are different than the table ids that occur in TABLE_MAP binary log events.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top