2013-07-26 3 views
5

Ich versuche, das mysql binary log ROW-Format manuell zu dekodieren. Jedem update/insert/delete-Ereignis ist ein TABLE_MAP_EVENT vorangestellt.mysqlbinarylog - Eindeutigkeit von table_id in TABLE_MAP_EVENT

Dieses Ereignis enthält eine table_id. Ich verwende diese ID, um einen Cache für die Spaltendefinition dieser Tabelle aufzubauen.

Von Zeit zu Zeit habe ich Fehler in diesem Cache, weil Spalteninformationen nicht übereinstimmen. Ich bin derzeit nicht in der Lage, diese Probleme in kurzen lebenden Verbindungen zu reproduzieren, nur in Log-Verbindungen, wo Binär-Log-Datei Rotation auftritt.

Ich vermute, dass die table_id nur für eine binäre Protokolldatei eindeutig ist. Weiß jemand, ob diese Annahme zutrifft? Weiß jemand wo die Dokumentation zu finden ist, die erklärt, was ich von der table_id erwarten kann?

Vielen Dank im Voraus Björn

Antwort

0

Da ich nicht Ihre tatsächliche Implementierung sehen kann, ist dies nur eine blinde Vermutung, aber einen Blick auf dem Bug unten nehmen, vielleicht, dass Ihre Kopfschmerzen verursacht: 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.* 
      (...) 
0

Nein, es gibt keine Nachschlagetabellen für binäre Protokolltabellen-ID-Werte.

Sie müssen WRITE/UPDATE/DELETE Binlog-Ereignisse in Bezug auf ihre vorherigen TABLE_MAP-Ereignisse verarbeiten.

Tatsächlich gibt es eine Spalte TABLE_ID innerhalb INFORMATION_SCHEMA.INNODB_SYS_TABLES, aber diese Nummern unterscheiden sich von den Tabellen-IDs, die in den binären Protokollereignissen von TABLE_MAP auftreten.

Verwandte Themen