The setup right now is as follows:

SuSE    master 4.0.26 as compiled by SuSE w/o InnoDB
SuSE    slave  4.0.26 MySQL binaries from tar.gz
Debian1 slave  4.0.26 MySQL binaries from tar.gz
Debian2 slave  4.0.26 MySQL binaries from tar.gz
XP      slave  4.0.20 MySQL binaries from zip

Debian2 slave is running idle, not used for production, just replicating.
XP is a "private" slave in my office

SuSE    master 4.0.26 fine
SuSE    slave  4.0.26 fine
Debian1 slave  4.0.26 problems
Debian2 slave  4.0.26 fine 
XP      slave  4.0.20 fine 

I never had these problems on Debian1 or else. They happened to start
yesterday, as far as I remember; I could only get rid of them with
emptying tables I didn't really need - then I had to trave. As I am
back now, I still have these problems and wonder what they mean.

Example:

MySQL Debian>SHOW SLAVE STATUS\G
*************************** 1. row ***************************
          Master_Host: pz-server1.***.com
          Master_User: repl
          Master_Port: 3306
        Connect_retry: 60
      Master_Log_File: pz-server1-bin.727
  Read_Master_Log_Pos: 129804731
       Relay_Log_File: server8324611625-relay-bin.167
        Relay_Log_Pos: 22344325
Relay_Master_Log_File: pz-server1-bin.726
     Slave_IO_Running: Yes
    Slave_SQL_Running: No
      Replicate_do_db: ***
  Replicate_ignore_db: 
           Last_errno: 1062
           Last_error: Error 'Duplicate entry '38278' for key 1' on query. Default database: '***'. Query: 'INSERT INTO anzeigen
        (kid, description, descShort, datum, av, rubrik, laufZeit)
        VALUES ('27296','Verkaufe 1 DVD ***','Verkaufe 1 DVD ***','2005-10-13','a','Videos',DATE_ADD(CURDATE(), INTERVAL 42 DAY)) '
         Skip_counter: 0
  Exec_master_log_pos: 209296424
      Relay_log_space: 117556869
1 row in set (0.00 sec)

There should be no duplicate error on an insert into a myisam table
with an autoincrement primary key, except the table is corrupt.

MySQL Debian>check table anzeigen;
+------------------------+-------+----------+-----------------------------------------------------------------+
| Table                  | Op    | Msg_type | Msg_text                                                        |
+------------------------+-------+----------+-----------------------------------------------------------------+
| *************.anzeigen | check | error    | Found key at page 801792 that points to record outside datafile |
| *************.anzeigen | check | error    | Corrupt                                                         |
+------------------------+-------+----------+-----------------------------------------------------------------+
2 rows in set (0.07 sec)

Ok, it is. How come??

MySQL Debian>repair table anzeigen;
+------------------------+--------+----------+----------+
| Table                  | Op     | Msg_type | Msg_text |
+------------------------+--------+----------+----------+
| *************.anzeigen | repair | status   | OK       |
+------------------------+--------+----------+----------+
1 row in set (9.33 sec)

Now we expect this entry to not be there because the insert has
failed, right?

MySQL Debian>INSERT INTO anzeigen
    ->         (kid, description, descShort, datum, av, rubrik, laufZeit)
    ->         VALUES ('27296','Verkaufe 1 DVD ***','Verkaufe 1 DVD ***','2005-10-13','a','Videos',DATE_ADD(CURDATE(), INTERVAL 42 DAY));
ERROR 1062: Duplicate entry '27296-a-Videos-Verkaufe 1' for key 2

Why that?

MySQL Debian>select * from anzeigen where id = 38278\G
*************************** 1. row ***************************
         id: 38278
        kid: 27296
description: Verkaufe 1 DVD ***
      datum: 2005-10-13
         av: a
     rubrik: Videos
  descShort: Verkaufe 1
   laufZeit: 2005-11-24
    counter: 0
     tmstmp: 20051013171720
 autoextend: no
1 row in set (0.00 sec)

Hm, the insert has happened and then the error was raised after that?
Weird.

I have this all the time. Next example:


MySQL Debian>SHOW SLAVE STATUS\G
*************************** 1. row ***************************
          Master_Host: pz-server1.***.com
          Master_User: repl
          Master_Port: 3306
        Connect_retry: 60
      Master_Log_File: pz-server1-bin.727
  Read_Master_Log_Pos: 139186279
       Relay_Log_File: server8324611625-relay-bin.167
        Relay_Log_Pos: 47832836
