After /var partition on master MySQL server was full, replication has stopped working. Master server wasn’t able to write new changes to the binlog file. Recovery procedure seems simple, clean /var partition and restart slave servers but it was not so easy.
MySQL replication on slave (version 5.1.61) has stopped. Slave_IO_Running was marked as Yes, but Slave_SQL_Running as No. Simple stop/start slave didn’t help so further problem analysis was needed. It seemed that current slave’s relay log was corrupted because testing with “mysqlbinlog” has printed out an error. Therefore, the solution was to discard current relay binlogs and to point slave to the last master binlog position.
This cookbook explains how to move MySQL master server to another host. Scenario in short goes: dump out master databases, import data on the new master server and point slave to the new master server. If you follow this simple steps, master migration should proceed without problems.
Small tip of how to log all queries done by the MySQL server. It is very useful if you want to preview SQL requests from WordPress, Joomla or any other system or client. After logging is enabled, server will write information to the log file when clients connect or disconnect, and it will log each SQL statement.
This post explains how to add a new slave to the existing MySQL replication. New slave server can be added to the MySQL replication without stopping master or shutting down existing slave server. You will have to temporarily stop replication on the slave server in order to take the current data snapshot.
MySQL replication can stop if slave fails to execute SQL statement from the binary log. From that moment, slave prints last error and waits for replication recovery. If master has consistent snapshot, then is only necessary to re-point slave to the new master position. It can be done with “change master to” or “sql_slave_skip_counter”.