Ошибка 1236 - «Не удалось найти первое имя файла журнала в двоичном файле индекса журнала»

10

Наша установка:

  • Мастер: MariaDB 10.0.21
  • Раб: MariaDB 10.0.17

До недавнего времени репликация работала нормально, и в этот момент ведомые БД пришлось восстанавливать из дампа. Я выполнил все необходимые действия: Дамп БД мастера, передавать дамп ведомому, уронить старые блоки данных, выполнить дамп для восстановления БД, выполнить соответствующую CHANGE MASTERкоманду, и , наконец START SLAVE.

Я получаю сообщение об ошибке: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

Первый файл журнала, который требуется ведомому от ведущего устройства, - это mysql-bin.000289. Я вижу, что это присутствует на мастере: введите описание изображения здесь

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

Все еще репликация не работает - я продолжаю получать ту же ошибку. У меня нет идей - что мне проверить дальше?

Обновлено: вывод по SHOW SLAVE STATUS\Gзапросу:

MariaDB [(none)]> SHOW SLAVE STATUS\G
--------------
SHOW SLAVE STATUS
--------------

*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 127.0.0.1
                  Master_User: replication
                  Master_Port: 1234
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000289
          Read_Master_Log_Pos: 342
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.000289
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB: xxx_yyy,xxx_zzz
          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: 342
              Relay_Log_Space: 248
              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: 'Could not find first log file name in binary log index file'
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 3
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
                   Using_Gtid: No
                  Gtid_IO_Pos: 
1 row in set (0.00 sec)

Дополнительная запрашиваемая информация:

root@master [818 18:54:22 /var/lib/mysql]# ls -l /var/lib/mysql/mysql-bin.000289
-rw-rw---- 1 mysql mysql 1074010194 May 19 03:28 /var/lib/mysql/mysql-bin.000289
root@master [819 18:54:29 /var/lib/mysql]# ls mysql-bin.00029*
mysql-bin.000290  mysql-bin.000291  mysql-bin.000292 #(Yes, it was created)
root@master [821 18:56:52 /var/lib/mysql]# mysql -uroot -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 6345382
Server version: 10.0.21-MariaDB-log MariaDB Server

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> SHOW BINARY LOGS;
+------------------+------------+
| Log_name         | File_size  |
+------------------+------------+
| mysql-bin.000279 | 1074114047 |
| mysql-bin.000280 | 1074004090 |
| mysql-bin.000281 | 1074035416 |
| mysql-bin.000282 | 1073895128 |
| mysql-bin.000283 | 1073742000 |
| mysql-bin.000284 | 1074219591 |
| mysql-bin.000285 | 1074184547 |
| mysql-bin.000286 | 1074217812 |
| mysql-bin.000287 | 1022733058 |
| mysql-bin.000288 |     265069 |
| mysql-bin.000289 | 1074010194 |
| mysql-bin.000290 | 1074200346 |
| mysql-bin.000291 |  617421886 |
| mysql-bin.000292 |     265028 |
+------------------+------------+
14 rows in set (0.00 sec)

MariaDB [(none)]> exit
Bye
root@master [821 18:57:24 /var/lib/mysql]# mysqlbinlog mysql-bin.000289 > /tmp/somefile.txt
root@master [822 18:58:13 /var/lib/mysql]# tail /tmp/somefile.txt 
# at 1074010124
#160519  3:28:59 server id 5  end_log_pos 1074010151    Xid = 417608063
COMMIT/*!*/;
# at 1074010151
#160519  3:28:59 server id 5  end_log_pos 1074010194    Rotate to mysql-bin.000290  pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@master [823 18:58:31 /var/lib/mysql]#

/etc/my.cnf.d/server.cnf (Выдержка):

# BINARY LOGGING #
log-bin                        = /var/lib/mysql/mysql-bin
expire-logs-days               = 14
sync-binlog                    = 1

Изменить: Позиция 342, кажется, существует:

root@master [826 12:15:33 /var/lib/mysql]# grep "end_log_pos 342 " /tmp/somefile.txt
#160517 14:43:13 server id 5  end_log_pos 342   Binlog checkpoint mysql-bin.000288
mysql replication mariadb rinogo
источник
Также будьте осторожны, так как ваша мастер-версия немного новее, чем ваша подчиненная. Хотя версия подчиненного может быть выше (поскольку он, несомненно, будет понимать все команды / функции / функции), если Мастер более поздний, он может вызывать то, о чем никогда не слышал Ведомый. Я подозреваю, что это не произойдет при такой незначительной разнице в ревизиях, но не может быть исключено и, несомненно, будет Чрезвычайным Арканом и его трудно найти. Также: официальная линия гласит, что более поздние версии master не поддерживаются.
TheSatinKnight

Ответы:

6

Кажется, вы не соединяетесь с мастером, которым себя считаете. Согласно вашим двоичным журналам на мастере, вы, кажется, имеете:

# 160519 3:28:59 идентификатор сервера 5

Но в соответствии с SHOW SLAVE STATUS мы видим:

         Master_Server_Id: 3

И далее вы, кажется, соединяетесь на локальном хосте, но подразумеваете, что ваш ведущий / ведомый находится на разных хостах:

              Master_Host: 127.0.0.1
