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
ну а дальше что делать? Дампа у меня нет (не делал).

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

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

А когда починишь можно сделать везде alter table engine=myisam чтобы в будущем не было этой возни после сбоев.

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

Во многих манах пишут, что надо поочередно увеличивать innodb_force_recovery с 1 до 6 и пытаться запустить Mysql сервер.
Но дальше непонятно, что делать?
Предположим я запустил с innodb_force_recovery равным 1 или 2.
Потом что?
Заново сделать дампы всех баз данных, потом переустановить Mysql сервер и восстановить все дампы.
Правильно? Или как то по другому?

rafaello
() автор топика

Данные вы уже потеряли. Вопрос в том, критичные это данные или нет. Если у вас есть механизм проверки логической целостности БД - проверяйте (именно логики, например у всех заказов есть клиенты, сумма позиций в заказе соответствует общей сумме заказа и т.д.). Если такого механизма нет - принимайте решение самостоятельно, форум за вас точно не решит.

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

В данном случае речь была о статистике тем на лоре: за время наверно десяти тем о том, что делать с рассыпавшейся innodb - ни одной про myisam. Ну и из того что я видел - так это то, что видел myisam на ненадёжно работающем железе и ни разу с ними ничего фатального не случилось. Да, могли потеряться какие-то отдельные строчки (в основном - из недавно записанных), но всё остальное после repair всегда чинилось и не требовало более никакого внимания.

Полноценной статистики по мировой практике их поломок - нет.

В что 2009 случилось? Мне кажется эта агитация за innodb не единомоментно случилась.

мыши так и грызут кактус

Но грызут, да. Впрочем такое состояние дел много где.

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

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

Может, хватит настолько упоротым на ЛОР ходить?

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

Может аргументы приведёшь? Ни разу ничего кроме теоретизирований (про ненужный в 99% случаев acid и про якобы устойчивость к сбоям которую мы в очередной раз наглядно видим) от сторонников innodb не видел.

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

То есть кроме перехода на личности и навешивания ярлыков

Ты шизофреник что ли? Где ты увидел в фразе «у тебя весь мир - локалхост», логически вытекающей из тезиса «про ненужный в 99% случаев acid и про якобы устойчивость к сбоям» переход на личности и навешивание ярлыков?

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

Ярлык это «локалхост». Та моя фраза касалась 99% применений mysql-клонов вообще, а не «у меня». Я б не спорил, если б ты сказал «почти весь мир - веб» (в применении к mysql-клонам). Будешь спорить что подавляющему большинству сайтов (включая лор) acid не нужен? Если будешь, то объясни зачем он например на лоре.

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

Та моя фраза касалась 99% применений mysql-клонов вообще

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

Тебе не буду.

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

Во многих манах пишут, что надо поочередно увеличивать innodb_force_recovery с 1 до 6 и пытаться запустить Mysql сервер. Но дальше непонятно, что делать?

Дальше дампить, убирать настройку и перезапускаться. Целостность данных после рекавери - отдельный вопрос, см. комментарий @Bloody

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

Ну что за понты дурацкие?

Во-первых, у innodb в плане нагрузок всё наоборот хуже чем у myisam, единственное что ему частично помогает так это построчные блокировки на запись. Но - частично, где-то помогают а где-то наоборот вредят, в зависимости от статистики update/select-ов.

Во-вторых, сколько в инете сайтов с теми нагрузками, которые ты не классифицируешь как локалхостовые? Это сайты уровня яндекса, авито и подобных? (но хабр наверно всё же ещё локалхостовый). Видимо, доля этих сайтов где-нить 0.001%, и у них определённо особые условия для работы всех их баз. И всё это не имеет никакого отношения к остальным 99.999+%, которые поставили себе этот многострадальный innodb либо потому что прочли где-то что это модно, либо потому что за них это выбрали авторы используемых ими инструментов.

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

Ну что за понты дурацкие?

Никаких понтов, я много раз уже читал твои когнитивные искажения вида «апач не нужен, есть nginx. innodb не нужна, есть myisam», вот добавилось ещё и «acid не нужен». Судя по косвенным признакам, ты уже не чёрно-белый школяр, Однако мышление сугубо чёрно-белое, значит, закостенел (или забронзовел, как вариант) и не принимаешь никакую ТЗ кроме своей => писать любые доводы тебе бессмысленно, поэтому «тебе не буду», потому-что не хочу. Так понятнее?

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

