今天收到邮件mysql从库同步出错了，后来跟开发沟通了一下说是，测试的时候向从库里插入过数据，后来删除了，以为不会影响主库，然后这个程序再向主库插入数据的时候报这个错了，
网上找了一下解决方法：
修改mysql配置文件 /etc/my.cnf 在 [mysqld]下加一行 slave_skip_errors = 1062 ,保存.重启mysql. mysql slave可以正常同步了.
这样对于数据的完整性没有保障
见：Replication Slave Options and Variables
--slave-skip-errors=[err_code1,err_code2,...|all]
| Command-Line Format | --slave-skip-errors=name |
||
| System Variable | Name | slave_skip_errors |
|
| Variable Scope | Global | ||
| Dynamic Variable | No | ||
| Permitted Values | Type | string |
|
| Default | OFF |
||
| Valid Values | OFF |
||
[list of error codes] |
|||
all |
|||
Normally, replication stops when an error occurs on the slave. This gives you the opportunity to resolve the inconsistency in the data manually. This option tells the slave SQL thread to continue replication when a statement returns any of the errors listed in the option value.
Do not use this option unless you fully understand why you are getting errors. If there are no bugs in your replication setup and client programs, and no bugs in MySQL itself, an error that stops replication should never occur. Indiscriminate use of this option results in slaves becoming hopelessly out of synchrony with the master, with you having no idea why this has occurred.
For error codes, you should use the numbers provided by the error message in your slave error log and in the output of SHOW SLAVE STATUS. Appendix B, Errors, Error Codes, and Common Problems, lists server error codes.
You can also (but should not) use the very nonrecommended value of all to cause the slave to ignore all error messages and keeps going regardless of what happens. Needless to say, if you use all, there are no guarantees regarding the integrity of your data. Please do not complain (or file bug reports) in this case if the slave‘s data is not anywhere close to what it is on the master. You have been warned.
Examples:
--slave-skip-errors=1062,1053 --slave-skip-errors=all