Relay_Master_Log_File: pz-server1-bin.726
     Slave_IO_Running: Yes
    Slave_SQL_Running: No
      Replicate_do_db: ***
  Replicate_ignore_db: 
           Last_errno: 1062
           Last_error: Error 'Duplicate entry 'holländische+reitpferde' for key 1' on query. Default database: '***'. Query: 'INSERT INTO searchTerms
                                (term, counter)
                                VALUES ('holländische+reitpferde', 1) /* Link_ID Resource id No.14 | Host_Master pz-server1.***.com | SERVER_ADDR 82.198.83.154*/'
         Skip_counter: 0
  Exec_master_log_pos: 234229410
      Relay_log_space: 127139297
1 row in set (0.00 sec)

MySQL Debian>select * from searchTerms where term = 'hollndische+reitpferde';
Empty set (0.00 sec)

How can this be?

MySQL Debian>check table searchTerms;
+---------------------------+-------+----------+----------+
| Table                     | Op    | Msg_type | Msg_text |
+---------------------------+-------+----------+----------+
| *************.searchTerms | check | status   | OK       |
+---------------------------+-------+----------+----------+
1 row in set (0.32 sec)

Hm, wrong search, should be holländische+reitpferde - somehow I can't
paste this, the umlaut won't appear, so let's try it this way:

MySQL Debian>select * from searchTerms where term like 'holl_ndische+reitpferde';
+-------------------------+---------+
| term                    | counter |
+-------------------------+---------+
| holländische+reitpferde |       1 |
+-------------------------+---------+
1 row in set (0.00 sec)

Ah, we do have it. 

This is the code which generates this query:

	while(list(, $val) = each($ar)) {
		$q = "UPDATE $table
		      	SET counter = counter +1
		      	WHERE term = '"
		      	              . addSlashes($val)
		      	              . "'";
		$db->query($q);
		if (!$db->affected_rows()){
			$q = "INSERT INTO $table
				(term, counter)
				VALUES ('"
				         . addSlashes($val)
				         . "', 1)";
			$db->query($q);
		}
	}

We theoretically could have another thread interfering here if it
would happen on the master, but then it would not be passed on to the
slave - besides, the other slaves don't have this error.

Next error:

MySQL Debian>SHOW SLAVE STATUS\G
*************************** 1. row ***************************
          Master_Host: pz-server1.***.com
          Master_User: repl
          Master_Port: 3306
        Connect_retry: 60
      Master_Log_File: pz-server1-bin.727
  Read_Master_Log_Pos: 141706074
       Relay_Log_File: server8324611625-relay-bin.167
        Relay_Log_Pos: 56524507
Relay_Master_Log_File: pz-server1-bin.726
     Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
      Replicate_do_db: ***
  Replicate_ignore_db: 
           Last_errno: 1062
           Last_error: Error 'Duplicate entry 'wenden' for key 1' on query. Default database: '***'. Query: 'INSERT INTO bookSearch
                        (term, counter)
                        VALUES ('wenden', 1) /* Link_ID Resource id No.14 | Host_Master pz-server1.***.com | SERVER_ADDR 83.246.116.25*/'
         Skip_counter: 1
  Exec_master_log_pos: 242692346
      Relay_log_space: 129694912
1 row in set (0.00 sec)


Same thing, I guess.

MySQL Debian>select * from bookSearch where term = 'wenden';
+--------+---------+
| term   | counter |
+--------+---------+
| wenden |       1 |
+--------+---------+
1 row in set (0.00 sec)

MySQL Debian>check table bookSearch;
+--------------------------+-------+----------+----------+
| Table                    | Op    | Msg_type | Msg_text |
+--------------------------+-------+----------+----------+
| *************.bookSearch | check | status   | OK       |
+--------------------------+-------+----------+----------+
1 row in set (0.22 sec)


Next evidence:



MySQL Debian>SHOW SLAVE STATUS\G 
*************************** 1. row ***************************
          Master_Host: pz-server1.***.com
          Master_User: repl
          Master_Port: 3306
        Connect_retry: 60
      Master_Log_File: pz-server1-bin.727
  Read_Master_Log_Pos: 151583020
       Relay_Log_File: server8324611625-relay-bin.167
        Relay_Log_Pos: 70542169
Relay_Master_Log_File: pz-server1-bin.726
     Slave_IO_Running: Yes
    Slave_SQL_Running: No
      Replicate_do_db: ***
  Replicate_ignore_db: 
           Last_errno: 1062
           Last_error: Error 'Duplicate entry '113684' for key 1' on query. Default database: '***'. Query: 'INSERT INTO bild
                        (id, comment, pid , typBild, width , height, format, paid , datum, kid)
                        VALUES ('', 'Koppeln', '38276', 'a', '', '', '.jpg', 'n', '2005-10-13', '40614') /* Link_ID Resource id No.13 | Host_Master localhost | SERVER_ADDR 82.198.83.74*/'
         Skip_counter: 0
  Exec_master_log_pos: 256415753
      Relay_log_space: 139728998
1 row in set (0.00 sec)

MySQL Debian>check table bild;
+--------------------+-------+----------+----------------------------------------------------------+
| Table              | Op    | Msg_type | Msg_text                                                 |
+--------------------+-------+----------+----------------------------------------------------------+
| *************.bild | check | warning  | 2 clients are using or haven't closed the table properly |
| *************.bild | check | status   | OK                                                       |
+--------------------+-------+----------+----------------------------------------------------------+
2 rows in set (1.29 sec)

MySQL Debian>select * from bild where id=113684\G
*************************** 1. row ***************************
     id: 113684
comment: Koppeln
    pid: 38276
typBild: a
  width: 400
 height: 267
 format: .jpg
   paid: y
  datum: 2005-10-13
    kid: 40614
1 row in set (0.00 sec)

Hm, I guess I should 

MySQL Debian>set slave-skip-errors=1062;
ERROR 1193: Unknown system variable 'slave'
MySQL Debian>set slave_skip_errors=1062;
ERROR 1193: Unknown system variable 'slave_skip_errors'


Hm, bad. Have to restart server for that...

ok, done, next type of error:

MySQL Debian>SHOW SLAVE STATUS\G
*************************** 1. row ***************************
          Master_Host: pz-server1.***.com
          Master_User: repl
          Master_Port: 3306
        Connect_retry: 60
      Master_Log_File: pz-server1-bin.727
  Read_Master_Log_Pos: 174181258
       Relay_Log_File: server8324611625-relay-bin.167
        Relay_Log_Pos: 137323525
Relay_Master_Log_File: pz-server1-bin.726
     Slave_IO_Running: Yes
    Slave_SQL_Running: No
      Replicate_do_db: ***
  Replicate_ignore_db: 
           Last_errno: 1050
           Last_error: Error 'Table 'log_visitors_051014' already exists' on query. Default database: '***'. Query: 'CREATE TABLE `log_visitors_051014` (
  `ip` varchar(16) NOT NULL default '',
  `tmstmp` timestamp(14) NOT NULL,
  PRIMARY KEY  (`ip`,`tmstmp`)
) TYPE=MyISAM COMMENT='count visitors' /* Link_ID Resource id No.15 | Host_Master pz-server1.***.com | SERVER_ADDR 83.246.116.25*/'
         Skip_counter: 0
  Exec_master_log_pos: 321818219
      Relay_log_space: 496398975
