Return to Answer

The book Understanding MySQL Internals (click to download PDF)

The book "Understanding MySQL Internals" (ISBN 0-596-00957-7)

• codes get interpreted by mysqlbinlog when extracting and displaying SQL commands
• MySQL Replication
• IO Thread interprets events and checks for validity before storing the events in the binlog
• SQL Threads interprets events from relay log and executes the commands

What would happen is

• codes get interpreted by mysqlbinlog when extracting and displaying SQL commands
• MySQL Replication
• IO Thread interprets events and stores the events in the binlog
• SQL Threads interprets and validates events from relay log and executes the commands

What would happen is the following:

I had run kill -9 on the mysqld_safe. service mysql start --skip-slave-start, run CHANGE MASTER TO the next available position, START SLAVE; , and replication was off and running.

If this crazy scenario was possible from MySQL 5.5.30 Master to MySQL 5.6.21 Slave, (as I have seen happen and have done multiple maintenances to correct), then the reverse is far more likely (the reverse being a new Master and an older Slave).

To correct this madness, I had to do the following:

• Run kill -9 on the mysqld_safe process
• Run service mysql start --skip-slave-start
• Run CHANGE MASTER TO the next available position
• Run START SLAVE;

From there, replication was off and running. This has happened to my boss once and to me once. Of course, I reloaded the data from the Master in full to get the Slave sync'd (Good thing the database was less than 100MB).

If this crazy scenario was possible from a MySQL 5.5.30 Master to MySQL 5.6.21 Slave, (as I have shown happen and two maintenance cycles to correct), then the reverse is far more likely (the reverse being a new Master and an older Slave).