0

Turns out I have called RESET MASTER; accidentally on the live server. The slaves stopped replication now because they can not find the expected bin log files on the master. Is there a way to continue replication without data corruption and without reimporting the whole dump on the slave?

Is it save to call CHANGE MASTER TO... with 'mysql-bin.000001' and position 1 on the slave now, because that is where they should continue, or do I risk data corruption in that case and it is generally preferred to reimport the whole dump and start over?

Improve this question
1
  • 1
    Do not go back to the start, unless you have really replicated nothing.
    – Rick James
    Commented Jan 26, 2016 at 6:06

1 Answer 1

Reset to default
0

Considering all the slaves were in-sync with master while you issued reset-master, it is safe to issue change master to on slaves with newly generated first bin-log.

Improve this answer
3
  • Thanks, is there a way to find out if they were in sync? Considering this is a live environment with hundreds of requests per minute, there might be a chance that a transaction has been executed just before I called RESET MASTER and before the slaves could read it, right?
    – rewb0rn
    Commented Jan 26, 2016 at 8:57
  • it is possible that your reset master have erased the data before it got replicated... check for error log for more information about last binary log co-ordinates and match it with slaves... if not... Restoring slave is a sure shot here but if not possible or if data's too large you may checksum/sync your data.
    – mysql_user
    Commented Jan 26, 2016 at 9:03
  • makes sense, thank you. restoring from scratch now, just to be sure.
    – rewb0rn
    Commented Jan 26, 2016 at 11:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.