LINUX.ORG.RU
ФорумAdmin

Не стартует Mysql сервер

 ,


0

1

Всем привет!
На VDS debian-11 установлена MySQL / MariaDB 8.0.32
На хостинге был системный сбой и VDS был недоступен где-то полчаса. Потом хостер сообщил, что у нас был сбой, извините мол, сейчас все работает.
Дело в том, что после сбоя не стартует MySQL.
В логах такая ошибка:

2023-06-15T13:33:19.021403Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: log0recv.cc:2088:!page || page_is_comp(page) == dict_table_is_comp(index->table) thread 140199409481472
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/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2023-06-15T13:33:19Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=c05eb91946dbbf14ed54aaf68c1facd05f3e65ac
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x5602ea1c942d]
/usr/sbin/mysqld(print_fatal_signal(int)+0x393) [0x5602e909eec3]
/usr/sbin/mysqld(my_server_abort()+0x7e) [0x5602e909f00e]
/usr/sbin/mysqld(my_abort()+0xa) [0x5602ea1c34ea]
/usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x336) [0x5602ea4b24a6]
/usr/sbin/mysqld(+0x242268b) [0x5602ea38868b]
/usr/sbin/mysqld(recv_recover_page_func(bool, buf_block_t*)+0x68b) [0x5602ea38b90b]
/usr/sbin/mysqld(buf_page_io_complete(buf_page_t*, bool)+0x39f) [0x5602ea5197df]
/usr/sbin/mysqld(fil_aio_wait(unsigned long)+0x1a6) [0x5602ea618b76]
/usr/sbin/mysqld(+0x24f5520) [0x5602ea45b520]
/usr/sbin/mysqld(std::thread::_State_impl<std::thread::_Invoker<std::tuple<Detached_thread, void (*)(unsigned long), unsigned long> > >::_M_run()+0xae) [0x5602ea45c0ee]
/lib/x86_64-linux-gnu/libstdc++.so.6(+0xceed0) [0x7f82c121bed0]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7ea7) [0x7f82c1327ea7]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f82c0f16a2f]
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.
После поиска по интернету нашел описание ошибки здесь. Тут чувак пишет, что надо делать.
Я не рискую делать то, что он пишет, потому что боюсь что то запороть, да и дампа у меня нет (а там он пишет, что нужен дамп).
Подскажите пожалуста на простом языке, как мне исправить данную ошибку, типа:
1. Пропиши в конфиге
[mysqld]
innodb_force_recovery = 1
ну а дальше что делать? Дампа у меня нет (не делал).

Ответ на: комментарий от emorozov

К слову, это можно сделать без транзакций, например так:

UPDATE account SET amount=amount+100 WHERE account_id=345 AND amount=100

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

С другой стороны, ты не уточил задачу. Если уточнить, может быть можно будет изменить реализацию на более эффективную.

И прошу, не надо это моё сообщение записывать в «призывал использовать эмулятор транзакций вместо настоящих транзакций».

firkax ★★★★★
()
Ответ на: комментарий от anc

Ну, в зависимости от задачи. Может нужно другие поля проверять а может наоборот лучше не надо. Да и amount может там и не строгое равенство amount=100 должно быть а например amount+100<=max_amount.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Реальность: юникод большинству был нафиг не нужен; 8-бит кодировки прекрасно справлялись со своей задачей - представлять все значимые международные символы (латинский алфафит, цифры и знаки препинания), алфавит своего языка (у нас - кириллица, в европе - некоторые добавочные к латинице символы) и немножко других знаков, каким хватило места (проблемы могли быть разве что у китайцеподобных с их иероглифами, но на них всем было пофиг).

Ну вот даже не буду снова комментировать. Ты живёшь видимо в очень узком мирке, где, например, никогда не требовалось писать/обрабатывать тексты одновременно на руссокм и немецком, русском и испанском.

Не говоря уж о том, что неполиткорректный выпад в сторону «ненужных китайцеподобных» сразу же отбрасывает более половины населения Земли.

