Если MySQL master-сервер по какой-то причине "упал", например из-за kernel panic или выключения питания, то после его запуска, вы можете увидеть на MySQL slave-сервер сообщение вида: Got fatal error 1236 from master when reading data from binary log:  'Client requested master to start replication from position > file size'. При этом команда START SLAVE работать не будет. Что же делать в такой ситуации?

Всё это означает, что бинарный лог, который у вас есть на master-сервере повреждён в результате некорректного завершения MySQL. Допустим вывод команды: SHOW SLAVE STATUS \G; на slave-сервере выглядит так:

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State:
                  Master_Host: 192.168.0.1
                  Master_User: replicator
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.004783
          Read_Master_Log_Pos: 643318915
               Relay_Log_File: db-master1-relay-bin.000747
                Relay_Log_Pos: 635452116
        Relay_Master_Log_File: mysql-bin.004783
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: information_schema,mysql,performance_schema
           Replicate_Do_Table:
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 643318915
              Relay_Log_Space: 1701816887
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from position > file size'
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 3
                  Master_UUID: 510103d3-3583-11e7-b931-00103007afb8
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp: 171128 08:35:49
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

Тогда у вас два пути:

1. Сделать дамп с master-сервера с ключём --master-data и перезалить дамп на slave-сервер. Однако, особенно на работающей системе, это не всегда возможно.
2. Пропустить проблемное место. Для этого заходим на master-сервер и ищем первую валидную позицию в указанном бинарном логе (строка подсвечена красным):

# mysqlbinlog mysql-bin.004783 | tail -n 9

видим что такое:

'/*!*/;
# at 643202777
#171128  8:25:10 server id 1  end_log_pos 643202808 CRC32 0xc7842fa3     Xid = 167808175
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

и искомую нами позицию 643202808.

Далее на slave-сервере выполняем команды:

stop slave;
change master to master_log_file='mysql-bin.004783', master_log_pos=643202808;
start slave;

После чего работа у вас восстанавливается и slave нагоняет master:

mysql> show slave status\G;
...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
...
        Seconds_Behind_Master: 0
...

Это мы сделали как бы отмотку назад, а можно сделать отмотку вперёд, т.е. выбрать следующий бинарный лог и перейти на первую валидную позицию в нём (4). Если отматывать назад, то некоторые транзакции будут пытаться накатится повторно, если вперёд, то часть транзакций будет потеряно, поэтому:

Внимание: Учтите, что при этом ваши базы на master'е и slave будут чем-то отличаться. Если это недопустимо - не применяйте данный способ!