Ошибка репликации MySQL: Error_code: 1032

Depending on what engine(s) you are using, whether you are using multiple schemata, and the options you are using with mysqldump you might not be getting a consistent dump.

If you have two schemata, let's say one named development and another named production, mysqldump locks the tables separately for each schema. That means while you're backing up the development schema the production schema is still writable and being updated.

Now that you have your dump of the two schemata and start up replication, the two schemata are actually on different binlog positions. That means when you get Error_code 1032 you really don't have that key.

If all of the tables that you need to backup are InnoDB you should look into the --single-transaction option to mysqldump. If you have a mix of InnoDB and MyISAM then only the InnoDB tables are guaranteed to be consistent. The MyISAM tables will still be written to using this option.

If you have a mix of InnoDB and MyISAM or are pure MyISAM only, the best option (using mysqldump) is to use --lock-all-tables. That does exactly what it sounds like, nothing will be written to until the dump is complete. This has the major drawback that your application or website that depends on the database is locked too (since it can't write).

The best option IMO is to move everything to InnoDB if it isn't already and use Percona Xtrabackup. It will still work fine with MyISAM tables as well, but through a different tool than the InnoDB tables (cp or rsync). It still will need to lock the tables while copying the MyISAM tables but it does its' best to minimize that time. If you use the rsync method then the tool will first copy all of your MyISAM tables, then lock the tables, and then it copies any tables that have been updated since the first copy. The lock only needs to be held during that second rsync.