Mariadb error 1236

If you spend all day every day looking after hundreds of MySQL servers, the chances are that you have encountered this problem. And the chances are that if your servers are configured properly (i.e. you have the same configuration on the master and the slaves), the error is almost certainly spurious and doesn’t mean what it says it means. So why does it happen? It isn’t entirely clear – it could be a consequence of a hardware glitch, in-flight data corruption in the network layer (though between TCP checksums, and binlog checksums it is vanishingly unlikely to pass through undetected), or a really difficult to reproduce MySQL bug (this happens very rarely, we see it maybe 2-3 times every year across hundreds of database servers in various different environments).

But it does happen. And when it does happen, the only way to make completely sure that the slave is sound is to re-initialize the entire data set – and that can be painful when you have terabytes of data. Of course, most of the MySQL and MariaDB database servers we look after run on ZFS with hourly or daily snapshots enabled. In those cases, we can simply roll back to the most recent snapshot before the error arose, and that almost always fixed the problem. But those who haven’t had their infrastructure

So let’s explore what you might be able to do avoid or at least postpone the slave re-initialization.

Working Through an Actual Example

For example, if it happens to you and you see this in your SHOW SLAVE STATUSG output:

      Exec_Master_Log_Pos: 123516843
    Seconds_Behind_Master: NULL
            Last_IO_Errno: 1236
            Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.140409' at 123516843, the last event read from './mysql-bin.140409' at 123, the last byte read from './mysql-bin.140409' at 123516862.'

The first thing that looks fishy is that the difference between the Exec_Master_Log_Pos and the last position read from binlog is tiny – and therefore highly unlikely to be on the scale of max_allowed_packet transaction size.

Looking at the binlog on the master, it quickly becomes obvious that both of those binlog positions are actually bogus:

mysqlbinlog mysql-bin.140409 | grep '^# at ' | grep -P 'at 12351d{4}$'at 123512938
at 123521149

So we might be able to get away with is resetting the slave replication coordinates:

STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.140409', MASTER_LOG_POS=123512938, MASTER_HOST='master-server', MASTER_USER='master-user', MASTER_PASSWORD='master-password';

Reason we go for the value before rather than the value after is because in most cases, if there is a primary key and we are using binlog_format=ROW, replication will break on a missing row (on a delete) or a duplicate key (on an INSERT), and we can skip the transaction and resume. If we go straight for the first value after the reported error, we could miss a transaction and we potentially won’t know until something breaks later on, or until we can check with pt-table-checksum – and that can take hours or days with terabytes of data.

Errors Often Cluster

Importantly – if you had a glitch like this occur, then it is clear that something is amiss. Don’t just apply this fix and assume everything else is OK on the server that was affected. At the very least run pt-table-checksum on it to make sure that the data is consistent. Servers that exhibit spurious errors rarely only do it once.

[slave]$ echo "show slave status G" | mysql | grep -E "[[:space:]]Master_Log_File|Read_Master_Log_Pos"
  Master_Log_File: s10-bin.000253
  Exec_Master_Log_Pos: 783374391

[master]$ mysqlbinlog s10-bin.000253 | tail -n 9
/*!*/;
# at 783367615
#150704 18:12:45 server id 62 end_log_pos 783367646 CRC32 0x2be04f67 Xid = 22088173
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

[slave] mysql> stop slave;
[slave] mysql> change master to master_log_pos=783367646;
[slave] mysql> start slave;

[Note] 'CHANGE MASTER TO executed'. Previous state master_host='10.10.10.10', master_port= 3306, master_log_file='s10-bin.000253', master_log_pos=783374391, master_bind=''. New state master_host='10.10.10.10', master_port= 3306, master_log_file='s10-bin.000253', master_log_pos=783367646, master_bind=''.
[Note] Slave I/O thread: connected to master 'repl@10.10.10.10:3306',replication started in log 's10-bin.000253' at position 783367646