А ты не думал что это ты мои фразы так интерпретируешь? Они между прочим про вполне конкретных «пользователей» были, а ты без спросу их обобщил на всё вокруг и недоволен. Да и даже когда я прямым текстом указываю, что не «не нужен» а «не нужен в 99% случаев» - то это уточнение ты почему-то пропускаешь мимо, дабы выставить меня источником излишне категоричных фраз. 99% в данном случае было не художественным приёмом, а реальной оценкой: как минимум столько имеется всяких гостевух/форумов/блогов/каталогов товаров с посещаемостью меньше 100к просмотров в сутки, и главная цель у них - чтоб само работало и не требовало ручных технических вмешательств (пока не взломают - тогда придётся нанимать кого-нить, хотя я видел один магазин компьютерного оборудования, где в описаниях товаров были следы битых вирусных вставок, портящих вид сайта, и даже это не мешало ему быть коммерчески успешным). И при этом им однозначно глубоко плевать на то, что из-за какого-нить краша (софта или железа) или планового хостерского перезапуска методом kill -9 пропадёт 5 недавних комментов к чему-нить. Или даже 5 зарегеных юзеров. Если в старых mysql эти check/repair table надо было вводить вручную, то в современных версиях в дефолтной установке даже этого не надо: сервер сам делает check/repair когда натыкается на незакрытую таблицу. Что может быть лучше для указанных 99% потребителей? Ни на что это они в здравом рассудке не променяют, если им объяснить ситуацию.

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

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

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

с апачем и нжениксом просто смешно

Там смешон не сам совет, т.е. ну, нжынс действительно обычно предпочтительнее. Но ржака в том, что чувак основывается на каких-то тестах пятнадцатилетней давности, сравнительно недавно вообще узнал про существование event mpm, размахивает боярскими доводами типа «апач старый» и незабвенной ПАРАДИГМОЙ, которуя лично я планирую таскать во все треды до тепловой смерти вселенной, потому что это дико смешно.

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

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

Блин, не могу молчать, ну как это вообще возможно: пишешь в одном треде «апач - легаси из девяностых, и поэтому он фу», переходишь в соседний тред и пишешь «муисам ftw». И никакая лампочка в голове не загорается, типа эээ погоди-ка.

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

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

Да и даже когда я прямым текстом указываю, что не «не нужен» а «не нужен в 99% случаев»

а реальной оценкой: как минимум столько имеется всяких гостевух/форумов/блогов/каталогов товаров с посещаемостью меньше 100к просмотров в сутки

Дяденька, выйдите из своей вэб подсобки в реальный мир, вы возможно будете очень удивлены тем фактом, что субд используют не только в вэбе. И субд это не только create table t1( f1 bigint, f2 varchar(100500), f3 timestamp, f4 varchar(500100), f5 float, ... f2000 double);

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

Устраивает, и более того.

И вот боюсь оговорить человека, но кажется мне, что это именно он топил за четвертую версию пыха, как за самую кошерную.

Ну вот например.

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

Читай беседу, об этом было. Ну ладно, повторю: подавляющее большинство инсталляций mysql - именно веб. И у автора этой темы тоже веб, я в этом практически полностью уверен. Спросим у него или не споришь?

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

подавляющее большинство инсталляций mysql - именно веб.

Откуда дровишки?

И у автора этой темы тоже веб, я в этом практически полностью уверен. Спросим у него или не споришь?

Вторую часть моего сообщения вы благополучно проигнорировали. ЧТД.

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

Нет, не топил. Я мог писал другое, что можно, читая наискосок как обычно, спутать с этим утверждением: во-первых, к четвёртой версии уже вполне сформировались ключевые положительные свойства пхп, во-вторых, стиль кода у современных пхп-кодеров представляет из себя вредный джава-карго-культ, и это облегчается благодаря последним нововведениям (но никто не заставляет). С другой стороны, были и улучшения (без них вполне можно было бы обойтись, но с ними лучше) как языка так и ядра интерпретатора, и выкидывания вредного легаси (типа register_globals,magic_quotes итд), которое провоцировало других плохих кодеров (не тех, которые джава-каргокультисты) писать свой плохой код в стиле пхп3.

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

Откуда дровишки?

А вот найди статистику и посмотрим.

Вторую часть моего сообщения вы благополучно проигнорировали. ЧТД.

Что я проигнорировал, что там надо было отвечать? Я в курсе что субд умеет не только хранить таблицы.

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

Откуда дровишки?

А вот найди статистику и посмотрим.

Ясно. Ку-ка-ре-ку.

Что я проигнорировал, что там надо было отвечать? Я в курсе что субд умеет не только хранить таблицы.

Ясно II. Намек был не на это.

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

А вот найди статистику и посмотрим.

Заинтриговал, погуглил. Никакой статистики нет, как я и предполагал. Есть цифры торчащих жопой в интернет инстансов - всего 4 миллиона и некая экспертная оценка, что это 2/3 всех инсталляций. По моим ощущениям - это ложь, а экспертная оценка уровня твоей болезни. А уж по категориям использования вообще сложно судить. Тем более, что один инстанс может обслуживать неограниченное количество применений. И это все еще надо взвешивать с альтернативныеми решениями типа постгреса, марии, фаера и скулайта. Скулайт, навскидку, гораздо опережает вообще все клиент-серверные решения и относительно редко используется в вебе.

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

