View Issue Details

IDProjectCategoryView StatusLast Update
0000236SymmetricDSBugpublic2010-01-19 16:56
ReporterAssigned Tochenson  
Priorityhigh 
Status closedResolutionfixed 
Product Version2.0.0 
Target Version2.1.0Fixed in Version2.1.0 
Summary0000236: MySQL InnoDB generates batches with same id if rows are cleaned from the sym_outgoing_batch and Mysql is restarted after that
Description"MySQL InnoDB generates batches with same id if rows are cleaned from the sym_outgoing_batch and Mysql is restarted after that. This problems is due to MySQL InnoDB behaviour. Quoting [MySQL 5.1 manual|http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html#innodb-auto-increment-traditional] {quote} If you specify an AUTO_INCREMENT column for an InnoDB table, the table handle in the InnoDB data dictionary contains a special counter called the auto-increment counter that is used in assigning new values for the column. This counter is stored only in main memory, not on disk. InnoDB uses the following algorithm to initialize the auto-increment counter for a table t that contains an AUTO_INCREMENT column named ai_col: After a server startup, for the first insert into a table t, InnoDB executes the equivalent of this statement: SELECT MAX(ai_col) FROM t FOR UPDATE; {quote} Same batchid's appear on Symmetric client node and that causes the batches to be skipped on the client (""WARN [impl.IncomingBatchService] [pulljob] Skipping batch XXXXX-12345"" errors in symmetric.log) A workaround might be to set the same ""purge.retention.minutes"" period on the client and server. This might not help in all cases. The proper fix would be not to delete the last row from Symmetric tables in PurgeService. That would keep the state of the next primary key value and keep it over mysql server restarts."
TagsNo tags attached.

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change