> For the complete documentation index, see [llms.txt](https://mariadb.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mariadb.com/docs/server/reference/error-codes/mariadb-error-codes-1200-to-1299/e1236.md).

# Error 1236: Got fatal error from master when reading data from binary log

| Error Code | SQLSTATE | Error                                     | Description                                                            |
| ---------- | -------- | ----------------------------------------- | ---------------------------------------------------------------------- |
| 1236       | HY000    | ER\_MASTER\_FATAL\_ERROR\_READING\_BINLOG | Got fatal error %d from master when reading data from binary log: '%s' |

## Possible Causes and Solutions

The primary couldn't send the binary log events that the replica asked for. The replica's I/O thread stops, and [SHOW REPLICA STATUS](/docs/server/reference/sql-statements/administrative-sql-statements/show/show-replica-status.md) shows the error as `Last_IO_Error`. The text in quotes, sent by the primary, tells you the cause.

**The binary logs the replica needs were purged.** The primary removed them, with [PURGE BINARY LOGS](/docs/server/reference/sql-statements/administrative-sql-statements/purge-binary-logs.md) or automatically after [binlog\_expire\_logs\_seconds](/docs/server/ha-and-performance/standard-replication/replication-and-binary-log-system-variables.md#binlog_expire_logs_seconds), before the replica read them. This happens when a replica was stopped or lagged for a long time:

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

With [GTID](/docs/server/ha-and-performance/standard-replication/gtid.md) replication, the same case reads:

```
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find GTID state requested by slave in any binlog files. Probably the slave state is too old and required binlog files have been purged.'
```

The events are gone, so the replica can't catch up from this primary. Set it up again from a fresh copy of the primary, for example with [mariadb-backup](/docs/server/server-usage/backup-and-restore/mariadb-backup/setting-up-a-replica-with-mariadb-backup.md). To prevent this, keep binary logs longer than a replica can be down or behind.

**The replica asks for a GTID the primary doesn't have.** The replica's [gtid\_slave\_pos](/docs/server/ha-and-performance/standard-replication/gtid/gtid-system-variables.md#gtid_slave_pos) is wrong, or the replica executed transactions of its own:

```
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Error: connecting slave requested to start from GTID 0-1-9999, which is not in the master's binlog'
```

If the message adds `it probably means that the slave has diverged due to executing extra erroneous transactions`, the replica has transactions that the primary doesn't have. Compare `@@gtid_slave_pos` on the replica with `@@gtid_binlog_pos` on the primary. If the replica's data matches the primary, set `gtid_slave_pos` to the right position. Otherwise, set the replica up again.

**An event is larger than max\_allowed\_packet.** The message is `log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master`. Raise [max\_allowed\_packet](/docs/server/server-management/variables-and-modes/server-system-variables.md#max_allowed_packet) on the primary, and [slave\_max\_allowed\_packet](/docs/server/ha-and-performance/standard-replication/replication-and-binary-log-system-variables.md#slave_max_allowed_packet) on the replica, to more than the largest event.

**The binary log is damaged.** Messages such as `binlog truncated in the middle of event; consider out of disk space on master`, `bogus data in log event` or `event read from binlog did not pass crc check` mean that the primary can't read its own binary log, for example after a crash or a full disk. Check the file with [mariadb-binlog](/docs/server/clients-and-utilities/logging-tools/mariadb-binlog.md). If the events after the damage are lost, set the replica up again.

After fixing the cause, start the replica with `START REPLICA`.

<sub>*This page is licensed: CC BY-SA / Gnu FDL*</sub>

{% @marketo/form formId="4316" %}