Заинтриговал, погуглил. Никакой статистики нет, как я и предполагал. Есть цифры торчащих жопой в интернет инстансов

Ну зачем же вы так сразу... мы только начали... а вы сразу с фактами... :)

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

А когда починишь можно сделать везде alter table engine=myisam чтобы в будущем не было этой возни после сбоев.

Ты прямо мастер давать очень странные советы. Перейдя на MyISAM будешь постоянно видеть сообщения о том что таблица заблокирована, придется отказаться от транзакциий, любимых тобой foreign keys, ACID’а, нормального кэширования и буфферизации, невозможно будет сделать консиситентный бэкап без остановки mysql, ну и при порче данных таблицу сложнее будет восстанавливать без транзакционного лога.

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

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

Перейдя на MyISAM будешь постоянно видеть сообщения о том что таблица заблокирована

Ни разу не видел. Это у innodb такие бывают наоборот - когда между двумя транзакциями deadlock получается и одну из них приходится откатывать и делать заново. Нет транзакций - нет и этих проблем. Просто подождать, и в большинстве случаев - совсем немного (например 100мс, если там конечно какой-то тяжёлый запрос неграмотно не всунули куда не следует). Для уже упомянутых сайтов уровня яндекса, понятное дело, ситуация другая, но их это обсуждение не касается.

придется отказаться от транзакциий, любимых тобой foreign keys, ACID’а

И чем это грозит для стандартного пхп-веба (посмотри его другие темы) типа форумов и гостевух?

нормального кэширования и буфферизации

Это ещё с чего?

невозможно будет сделать консиситентный бэкап без остановки mysql

Ну да.

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

А давай у автора спросим, что он предпочтёт в случае таких ситуаций:

1) база отказывается запускаться и заставляет хозяев устраивать муторную ручную возню по «правильному» восстановлению данных, при этом возможно что-то таки потеряется, но скорее всего очень мало (последние транзакции, которые не успели записаться никуда перед крашем)

2) база принудительно запускается, как может фиксит сама все несостыковки, а там где сложно - тупо выкидывает мешающие данные, зато ручной возни не требуется и его онлайн-сервис снова онлайн; при этом вероятность и количество потерь в среднем больше чем в первом варианте, но всё ещё в среднем маленькое и тоже затрагивающее только те места, где что-то менялось в последние минуты перед сбоем.

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

Это у innodb такие бывают наоборот - когда между двумя транзакциями deadlock получается

Это не проблема innodb, это проблема макак которые так написали, транзакция на запись должна быть короткой, стартанули, записали, закомитили. Макаки же все в одну транзакцию кладут и выборку и запись, стартанули транзакцию с select *.... пользак несколько часов в неё смотрит, потом решает поменять что-то... надеюсь вы поняли почему deadlock возникает. Но как уже упоминал, даже секундная конкурентная транзакция возможна, однако лучше оно ругнется чем получить неконсистентность в результате.

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

пользак несколько часов в неё смотрит

Нет, я имел ввиду короткую в доли секунды. Ну разумеется там селекты с апдейтами перемешаны, потому как вторые зависят от первых.

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

Да я и не осуждаю.

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

Ну разумеется там селекты с апдейтами перемешаны, потому как вторые зависят от первых.

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

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

Чувак, это просто кошмар. Либо ты очень тонкий тролль, на таком уровне, что большинство годами не замечает, что ты троллишь (вспоминая, например, твоё сообщение из 2019 о том, что «юникод - не нужен»). Либо моё мнение о том, что уровень PHPшников в IT - ниже плинтуса, получил очередное мощное подкрепление в этом треде.

Ну серьёзно. «Транзакции могут приводить к взаимным блокировкам, поэтому не надо использовать транзакции».

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

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

это проблема макак которые так написали, транзакция на запись должна быть короткой, стартанули, записали, закомитили. Макаки же все в одну транзакцию кладут и выборку и запись, стартанули транзакцию с select *…. пользак несколько часов в неё смотрит, потом решает поменять что-то..

Нда, гораздо «лучше», если пользователь А выполнил в короткой транзакции «SELECT amount FROM account WHERE account_id=345», и получил 100, затем пользователь Б выполнил в короткой транзакции «SELECT amount FROM account WHERE account_id=345», получил 100.

Затем каждый из них выполнил код «amount += 100» и выполнил в новой короткой транзакции UPDATE.

Вот это реально, уровень не криворуких макак!

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

Сколько можно перевирать мои слова?

1) я не писал что «юникод не нужен» (вот именно так категорично), прочти внимательнее что там

2) я не пхпшник

3) я не писал что не надо использовать транзакции из-за того что они могут приводить к блокировкам

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

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