I’m stumped on a replication issue and I’m wondering if percona-toolkit can assist. I am not a MySQL DBA (linux systems person by trade).
First pt-slave-find:
pt-slave-find --host localhost
localhost
Version 5.1.73-log
Server ID 1
Uptime 42+02:59:29 (started 2015-08-04T12:36:48)
Replication Is not a slave, has 1 slaves connected, is not read_only
Filters
Binary logging ROW
Slave status
Slave mode STRICT
Auto-increment increment 1, offset 1
InnoDB version BUILTIN
± [REDACTED IPADDRESS]
Version 5.1.73-log
Server ID 2
Uptime 06:34 (started 2015-09-15T15:29:43)
Replication Is a slave, has 0 slaves connected, is not read_only
Filters
Binary logging ROW
Slave status seconds behind, not running, error 1535
Slave mode STRICT
Auto-increment increment 1, offset 1
InnoDB version BUILTIN
It appears that error number 1535 means that the schema on your slave is not the same on the master, meaning one of them was ALTER’ed in some way, but not the other.
So you need to start by finding out what the difference is. If you look in the error log on the slave, it should give you the error that it quit on (searching the log for “1535” should find it). Once you know where the difference is, you’ll have to find out what the difference is and fix it. To find out what the difference is, the easiest way is to run “show create table ” on both the master and the slave, and compare the output to find out what the difference is. Then depending on which one is right, you’ll have to ALTER one of them to match the other one, which would most likely mean altering the slave (unless things are really out of whack, which is possible). If it does turn out the issue is on the master (i.e. someone modified the slave on accident instead of the master), then I would get professional help, as you could easily get in trouble quickly if you do the wrong thing on the master.
If you want to avoid all of that by just setting up a brand new slave, you could follow the below guide for Xtrabackup to do so:
[url]Percona XtraBackup