mysql> show binlog events in 's9-bin.000125' from 24084942 limit 10;
+---------------+----------+-------------+-----------+-------------+------------------+
| Log_name      | Pos      | Event_type  | Server_id | End_log_pos | Info             |
+---------------+----------+-------------+-----------+-------------+------------------+
| s9-bin.000125 | 24084942 | Write_rows  |         8 |    24085025 | table_id: 244461 |
| s9-bin.000125 | 24085025 | Update_rows |         8 |    24086045 | table_id: 244461 |
| s9-bin.000125 | 24086045 | Write_rows  |         8 |    24086128 | table_id: 244461 |
| s9-bin.000125 | 24086128 | Update_rows |         8 |    24086518 | table_id: 244461 |
| s9-bin.000125 | 24086518 | Write_rows  |         8 |    24086600 | table_id: 244461 |
| s9-bin.000125 | 24086600 | Update_rows |         8 |    24086876 | table_id: 244461 |
| s9-bin.000125 | 24086876 | Write_rows  |         8 |    24087008 | table_id: 244461 |
| s9-bin.000125 | 24087008 | Update_rows |         8 |    24087138 | table_id: 244461 |
| s9-bin.000125 | 24087138 | Write_rows  |         8 |    24087221 | table_id: 244461 |
| s9-bin.000125 | 24087221 | Update_rows |         8 |    24087611 | table_id: 244461 |
+---------------+----------+-------------+-----------+-------------+------------------+
10 rows in set (0.00 sec)

Posted in Howto.

Tagged with mysql, репликация.

– 05.07.2015

In case your Mysql or Mariadb replication crashed with following error, here are steps we do to recover replication:

Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin.006270' at 357275228, the last event read from 'mysql-bin.006270' at 4, the last byte read from 'mysql-bin.006270' at 4.'

In our case was the root of problem crash of master server, therefore the slave didn’t finish reading of binary log and stopped replicating.
This was the state in our slave, when on master was corrupted mysql-bin.006270:

MariaDB [(none)]> show slave statusG

*************************** 1. row ***************************

               Slave_IO_State: 

                  Master_Host: xxx.xxx.xxx.xxx

                  Master_User: replicator

                  Master_Port: 3306

                Connect_Retry: 60

              Master_Log_File: mysql-bin.006270

          Read_Master_Log_Pos: 357275228

               Relay_Log_File: 2_db_la-relay-bin.009230

                Relay_Log_Pos: 196732452

        Relay_Master_Log_File: mysql-bin.006270

             Slave_IO_Running: No

            Slave_SQL_Running: Yes

              Replicate_Do_DB: 

          Replicate_Ignore_DB: 

           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: 357275190

              Relay_Log_Space: 666929161

              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 impossible position; the first event 'mysql-bin.006270' at 357275228, the last event read from 'mysql-bin.006270' at 4, the last byte read from 'mysql-bin.006270' at 4.'

               Last_SQL_Errno: 0

               Last_SQL_Error: 

  Replicate_Ignore_Server_Ids: 

             Master_Server_Id: 11

               Master_SSL_Crl: 

           Master_SSL_Crlpath: 

                   Using_Gtid: No

                  Gtid_IO_Pos: 

      Replicate_Do_Domain_Ids: 

  Replicate_Ignore_Domain_Ids: 

                Parallel_Mode: conservative

1 row in set (0.00 sec)

Solution in our case was to change master log file to next bin log file mysql-bin.006271 from position 4 and start slave again:

stop slave;

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.006271', MASTER_LOG_POS=4;

start slave;

Первоначально Написано Мухаммедом Ирфаном

Репликация MySQL является основным процессом для поддержки нескольких копий данных, и репликация является очень важным аспектом в администрировании базы данных. Чтобы синхронизировать данные между ведущим и ведомым устройствами, вам необходимо обеспечить бесперебойную передачу данных, и для этого необходимо своевременно действовать в отношении ошибок репликации, чтобы продолжить синхронизацию данных. Здесь, в группе поддержки Percona , мы часто помогаем клиентам с проблемами, связанными с репликацией. В этом посте я расскажу о самой критической ошибке кода репликации 1236, а также о причинах и способах ее устранения. Ошибка репликации MySQL « Получена фатальная ошибка 1236 » может быть вызвана несколькими причинами, и я постараюсь охватить все из них.