А вот магазин еды, даже без юникода, без транзакций и вообще изучая php/sql методом тыка и поставив апач+modphp по гайду 20-летней давности - вполне можно. Думаю что некоторые так и делали некоторое время назад (сейчас популярнее поставить готовый уже в каком-нить докере).

Да, я как-то году в 2008-2010 разбирал базу такого магазина. Попросили, потому что сами перестали понимать, кто за что платил, и когда.

Полез в базу - ни одного внешнего ключа, ни одного констрейнта, всё пишется кто в лес, кто по дрова.

90% записей привёл в порядок скриптами, оставшиеся 10% пришлось разбирать вручную, а потом вообще переписал эту херню целиком.

Молодой был, сил и времени много… Сейчас сразу бы сказал: «Ищите тех, кто это писал, и снимайте с них шкуру.»

emorozov
()
Ответ на: комментарий от firkax

Ни разу не видел.

Так у тебя и база скорее всего на пару пользовалей размером в 100 мб и запросами раз в десять минут.

И чем это грозит для стандартного пхп-веба

Я не знаю что такое «стандартный пхп-веб», если на этом «пхп-вебе» написан интернет-магазин, то ты легко можешь «проиграть» оплаченные заказы. Хотя если честно я уже лет 12 не видел в вебе где только php-mysql. Сейчас веб намного сложнее.

А давай у автора спросим, что он предпочтёт

А ты не прячься за автора. Твое сообщение прочитает огромное количество людей. И возможно найдутся те, кто последует твоему совету, не зная к чему это ведет.

adn ★★★★
()
Ответ на: комментарий от emorozov

Ну вот даже не буду снова комментировать. Ты живёшь видимо в очень узком мирке, где, например, никогда не требовалось писать/обрабатывать тексты одновременно на руссокм и немецком, русском и испанском.

Опять перевирание. Слова «большинству» и «был» ты пропустил. То, что я ничего не писал лично про себя вообще - тоже типа не заметил. Возможно ещё пропустил (но тут я не уверен) что речь была про веб, а конкретно про пхп. Да, представь себе, большинству не нужно одновременно писать что-то на одной странице сайта на трёх языках. Даже сейчас. А редкие юникодные символы можно вставить через html-entities. А ещё, пхп писали не китайцы, хотя они и тоже пользовались им.

Да, я как-то году в 2008-2010 разбирал базу такого магазина

Ну это ты видел что там ужас внутри, а для хозяев магазина это «сайт глючит, найдём программиста чтоб починил». Покуда эти расходы не перевешивают альтернативные - так и делали. И причём смотри - их беспокоило что они не видят нормально прохождение оплат. Думаю, это была далеко не единственная там проблема, но на всё остальное им было закономерно плевать. И если б кто-то предложил им прикостылить фикс только оплат задёшево - думаю согласились бы.

firkax ★★★★★
()
Ответ на: комментарий от adn

Так у тебя и база скорее всего на пару пользовалей размером в 100 мб и запросами раз в десять минут.

Да нет, побольше. Но ты не понял: myisam впринципе не может ругаться на заблокированные таблицы. Он просто ждёт пока они разлочатся, хоть час, хоть месяц.

Я не знаю что такое «стандартный пхп-веб», если на этом «пхп-вебе» написан интернет-магазин, то ты легко можешь «проиграть» оплаченные заказы

Ну вот финансово-ответственные аспекты это отдельная история, для них и правда крайне желательно ничего не терять. Но для этого можно устроить всё это для конкретных финансово-ответственных таблиц, и не ограничиваться acid-базами, а ещё например страховочные письма себе на почту слать, если надёжность хостинга и прочего вызывает сомнения. А у крупных компаний (у кого есть своя бухгалтерия), вообще оформленные заказы обычно отсылаются в неё, и уже хранятся в бухгалтерских базах (+бумажках), а на сайте в лучшем случае зеркало, или же вообще «заказ оформлен, дальше узнавайте по телефону». Всякие же комментарии к товарам и прочее подобное можно хранить всё так же абы как.

