我的复制突然脱机。 SHOW SLAVE STATUS显示I / O线程正在运行，而SQL线程则不在。
我有错误消息：
致命错误：发现已经映射但具有不同设置的表映射事件映射表ID 0。
我一直无法find这个使用谷歌的解决scheme。
停止/启动从机没有多大帮助。
如果你的主服务器版本比MySQL 5.1.53版本早，你已经遇到了错误。
http://bugs.mysql.com/bug.php?id=56226
MySQL 5.1.53的变化（2010-11-03） –
复制：更改
MyISAM表的列而不设置列大小的ALTER TABLE语句导致二进制日志在多个表上的更新（包括删除）意外地设置为0时被损坏，导致在复制失败时导致复制失败多个表格收到相同的表格地图ID。 （错误＃56226，错误＃11763509）– http://dev.mysql.com/doc/relnotes/mysql/5.1/en/news-5-1-53.html
现在的问题已经过了几天了，所以你现在可能已经重build了复制了。 如果您的服务器版本较旧，则应升级，因为问题可能会返回。
如果没有，你可能会SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; 并跳过无效的表格映射条目…虽然我不确定这可以在这种情况下使用。 即使它看起来有效，那么您很可能会有一个与主服务器分离的从服务器，因此您需要validation使用第三方工具的两台服务器上的数据是否相同。
如果你的服务器不老，这表明一个损坏的二进制日志，这不应该发生，但如果这样做，可能意味着其他问题的主人或奴隶迫在眉睫。
如果复制失败，最好重新开始，而不是排除故障。
1）在主要的MySQL服务器上FLUSH TABLES WITH READ LOCK;
2）转储所有数据库mysqldump -uusername --all-databases -p | gzip -2 > dump.sql.gz mysqldump -uusername --all-databases -p | gzip -2 > dump.sql.gz
3）在主MySQL服务器上UNLOCK TABLES; //不一定是CAPS。
4）将您的文件scp到辅助MySQL服务器。
5） slave stop; 在辅助MySQL服务器上。
6）在辅助MySQL服务器上导入dump.sql.gz，如下所示：
gunzip < dump.sql.gz | mysql -uusername -password
7）如果你已经正确设置你的MASTERconfiguration，你可以启动slave
start slave;
8）显示slave SHOW SLAVE STATUS\G;
检查特定的错误代码并更新您的答案以提供更多详细信息。 如果可能的话