Binlog has bad magic number

Binary logs have different start positions upon the creation of a new binary log. In fact, a binary log position actual represents the numbers of bytes written in the binary at the end of the most recent SQL statement recorded.

The following is the list of binary log starting positions for each major release of MySQL 5

• For MySQL 5.5 : 120
• For MySQL 5.5 : 107
• For MySQL 5.1 : 106
• For MySQL 5.0 : 98

Included in these initial bytes is a static value called the magic number, a base-64 value. I wrote about this back on Dec 26, 2011 : mysql emits BINLOG rows even though binlog_­format=­STATEMENT

Although the BINLOG magic number is always in the same position, you cannot use binary logs from one version to newer versions under certain circumstances. For example, binary logging events could change and not be understood. Row-based binary logging and MySQL Replication can break on a MySQL 5.6 Slave replicating from an older master when handling DATETIME values. I wrote about this recently

• Jun 18, 2015 : mysql master slave replication scenario
• Jan 02, 2015 : mysql replication master 5.5 slave 5.1 error on create database

There is also the possibility of a corrupt binary log. I wrote about this on Feb 04, 2011 : MySQL master binlog corruption

Your solution is to

• net stop mysql
• Erase binary logs (and the binary log index file)
  • IF you do not know where they are, locate my.ini on your PC
  • Open my.ini in Notepad
  • look for the option log-bin or log_bin
  • look for the option datadir
  • If log-bin only has a filename, look inside the folder specified by datadir
  • If log-bin includes a path and a filename, look inside the folder specified by log-bin
  • Open the desired folder in Windows Expolrer
  • Remove the binary logs
  • There should be a file whose file extension is .index. Delete this as well
• net start mysql

Please DO NOT ERASE ib_logfile0 or ib_logfile1 when you have binary log issues.