А ты не прячься за автора. Твое сообщение прочитает огромное количество людей. И возможно найдутся те, кто последует твоему совету, не зная к чему это ведет.

Ну ладно, есть небольшая вероятность что кто-то себе что-то так нарушит. Хотя она очень мала. Особенно если учитывать сколько тут пришло вполне ожидаемых возражений в ответ - вряд ли он бездумно кинется исполнять именно мой совет. С другой стороны, типичный представитель пользователей mysql, который хочет просто сделать чтоб запустилось, скорее всего разделяет желания автора.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Слушай, ты живешь в парадигме начала 2000х. Современный web - это миллионы пользователей, которым надо отдать только их уникальный контент + api для роботов и интеграции с другими ресурсами.

Какая еще бухгалтерия и e-mail’ы?

И еще утверждаешь что в этой же парадигме живут 99.99%. Как так то? Ты совсем не умеешь в аналитику?

adn ★★★★
()
Ответ на: комментарий от adn

Какая еще бухгалтерия

У не совсем мелких компаний обычно есть бухгалтерский отдел, через который проходят заказы. Они ещё и физические бумажки любят кроме всего прочего, можешь вешать ярлык «парадигма 1980х».

и e-mail’ы?

В качестве страховки к ненадёжному коду вполне норм.

Современный web - это миллионы пользователей, которым надо отдать только их уникальный контент + api для роботов и интеграции с другими ресурсами.

Это у крупных сайтов так. А у мелких нет ни миллионов пользователей, ни средств на нормальный сайт. Но самих этих мелких полно (и опять упомяну автора темы, скорее всего). Повторю ещё раз - всякие яндексы и подобные без этой темы и моих советов разберутся как им настраивать (да что настраивать, разрабатывать) базу, им это не адресуется.

99.99%

Ну и опять подгонка фактов. Я такого не писал. Я писал, во-первых, 99% (это важно, т.к. остаётся не 0.01% а целый 1% на серьёзные проекты - в 100 раз больше, а во-вторых то была чуть другая тема, хоть и смежная).

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

Никогда такого не было, и вот опять развалившаяся innodb и крашащийся сервер без внятной диагностики. То ли дело myisam где repair table бы всё исправил в автоматическом режиме.

А зачем вы вообще пользуетесь такой базой, где надо выбирать между крашами и отсутвием базового функционала? Постгрес-бояре на это всё смотрят с лёгким недоумением. У меня постгрес на каком только мусоре не работал, как только его не крашили и не стопали. Видел, как в кубере сотни рестартов было, т.к. память по лимитам слишком зарезали и там процессы каждые несколько минут прибивал оомкиллер. Лет 15 наверное на всех проектах выбраю постгрес вообще не думая. И ни разу ничего даже близко не разваливалось, всё просто работает само по себе, на всех операционках, от Windows какой-то древней, до упомянутого кубера.

Ну а если захочется «WEB SCALE», то можно органично перелезть в какой-то момент на кокрочдб и скалироваться на произвольное число нод.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 3)
Ответ на: комментарий от vbr

Постгрес-бояре на это всё смотрят с лёгким недоумением.

Да, постгрес наверно получше будет. Но в вебе принято mysql/форки, и вобщем-то обычно выбор делает кто-то другой и давно, а переход это весьма муторное мероприятие, которое обычно не одобряется.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Но в вебе принято mysql/форки

С чего бы это? Есть какие-то пруфы?

Уже много лет ни в одном современном руководстве, ни в одной книге, ни в одном курсе, MySQL даже не упоминается.

Да и вокруг вижу, что при начале разработки нового сервиса, когда стоит вопрос о выборе реляционной СУБД, MySQL (и форков) даже в рассмотрении не будет.

emorozov
()
Ответ на: комментарий от firkax

Они ещё и физические бумажки любят кроме всего прочего, можешь вешать ярлык «парадигма 1980х».

Вы возможно не поверите, но бумажки имхо любят все, от мелких до крупных компаний. Разница только в требованиях бумажек, мелкие «нам нужно... и потерпят какое-то время...» крупные «нам нужно вчера и не имеет».