Эндрю
источник
1
Мы используем SSH туннелирование (с autossh ) для локального предоставления удаленного мастера 127.0.0.1:3305. Я также заметил Master_Server_Id, но я подумал, что это был просто остаток давным-давно, когда мы использовали другой мастер. Я ожидал, что значение SHOW SLAVE STATUSбудет обновлено, как только мы полностью восстановим репликацию. Несмотря на это, это потрясающее предложение; Я проверю трижды, что мы действительно подключаемся к нужному мастеру!
Риного
1
Большое спасибо за то, что указали мне правильное направление! Мы действительно подключались не к тому хозяину. Я подтвердил это, выполнив telnet 127.0.0.1:3305- я увидел, что заявленная версия MySQL совпадает с версией старого мастера. Я думаю, что корень проблемы, вероятно, был вызван некоторыми причудами DNS в нашей сети - кажется, что соединение autossh было ошибочно установлено с domain.com, даже если оно было настроено для подключения к db.domain.com. Большое спасибо еще раз.
Риного
8

Если ничего не помогает, вы можете обнаружить, что вам нужно сбросить ведомое устройство и перезапустить репликацию. С https://www.redips.net/mysql/replication-slave-relay-log-corrupted/ :

# First note current settings
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;
Энди Беверли
источник
1
ОП прокомментировал, что другой ответ был правильным (и они подключались к неправильному экземпляру).
ypercubeᵀᴹ
3
@ yper-trollᵀᴹ - да, но половина цели Stackexchange - это архив вопросов, которые неизбежно попадают в верхнюю часть поисков Google для других людей с такой же проблемой. У меня была точно такая же проблема, и это было для меня решением (тем более, что я буквально часами пытался ее решить, потому что большинство других страниц показывают одни и те же ответы). Тот факт, что другой «неправильный» ответ имеет 2 голоса «за», свидетельствует об этом.
Энди Беверли
Да, справедливо. Пока это (предложение) предназначено для использования, когда все остальное терпит неудачу (и четко обозначено как таковое), это нормально. Вот почему я только прокомментировал, а не проголосовал.
ypercubeᵀᴹ
1
Этот ответ работал для меня, когда ни один из других советов не применялся. (Я работал над существующим текущим binlog, правильно настроил мастер и т. Д.) Это хороший ответ и, откровенно говоря, RESET SLAVE; Вариант следует упомянуть более заметно выше.
JD Болдуин
3

Сообщение об ошибке является ответом.

Посмотрите на вывод SHOW BINARY LOGSзапроса:

+------------------+------------+
| Log_name         | File_size  |
+------------------+------------+
| mysql-bin.000279 | 1074114047 |
| mysql-bin.000280 | 1074004090 |
| mysql-bin.000281 | 1074035416 |
| mysql-bin.000282 | 1073895128 |

На дисплее нет mysql-bin.000278.

Если двоичные журналы не повернуты, содержимое mysql-bin.index неверно.

Пожалуйста, сравните содержимое mysql-bin.indexс существующими файлами binlogs и убедитесь, что они совпадают. Вы можете исправить это на Мастере с

mysql> PURGE BINARY LOGS TO 'mysql-bin.000279';

потом иди к рабу и беги

mysql> STOP SLAVE; START SLAVE;

Попробуйте!

RolandoMySQLDBA
источник
Привет, Роландо! Большое спасибо за Вашу помощь! К сожалению, я все еще в замешательстве. Вы имели в виду mysql-bin.000288вместо mysql-bin.000278? Если так, mysql-bin.000288кажется, существует. Это все еще решит проблему?
Риного
PURGE BINARY LOGS TO 'mysql-bin.000279';дал мне ошибку (как и следовало ожидать), так как журнал "279" больше не существует (был свернут). PURGE BINARY LOGS TO 'mysql-bin.000288';успешно выполнен и удалил все двоичные журналы до "288". К сожалению, я все еще получаю ошибку.
Риного
Большое спасибо за ваши подробные предложения, Роландо! Проблема закончилась тем, что мы подключались не к тому хозяину ( dba.stackexchange.com/a/140259/55530 ).
Риного
2

Обновление: этот ответ охватывает общую классификацию ошибок. Чтобы получить более конкретный ответ о том, как лучше всего обрабатывать точный запрос ОП, см. Другие ответы на этот вопрос.

Одна из самых критических ошибок репликации. Получена фатальная ошибка 1236. Она может быть вызвана несколькими причинами, одна из которых - заголовок этого вопроса.

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

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

Так много сценариев может вызвать это:

  • Бинарные журналы главного сервера с истекшим сроком действия через системную переменную expire_logs_days(my.cnf, если вы установили expire_logs_daysстарые binlogs, автоматически устаревают и удаляются; когда MySQL открывает новый файл binlog, он проверяет старые binlogs и удаляет все, которые старше, чем значение expire_logs_days)
  • Кто-то вручную удалил двоичные журналы из мастера с помощью PURGE BINARY LOGSкоманды или с помощью rm -fкоманды
  • У вас есть кое- cronjobчто, что архивирует старые двоичные журналы, чтобы занять место на диске

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

Ссылка: MySQL репликация получила фатальную ошибку

AnouarZ
источник