Last_IO_Error: Получена фатальная ошибка 1236 от мастера при чтении данных из двоичного журнала: «превышена запись в журнале событий max_allowed_packet; Увеличьте max_allowed_packet на мастере; первое событие «binlog.000201» на 5480571

Это типичная ошибка на подчиненном (ых) сервере (ах). Это отражает проблему, связанную с размером max_allowed_packet . max_allowed_packet ссылается на один оператор SQL, отправляемый на сервер MySQL как двоичное событие журнала от главного к подчиненному. Эта ошибка обычно возникает, когда у вас есть другой размер max_allowed_packet на главном и ведомом (то есть размер главного max_allowed_packet больше, чем на подчиненном сервере) . Когда главный сервер MySQL пытается отправить больший пакет, чем определено на подчиненном сервере, подчиненный сервер не может принять его и, следовательно, ошибку. Чтобы устранить эту проблему, убедитесь, что у max_allowed_packet одинаковое значение как для ведомого, так и для ведущего устройства. Вы можете прочитать больше о max_allowed_packet здесь .

Эта ошибка обычно возникает при обновлении огромного количества строк на ведущем устройстве, и она не вписывается в значение размера slave max_allowed_packet, потому что размер slave max_allowed_packet ниже, чем мастер. Обычно это происходит с запросами « LOAD DATA INFILE » или « INSERT .. SELECT ». По моему опыту, это также может быть вызвано логикой приложения, которая может генерировать огромную INSERT с ненужными данными. Примите во внимание, что одна новая переменная, представленная в MySQL 5.6.6 и более поздних версиях slave_max_allowed_packet_size, контролирует максимальный размер пакета для потоков репликации. Он переопределяет переменную max_allowed_packet на ведомом устройстве, и его значение по умолчанию составляет 1 ГБ. В этом посте, «Max_allowed_packet и повреждение двоичного журнала в MySQL», мой коллега Мигель Анхель Нието подробно объясняет эту ошибку.

Получил фатальную ошибку 1236 от мастера при чтении данных из двоичного журнала: «Не удалось найти первое имя файла журнала в двоичном файле индекса журнала»

Эта ошибка возникает, когда ведомому серверу требуется двоичный журнал для репликации, больше не существует на главном сервере базы данных. В одном из сценариев для этого ваш подчиненный сервер по какой-то причине останавливается на несколько часов / дней, и когда вы возобновляете репликацию на ведомом устройстве, происходит сбой с вышеуказанной ошибкой.

Когда вы исследуете, вы обнаружите, что главный сервер больше не запрашивает двоичные журналы, которые ведомому серверу нужно извлечь для синхронизации данных. Возможные причины этого включают двоичные журналы с истекшим сроком действия главного сервера через системную переменную expire_logs_days — или кто-то вручную удалял двоичные журналы из мастера с помощью команды PURGE BINARY LOGS или с помощью команды ‘rm -f’, или у вас может быть какой-то cronjob, который архивирует старые двоичные журналы в запрос места на диске и т. д. Итак, убедитесь, что на главном сервере всегда есть необходимые двоичные журналы, и вы можете обновить свои процедуры, чтобы сохранить двоичные журналы, необходимые для подчиненного сервера, путем мониторинга переменной « Relay_master_log_file » из SHOW SLAVE STATUSвывод. Более того, если вы установили expire_log_days в my.cnf, старые binlogs устаревают автоматически и удаляются. Это означает, что когда MySQL открывает новый файл binlog, он проверяет старые binlogs и удаляет все, которые старше, чем значение expire_logs_days (в днях). Percona Server добавил функцию для истечения срока действия журналов на основе общего количества файлов, используемых вместо возраста файлов binlog. Таким образом, в этой конфигурации, если вы получите всплеск трафика, это может привести к тому, что бинлоги исчезнут быстрее, чем вы ожидаете. Для получения дополнительной информации проверьте Ограничение количества файлов binlog .