anc ★★★★★
()
Ответ на: комментарий от emorozov

Уже много лет ни в одном современном руководстве, ни в одной книге, ни в одном курсе, MySQL даже не упоминается.

Я ввёл в яндекс «как установить php сервер», первая строка - официальный сайт пхп, вторая - какой-то переводной гайд с намёками на WAMP, третья - гайд как установить LAMP, в чётвёртой mysql (сервер) упоминается как почти зависимость пхп, пятый - статья с хабра 2017 года, mysql сам по себе там не упоминается, но в рекомендуемом ./configure для сборки пхп присутствует. Шестая - WAMP, седьмая - LAMP (на ubuntu 20, т.е. статья новая), и только восьмая без mysql (но всё так же с апачем). Надо ли уточнять, что ни на одной из этих страниц ни слова про postgres.

Ввёл «как установить веб сервер». 1 - WAMP, 2 - чисто апач, в конце ссылка на LAMP как на более продвинутый вариант, 3 - статья с хабра 2018 года, LAMP, 4 - чисто апач, дальше кажется тоже.

Ну и проекты которые тянутся с давних времён.

Да и вокруг вижу, что при начале разработки нового сервиса, когда стоит вопрос о выборе реляционной СУБД, MySQL (и форков) даже в рассмотрении не будет.

У тебя выборка не репрезентативная наверно, у тебя всякие серьёзные ит, а их мало.

firkax ★★★★★
()
Ответ на: комментарий от firkax

обычно есть бухгалтерский отдел, через который проходят заказы

правильно, но даже в России бумажки не являются основой и все заказы и проводки изначально живут в базе данных

В качестве страховки к ненадёжному коду вполне норм.

ага, даже при нескольких сотнях продаж в день - это трындец. Интересно как ты это будешь загружать потом в базу из которой вытаскивает заказы какая-нибудь 1c?

А у мелких нет ни миллионов пользователей, ни средств на нормальный сайт

Правильно, поэтому они пользуются чужими площадками или соц. сетями. Сайт на какой-нибудь тильде ничем не отличается по виду от того что раньше делали на wordpress, но тебе не нужно ничего ставить, настраивать и администрировать.

Про торговые площадки я вообще молчу

Я такого не писал. Я писал, во-первых, 99%

Да не важно. Нет больше веба 2000-х. Кончился. Нет уже никаких массовых LAMP для homepage.

adn ★★★★
()
Ответ на: комментарий от emorozov

Но в вебе принято mysql/форки

С чего бы это? Есть какие-то пруфы?

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

Для новых проектов да, обычно PostgreSQL выбирают.

gruy ★★★★★
()
Ответ на: комментарий от adn

ага, даже при нескольких сотнях продаж в день - это трындец. Интересно как ты это будешь загружать потом в базу из которой вытаскивает заказы какая-нибудь 1c?

Никак, почта не для этого. А для того, чтобы когда позвонит недовольный клиент «куда дели мой оплаченный заказ» менеджер вручную проверил почти и внёс его на сайт, если его там почему-то нет.

Правильно, поэтому они пользуются чужими площадками или соц. сетями

Да, есть такое. Но такие и вопросами какую базу поставить не озадачиваются, так что сразу выкидываем их из рассмотрения (сколько бы их ни было в %) и рассматриваем только тех кто остался.

Да не важно. Нет больше веба 2000-х. Кончился. Нет уже никаких массовых LAMP для homepage.

Массовых может и нет, но всё же их много.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Никак, почта не для этого. А для того, чтобы когда позвонит недовольный клиент «куда дели мой оплаченный заказ» менеджер вручную проверил почти и внёс его на сайт

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

рассматриваем только тех кто остался.

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

adn ★★★★
()
Ответ на: комментарий от firkax

Тем не менее это способ которым делают сайты нубы, которые первый раз этим занялись

Не в двадцатых годах двадцать первого века. Современные нубы хреначат сайты на react’е с бэкендом на nodejs (или golang) с redis’ом для общения между воркерами и mongodb для хранения данных.

adn ★★★★
()