Error 1236 - "Could not find first log file name in binary log index file"

If all else fails, you may find that you need to reset the slave and restart replication. From https://www.redips.net/mysql/replication-slave-relay-log-corrupted/ :

# First note current settings (note Relay_Master_Log_File and Exec_Master_Log_Pos)
mysql> show slave status\G
# then stop slave
mysql> stop slave;
# make slave forget its replication position in the master's binary log
mysql> reset slave;
# change slave to start reading from stopped position
mysql> change master to master_log_file='mysql-bin.XXX', master_log_pos=XXX;
# start slave
mysql> start slave;

You seem to not be connecting to the master that you think you are. Per your binary logs on the master you seem to have:

#160519 3:28:59 server id 5

But per SHOW SLAVE STATUS we see:

         Master_Server_Id: 3

And further you seem to be connecting on localhost, but you implied your master/slave are on different hosts:

              Master_Host: 127.0.0.1

Update: This answer covers the general error classification. For a more specific answer about how to best handle the OP's exact query, please see other answers to this question

One of the top most critical replication error Got fatal error 1236 It can be triggered by multiple reasons, one of them is the title of this question.

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

This error occurs when the slave server required binary log for replication no longer exists on the master database server.

So many scenarios can cause this:

• The master server expired binary logs via system variable expire_logs_days (my.cnf if you set expire_logs_days old binlogs expire automatically and are removed; When MySQL opens a new binlog file, it checks the older binlogs, and purges any that are older than the value of expire_logs_days)
• Someone manually deleted binary logs from master via PURGE BINARY LOGS command or via rm -f command
• You have some cronjob which archives older binary logs to claim disk space

In order to resolve this problem, the only clean solution I can think of is to re-create the slave server from a master server backup or from other slave in replication topology.

Reference : mysql replication got fatal error