ИМЕЕТСЯ Виртуальная машина версия 5.1.1, которая нормально работала, пока не произошел какой-то креш на серваке. Теперь Mysql не запускается с ошибкой:
НА ЭКРАНЕ: ------------------------------------------------------ Mysql connect error [localhost, 127.0.0.1]: Can't connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (2) (400) /home/bitrix/www/bitrix/modules/main/lib/db/mysqlconnection.php:50 ----------------------------------------------------
Ранее встречавшиеся ошибки - это не то. (Место хватает - проверили, файла mysqld.sock нет)
КОНФ.ФАЙЛ ----------------------------------------------------------------------------------------------- # # Basic mysql configuration. Use bvat for advanced settings. # Parameters set by bvat are stored in /etc/mysql/conf.d/bvat.cnf. # If you want to change any parameter, you'll have to redefine it in /etc/mysql/co nf.d/z_bx_custom.cnf #
[client] port = 3306 socket = /var/lib/mysqld/mysqld.sock default-character-set = utf8
# Include additional settings !includedir /etc/mysql/conf.d/ -------------------------------------------------------------------------------------
НАСТРОЙКИ ВСЕ СТАНДАРТНЫЕ КАКИМИ ОНИ БЫЛИ В ВИРТУАЛЬНОЙ МАШИНЕ 5.1.1 (2014-15 г.)
В ЛОГЕ: --------------------------------------------- /usr/libexec/mysqld[0x81bc6d9] /usr/libexec/mysqld(_Z11plugin_initPiPPci+0x9b7)[0x81c0547] /usr/libexec/mysqld[0x81376bf] /usr/libexec/mysqld(_Z11mysqld_mainiPPc+0x452)[0x813ab52] /usr/libexec/mysqld(main+0x28)[0x812fa58] /lib/libc.so.6(__libc_start_main+0xe6)[0x23cd36] /usr/libexec/mysqld[0x812f991] The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 171205 08:20:12 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended -----------------------------------------------
В Мессаджес --------------------------------------------------------- [root@portal mysql]# tail /var/log/messages Dec 5 08:51:02 portal ntpd[1690]: 0.0.0.0 c61c 0c clock_step +5.858335 s Dec 5 08:51:02 portal ntpd[1690]: 0.0.0.0 c615 05 clock_sync Dec 5 08:51:03 portal ntpd[1690]: 0.0.0.0 c618 08 no_sys_peer Dec 5 09:00:55 portal ntpd[1690]: 0.0.0.0 c613 03 spike_detect +5.846018 s Dec 5 09:03:58 portal dhclient[1408]: DHCPREQUEST on eth0 to 192.168.71.254 port 67 (xid=0x3821c24d) Dec 5 09:03:58 portal dhclient[1408]: DHCPACK from 192.168.71.254 (xid=0x3821c24d) Dec 5 09:04:01 portal dhclient[1408]: bound to 192.168.71.128 -- renewal in 695 seconds. Dec 5 09:06:34 portal ntpd[1690]: 0.0.0.0 c61c 0c clock_step +5.866029 s Dec 5 09:06:34 portal ntpd[1690]: 0.0.0.0 c614 04 freq_mode Dec 5 09:06:35 portal ntpd[1690]: 0.0.0.0 c618 08 no_sys_peer ----------------------------------------------------------------------
Короче, все плохо, люди советуют поднять БД из дампа. Я не очень понимаю, побились файлы нашей БД или самого ПО Mysql
ВНИМАНИЕ ВОПРОС, ВЕРНЕЕ 2:
1) Есть ли какой-то вариант восстановления без отката к дампу? Возможности нанять линуксоида нет, действуем сами по инструкциям, так что многого не знаем. 2) Если восстанавливаться из дампа, я планирую заодно тогда уж ПЕРЕЙТИ на VMBITRIX 7.2 Проблема в том, что дампы лежат в структуре сайта локально (а не в облаке), а как их оттуда забрать - я не знаю, перерыла справочники, знаю только как туда СКАЧАТЬ например wget-om
Есть ли у кого-то описание действий, такой чек-лист, как забрать файлы из виртуальной машины, перенести их в структуру веб-сервера на новую...? чтобы восстановиться. Сколько времени на это понадобится?
ДОПОЛНЕНИЕ Содержимое папки с данными /var/lib/mysql:
-------------------------------------- ibdata1 ib_logfile0 mysql sitemanager0 ibdata1.bak ib_logfile1 performance_schema test ibdata2.bak localhost.localdomain.err portal.err -------------------------------------- (ibdata2.bak это уже я создала)
Ну и самый простой чек - лист Делаем бэкап в папку на сайт. После окончания бэкапа - система выдаст ссылку на резервную копию.
на новой свежеразвернутой машине - заходим по ИП на сайт - говорим восстановить из копии и указываем где взять копию. Сайт с магазином на 800 000 наименований - 40 минут итого.
Анатолий написал: Делаем бэкап в папку на сайт. После окончания бэкапа - система выдаст ссылку на резервную копию.
К сожалению, не можем, ибо сайт и битрикс - не запускаются, сделать свежий резерв нет возможности. В наличии только файлы уже сделанного резерва. Я не понимаю, как их оттуда забрать можно.
Андрей Николаев написал: Нам обычно nginx + httpd + mysql рестарт помогал (причем на время рестарта nginx отключается, а все остальное просто перезагружается)
Список команд точных не подскажете? nginx ни разу не пробовала там рестартовать, только httpd и mysqld
Ваши логи не полные, а лишь последние 10 строк, что очень не информативно. 1. Покажите нам результаты выполнения
Код
df -h
и
Код
free -m
2. Предоставьте более подробные логи относящиеся к проблеме (так например в messages у вас записи более поздние, чем из mysql лога) ---- Возможно у вас проблема с битым binlog (в логах должны быть намеки на это). Если так, то можете попробовать добавить в конфиг mysql:
Mikhail Kryachek написал: 2. Предоставьте более подробные логи относящиеся к проблеме
Я прочитала, как следить за логом в реальном времени. Запустила слежение, потом команду service mysqld start, и получила следующий полный текст: (дополнение: в файле messages сообщения не обновляются при попытке запустить БД)
------------------------------------------------------------------------------------------------ 171211 11:34:25 mysqld_safe Starting mysqld daemon with databases fr om /var/lib/mysql 171211 11:34:25 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead. 171211 11:34:25 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead. 171211 11:34:25 [Note] Plugin 'FEDERATED' is disabled. 171211 11:34:25 InnoDB: The InnoDB memory heap is disabled 171211 11:34:25 InnoDB: Mutexes and rw_locks use GCC atomic builtins 171211 11:34:25 InnoDB: Compressed tables use zlib 1.2.3 171211 11:34:25 InnoDB: Using Linux native AIO 171211 11:34:25 InnoDB: Initializing buffer pool, size = 756.0M 171211 11:34:25 InnoDB: Completed initialization of buffer pool 171211 11:34:25 InnoDB: highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 13195165898 171211 11:34:25 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 13195181479 171211 11:34:25 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 171211 11:34:25 InnoDB: Assertion failure in thread 1995471728 in file trx0undo.c line 561 InnoDB: Failing assertion: free + TRX_UNDO_LOG_XA_HDR_SIZE < UNIV_PAGE_SIZE - 100 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 08:34:25 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail.
key_buffer_size=67108864 read_buffer_size=131072 max_used_connections=0 max_threads=20 thread_count=0 connection_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 232083 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0 Attempting backtrace. You can use the following information to find out wh ere mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0 thread_stack 0x20000 /usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83efa34] /usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bd89c] [0xf23400] [0xf23424] /lib/libc.so.6(gsignal+0x51)[0xafc871] /lib/libc.so.6(abort+0x17a)[0xafe14a] /usr/libexec/mysqld[0x8451069] /usr/libexec/mysqld[0x8451603] 72 73 74 75 /usr/libexec/mysqld[0x84d9b2a] /usr/libexec/mysqld[0x84db1d5] 76 /usr/libexec/mysqld[0x847825d] 77 /usr/libexec/mysqld[0x84a35dd] 78 /usr/libexec/mysqld[0x8432d10] /lib/libpthread.so.0(+0x6b39)[0x62fb39] /lib/libc.so.6(clone+0x5e)[0xbb4c2e] The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 171211 11:34:25 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended ------------------------------------------------------------------------------------------------
На binlog вроде намеков нет, поэтому применять последнюю команду не стала.
Уточнила этот вопрос. На самом серваке 32 Гб, Виртуалке было выделено 4 Гб, все эти годы хватало, на всякий случай выделила 6 Гб. Но это вообще, по-моему, далеко за глаза....))) В любом, случае, не помогло.
И еще вопрос - как исключить проблему ЖЕЛЕЗА??? Скопировать по удаленко 200 Гб портала не представляется возможным....
171211 11:34:25 InnoDB: Assertion failure in thread 1995471728 in file trx0undo.c line 561
и эту: It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 232083 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.
АПДЕЙТ: Запустилась только в режиме innodb_force_recovery = 6 !!! Пробую восстановление innodb по инструкции. Бэкап если что есть......... Теоретически должно помочь, если проблема не в железе.
171211 11:34:25 InnoDB: Assertion failure in thread 1995471728 in file trx0undo.c line 561
Если очень коротко, то у вас повреждена БД. Быстрее всего был какой-то сбой, резкое выключение сервера итд итп. И как результат БД даже не может стартануть. Попробуйте запустить в режиме восстановления https://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html со значениями от 1 до 3. Если не поможет, то процесс восставновления очень долгий и быстрее всего будет сопровождаться частичной потерей данных. Лучше найти прошлый бекап (если он есть)
Цитата
остался открытым. Если не удастся запустить этот портал, как забрать с него локальный бэкап. Как соединиться с содержимым старой машины?
По SSH подключайтесь и производите необходимые манипуляции.
Цитата
"как забрать файлы из виртуальной машины, перенести их в структуру веб-сервера на новую...? чтобы восстановиться."
Сделайте архив файлов\папок с помощью команды tar, и затем перенесите на другой сервер с помощью команды wget
Mikhail Kryachek написал: Если не поможет, то процесс восставновления очень долгий
Да, действительно, уже час прошел после команды восстановления БД, и пока нет ответа в терминале. Ошибка в браузере сменилась на Mysql select db error [sitemanager0]: Unknown database 'sitemanager0' (400) Ждем-с.
Цитата
Mikhail Kryachek написал: Сделайте архив файлов\папок с помощью команды tar, и затем перенесите на другой сервер с помощью команды wget
Архивы имеются (благо было настроено еженочное копирование), а вот как их скачать не очень понимаю. Wget же именно скачивает, а не отправляет. Даже если распакую рядом новую виртуалку, как в нее перекачать архивы, которые лежат в этой? Я планировала хотя бы как-то запустить эту, и скачать архивы, т.к они будут после запуска "онлайн" и можно будет получить ссылку для переноса, в крайнем случае, так скачать. Вообще, было бы круто иметь возможность отправить локальный файл в любое время на хранение в облако, прямо из контекстного меню. (при условии что подписка активна и место есть, конечно)
Если у вас есть доступ по SSH, то проблем никаких не должно быть. 1. Есть старая виртуалка с полумертвым MySQL и быстрее всего доменное имя привязано к ней (напр. bx.site) 2. Есть новая виртуалка или иной хостинг 3. Предположим у вас есть бекап на старой виртуалке доступный по публичному адресу http://bx.site/bitrix/backup/my-backup.tar.gz 4. Подключаетесь к новой виртуалке заходите в нужную папку и выполняете wget http://bx.site/bitrix/backup/my-backup.tar.gz и бекап будет скачен со старой виртуалки на новую.
ЗЫ. также возможно вы можете использовать локальные IP виртуалок для копирования данных, вместо публичных URL
Спасибо, мне просто в голову не приходило, что при неработающей (или даже отсутствующей) MySQL файлы все равно можно получить по публичной ссылке! Мы даже не пробовали так делать. Сейчас скачали их вручную просто, все 36 частей, а на новую загрузили с локального компа, выделив все (facepalm). Даже не пришлось разбираться с локальными сетями, адресами итд. Спасибо вам огромное за подсказку!!!