When initializing MySQL replication between version 5.5.16-1 (master) and 5.5.18-1 (slave), the duplicate key error typically occurs during these specific conditions:

-- Master snapshot creation method
FLUSH TABLES WITH READ LOCK;
mysqldump --all-databases --master-data > dbdump.sql

The slave fails with error 1062 despite:

• Single record existing on master (verified by COUNT(*))
• Proper dump import procedure
• Skip-slave-start being used initially

Standard troubleshooting attempts that proved ineffective:

-- Common resolution attempt
STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;

The Master_Log_Pos=4 anomaly suggests potential binary log initialization issues. This manifests when:

-- Verification query
SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Master_Log_File: 
          Read_Master_Log_Pos: 4

Instead of using skip-errors, implement this comprehensive solution:

-- Complete reinitialization procedure
STOP SLAVE;
RESET SLAVE ALL;
DROP DATABASE db;
-- Reimport with proper position tracking
mysql -uroot -p < dbdump.sql
CHANGE MASTER TO
  MASTER_HOST='x.x.x.x',
  MASTER_USER='xx',
  MASTER_PASSWORD='xxx',
  MASTER_LOG_FILE='mysql-bin.00000X',
  MASTER_LOG_POS=Y;
START SLAVE;

Always cross-validate binary log positions:

-- On master server
SHOW MASTER STATUS;
-- On slave before starting replication
SHOW SLAVE STATUS\G

• Use mysqldump --single-transaction for InnoDB tables
• Verify table checksums post-import
• Implement pt-table-checksum for consistency validation

For persistent issues, consider:

-- Alternative initialization method
STOP SLAVE;
SET GLOBAL slave_parallel_workers=0;
SET GLOBAL sync_relay_log=1;
-- Reinitialize from exact binary log position

When setting up MySQL replication between v5.5.16 (master) and v5.5.18 (slave), the following steps were taken:

# On master:
mysql> FLUSH TABLES WITH READ LOCK;
shell> mysqldump --all-databases --master-data > dbname_date +%F.sql

# On slave:
shell> pv dbname_date +%F.sql | mysql -u root -p
mysql> START SLAVE;

The slave fails with error:

Last_SQL_Errno: 1062
Last_SQL_Error: Error 'Duplicate entry '115846' for key 'PRIMARY'' on query.
Default database: 'db'. Query: 'INSERT INTO request_posted (id, user_id, channel...)

Despite verifying only one record exists on master:

mysql> SELECT COUNT(*) FROM request_posted WHERE id=115846;
+----------+
| COUNT(*) |
+----------+
|        1 |
+----------+

Several troubleshooting methods were attempted:

# Method 1: Skip counter
mysql> STOP SLAVE;
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
mysql> START SLAVE;

# Method 2: Reinitialization
shell> rm -rf /var/lib/mysql/*
shell> mysql_install_db

The slave status shows unusual Master_Log_Pos value:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: x.x.x.x
          Read_Master_Log_Pos: 4
               Relay_Log_File: mysqld-relay-bin.000001
                Relay_Log_Pos: 4
             Slave_IO_Running: No
            Slave_SQL_Running: No

1. Verify binary log coordinates before starting replication:

# On master after dump:
mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 107      |              |                  |
+------------------+----------+--------------+------------------+

# On slave before start:
mysql> CHANGE MASTER TO
    -> MASTER_HOST='master_host',
    -> MASTER_USER='repl_user',
    -> MASTER_PASSWORD='password',
    -> MASTER_LOG_FILE='mysql-bin.000003',
    -> MASTER_LOG_POS=107;

2. Alternative dump method for consistent snapshots:

shell> mysqldump --single-transaction --master-data=2 --all-databases > dump.sql

• Always verify master status after FLUSH TABLES WITH READ LOCK
• Use --single-transaction for InnoDB tables to avoid locking
• Confirm slave status coordinates match master before starting
• Consider using GTID-based replication for version 5.6+