Чтобы решить эту проблему, единственное чистое решение, которое я могу придумать, — это воссоздать подчиненный сервер из резервной копии главного сервера или из другого подчиненного в топологии репликации.

— Получена фатальная ошибка 1236 от мастера при чтении данных из двоичного журнала: ‘binlog урезан в середине события; учитывать нехватку дискового пространства на мастере; первое событие ‘mysql-bin.000525’ в 175770780, последнее событие, прочитанное из ‘/data/mysql/repl/mysql-bin.000525’ в 175770780, последний байт, прочитанный из ‘/ data / mysql / repl / mysql- bin.000525 ‘на 175771648.’

Обычно это вызвано sync_binlog <> 1 на главном сервере, что означает, что двоичные события журнала могут не синхронизироваться на диске. Может быть зафиксированный оператор SQL или изменение строки (в зависимости от формата репликации) на главном сервере, который не сделал его ведомым, потому что событие урезано. Решением было бы переместить подчиненный поток в следующий доступный двоичный журнал и инициализировать подчиненный поток с первой доступной позицией в двоичном журнале, как показано ниже:

mysql>CHANGE MASTERTOMASTER_LOG_FILE='mysql-bin.000526',MASTER_LOG_POS=4;

— [ОШИБКА] Ведомый ввод / вывод: Получена фатальная ошибка 1236 от мастера при чтении данных из двоичного журнала: «Клиент запросил мастер начать репликацию с невозможной позиции; первое событие ‘mysql-bin.010711’ в 55212580, последнее событие, прочитанное из ‘/var/lib/mysql/log/mysql-bin.000711’ в 4, последний байт, прочитанный из ‘/ var / lib / mysql / log / mysql-bin.010711 ‘на 4.’, код ошибки: 1236

Я предвижу, что главный сервер вышел из строя или перезагружен и, следовательно, события двоичного журнала не синхронизированы на диске. Обычно это происходит, когда sync_binlog! = 1 на мастере. Вы можете исследовать это как проверку содержимого двоичного журнала, как показано ниже:

$mysqlbinlog--base64-output=decode-rows--verbose--verbose--start-position=55212580mysql-bin.010711

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

mysql>CHANGE MASTER TOMASTER_LOG_FILE='mysql-bin.000712',MASTER_LOG_POS=4;

Это возобновит репликацию.

Чтобы избежать испорченных binlogs на ведущем устройстве, включение sync_binlog = 1 на главном помогает в большинстве случаев. sync_binlog = 1 будет синхронизировать двоичный журнал на диск после каждой фиксации. sync_binlog заставляет MySQL выполнять fsync в двоичном журнале в дополнение к fsync от InnoDB. Напомним, что это оказывает некоторое влияние на стоимость, поскольку он синхронизирует запись в двоичный журнал на диске после каждой фиксации. С другой стороны, накладные расходы sync_binlog = 1 могут быть очень минимальными или незначительными, если дисковая подсистема является SSD вместе с кэш-памятью с резервным питанием от батареи (BBU). Вы можете прочитать больше об этом здесь в руководстве.

sync_binlog — это динамическая опция, которую вы можете включить на лету. Вот как:

mysql-master>SET GLOBAL sync_binlog=1;

Чтобы сделать изменение постоянным при перезагрузке, вы можете добавить этот параметр в my.cnf .

В дополнение к этому, наряду с исправлениями репликации, всегда лучше убедиться, что ваша реплика находится в ведущем устройстве, и проверить данные между ведущим / ведомым устройствами. К счастью, в Percona Toolkit есть инструменты для этой цели: pt-table-checkum & pt-table-sync . Перед проверкой согласованности репликации обязательно проверьте среду репликации, а затем синхронизируйте все различия.