1

I'm migrating a cluster that has the following set for slave-skip-errors:

slave-skip-errors = 0,1062,1053,1051

Of course, as these things go, nobody knows why it was setup like this or who did it, or if they're even with the company. I also know why NOT to put slave-skip-errors of any kind, but I am totally clueless as to the "0". The replication I'm setting up will not have any slave-skip-errors.

Looking at http://dev.mysql.com/doc/refman/5.7/en/error-messages-server.html I can find all the codes that are skipped. I can only assume that the zero is a sort of catch-all for slave-skip-errors? My google-fu is not so strong on this one, I can't really find an answer to my question, so I'm hoping that some MySQL guru here will be able to confirm or deny the 0, and if it in fact does anything.

Thanks!

Improve this question
3
  • dba.stackexchange.com for the dba gurus
    – user9517
    Oct 21, 2016 at 20:45
  • If a binlog event is replicated in that causes an error on the master, but not the slave -- unusual but possible -- replication will (correctly) stop because this condition -- like all replication errors -- means your replica is likely broken. Since "error 0" is "success," this configuration might prevent replication from stopping under that specific condition. Skipping replication errors of any kind should only be used in emergency conditions, because a replica with valid data and configuration will not throw errors. Horrible hack if true.
    – Michael - sqlbot
    Oct 21, 2016 at 22:27
  • Yes, I know any error skipping is a terrible idea, and it's not set on the new servers. The old servers will be decommissioned, and no one wants to touch that specific hornet's nest. :) Drookie is most likely correct, since the codes all start above 1000, and I have a sneaky suspicion that this value doesn't actually do anything. The cluster is a mess, that's why the migration is happening anyway.
    – Vladimir
    Oct 22, 2016 at 10:00

1 Answer 1

Reset to default
2

There shouldn't be any of these, this configuration directive should be set to default (not ignoring any of the errors). As simple as that. And if I were you - I would reinitialize the whole replica. It's almost inevitably out of sync, on logical level.

This urban legend (setting non-default slave-skip-errors) comes out of two things:

  • lack of understanding how the replication works
  • the funny fact that MySQL doesn't set replica to read-only by default, so any clients that still connect to it (due to stale connection descriptors, or stuck connection poolers) may easily damage it. So every replica probably needs to be read-only, unless there's a cyclic chain replication (from my point of view - another nonsense) or at least definitive understanding why it should be read-write.
Improve this answer
4
  • The current cluster is a total and utter mess and very sensitive for our customer. I took a logical dump from one of the slaves with the coordinates, importing it into the new cluster. The datadir is huge, 700 gigs or so, and I do realize that the cluster is not consistent, but I have to work with what I have with minimal service interruptions for the switchover. So, you know that the 0 is a completely nonsense value for the slave-skip-errors directive?
    – Vladimir
    Oct 21, 2016 at 21:26
  • I know it should be set to OFF.
    – drookie
    Oct 21, 2016 at 21:42
  • And it's a string, so you can write just anything there, the question is how it's parsed. I would check the show variables like 'slave_skip_errors'; may be it will give a clue on that. Hopefully there can be a parsed and applied value.
    – drookie
    Oct 21, 2016 at 21:44
  • slave_skip_errors shows that same setting of 0, and the other ones. I'll accept your answer as I think it's the valid one. Thanks for the input. :)
    – Vladimir
    Oct 22, 2016 at 10:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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