1 row in set (0.00 sec)


Now it catches up. I will reset this slave tomorrow morning and expect
that problems will be gone as a consequence.

These are tables which seem to produce lock contention:

CREATE TABLE `bild` (
  `id` mediumint(8) unsigned NOT NULL auto_increment,
  `comment` text NOT NULL,
  `pid` mediumint(8) unsigned NOT NULL default '0',
  `typBild` char(1) NOT NULL default '',
  `width` mediumint(8) unsigned NOT NULL default '0',
  `height` mediumint(8) unsigned NOT NULL default '0',
  `format` varchar(4) NOT NULL default '',
  `paid` char(1) NOT NULL default '',
  `datum` date NOT NULL default '0000-00-00',
  `kid` mediumint(8) unsigned NOT NULL default '0',
  PRIMARY KEY  (`id`),
  KEY `pid` (`pid`),
  KEY `kid` (`kid`),
  KEY `typBild` (`typBild`),
  KEY `typBild_2` (`typBild`),
  KEY `typBild_3` (`typBild`)
) TYPE=MyISAM PACK_KEYS=1 

CREATE TABLE `sessData` (
  `sid` varchar(42) NOT NULL default '',
  `varsVal` mediumtext NOT NULL,
  `datum` timestamp(14) NOT NULL,
  PRIMARY KEY  (`sid`),
  KEY `datum` (`datum`)
) TYPE=MyISAM

CREATE TABLE `pferde_counter` (
  `id` mediumint(8) unsigned NOT NULL default '0',
  `counterListe` mediumint(8) unsigned NOT NULL default '0',
  `counterTabelle` mediumint(8) unsigned NOT NULL default '0',
  `counterDatenblatt` mediumint(8) unsigned NOT NULL default '0',
  `counterMerken` mediumint(8) unsigned NOT NULL default '0',
  `tmstmp` timestamp(14) NOT NULL,
  PRIMARY KEY  (`id`)
) TYPE=MyISAM

The statements leading to contention are all in perfect shape. There
seems to be no reason why lock contention should occur in the first
place.