MySQL fatal error 1236

MySQL error message when attempting to start a replication slave:

Got fatal error 1236: ‘Could not find first log file name in binary log index file’ from master when reading data from binary log

I banged my head against a wall for a short period of time trying resolve this one. The resolution is easy, but I didn’t find it in my searching. Hopefully this will allow someone to move forward more quickly than I did, providing I am not the only one that didn’t immediately realize what was going on. The full error reads something like:

060903 11:01:58 [Note] Slave SQL thread initialized, starting replication in log '/var/mysql/logs/mysql-log.000125' at position 97277001, relay log './slave-relay-bin.000001' position: 4
060903 11:01:58 [Note] Slave I/O thread: connected to master 'slave@master:3306', replication started in log '/var/mysql/logs/mysql-log.000125' at position 97277001
060903 11:01:58 [ERROR] Error reading packet from server: Could not find first log file name in binary log index file ( server_errno=1236)
060903 11:01:58 [ERROR] Got fatal error 1236: 'Could not find first log file name in binary log index file' from master when reading data from binary log
060903 11:01:58 [Note] Slave I/O thread exiting, read up to log '/var/mysql/logs/mysql-log.000125', position 97277001

The slave was being started from an InnoDB Hot Backup created on the master. After restoring the backup and starting up MySQL, the following binlog position was reported:

InnoDB: Last MySQL binlog file position 0 97277001, file name /var/mysql/logs/mysql-log.000125

which suggests the change master statement:

CHANGE MASTER TO
MASTER_HOST='master',
MASTER_USER='slave',
MASTER_LOG_FILE='/var/mysql/logs/mysql-log.000125',
MASTER_LOG_POS=97277001;

However, the full path to the log file is what causes the ‘Could not find first log file name in binary log index file’ error. MySQL looks for the log file in the defined log directory, /var/mysql/logs in this case. Simply adjusting the change master statement:

CHANGE MASTER TO
MASTER_HOST='master',
MASTER_USER='slave',
MASTER_LOG_FILE='mysql-log.000125',
MASTER_LOG_POS=97277001;

results in:

060903 11:15:16 [Note] Slave SQL thread initialized, starting replication in log 'mysql-log.000125' at position 97277001, relay log './slave-relay-bin.000001' position: 4
060903 11:15:16 [Note] Slave I/O thread: connected to master 'slave@master:3306', replication started in log 'mysql-log.000125' at position 97277001

And we’re replicating. Maybe if I had more occasion to bring up new MySQL replication slaves, this would have been obvious.

Moving to OS X Mail app

Since moving over to the dark side last year (using a PowerBook as my primary laptop), I’ve still kept Thunderbird as my primary email client, having used it on Windows since its first release. But at some point, it seems Thunderbird stops learning when I mark a message as junk. No matter how many times I tell it a piece of mail is junk, a duplicate of that shows up in my Inbox. I tried the default OS X Mail app when I first switched to Mac, but didn’t like the way it treated my two primary IMAP accounts differently. One would put all the folders under the Inbox folder, and the other kept all the folders outside the Inbox in a separate heirarchy. However, I just realized why, and now I think OS X Mail app might work for me.

I decided to try to live with the difference between the way the two IMAP accounts were handled, and give Mail.app a shot at handling junk mail. After a couple days, I rarely receive the same piece of junk mail twice. Only problem is I keep seeing the error “This message could not be saved” when editing a new message. I assumed that it was trying to auto-save a draft, but I haven’t been too concerned and was content to ignore the message a few times, not wanting to break the flow of whatever I was doing at the time. Then I noticed that my sent mail was not being saved. A quick search found a few references to this error in relation to the Cyrus IMAP server. The suggested fix is to set the “IMAP Path Prefix” in the Advanced tab under Accounts preference settings to “INBOX”. I wasn’t 100% sure the server was Cyrus, but gave it a shot.

Not only did this fix my error, but now my two IMAP accounts are handled the same in Mail.app. The top level Inbox has a subfolder for each IMAP account, as do the top level Drafts, Sent and Trash folders. All the other folders are under a separate top level folder for each account. Very cool. Checking for new mail now requires looking in two folders right next to each other (under the top level Inbox), rather than scrolling through a bunch of folders from one account to get to the Inbox for the other. And now that I’ve got Mail.app hooked into Growl notifications, my email experience has improved for the first time in years.

It’s the little things in life that make a difference. While I’m mucking about in preferences, might as well set up a rule to highlight email from the CEO.