Thing 1: your auto_increment key MUST be your primary key. Thing 2: the timestamp field will be updated with the current epochal timestamp which only increments every second.. as you have a timestamp field as you primary (and therefore unique) key, you will never be able to perform more than one INSERT/UPDATE within the span of any given second.
you need to redign the table, I'm afraid. On 9/11/07, WiNK / Rob <[EMAIL PROTECTED]> wrote: > Hi , > > I think i might have hit a bug, posted on forums.mysql.com but > apparently nobody really reads that i think. > > my table: > > CREATE TABLE `clog` ( `cID` int(20) NOT NULL auto_increment, `lID` > int(10) default NULL, `ip` int(10) default NULL, `timestamp` int(11) NOT > NULL, PRIMARY KEY (`clickID`) ) ENGINE=MYISAM; or i use ARCHIVE > > I have a bit of a problem that occurs only when i change my really > simple log table to the archive engine. The replication breaks. Any > thoughts? The row number of the error is variable. When the table is set > to myisam, the replication does not break on duplicate key, and runs as > expected. > > Can't write; duplicate key in table 'clog'' on query. > > Is it possible that due to the stress of the benchmark, my slave cannot > compute the next cID or creates a duplicate (cId is the only variable > that changes, on bench query)? > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > > -- - michael dykman - [EMAIL PROTECTED] - All models are wrong. Some models are useful. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
