Повредили файлы базы данных в MySql ibd и frm

MyISAM

Чел, ты болен. Прекрати уже эту дрянь всем втирать, кто о БД упомякнул.

Нет, это ты религиозно-теоретический фанатик.

а религиозно-то почему

Потому что это такая религия - веровать в святые писания теоретиков.

SQLite is Transactional

Когда даже SQLite не разваливается на части, это повод задуматься.

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

Вообще говоря, разваливается с удручающей регулярностью.

Хватит молиться на транзакции. Их сфера применения сильно уже чем некоторые пытаются впарить. А если ещё и сервер не теряет питание неожиданно и регулярно - то ещё уже.

И какой у тебя опыт? Пока что я вижу только ничем не подкрепленные заявления «нет транзакций, ужас, она развалится через день».

Вообще говоря, разваливается с удручающей регулярностью.

Хотел поставить звёздочку, но решил не усложнять для firkax.
На фоне MyISAM всё одно.

Их сфера применения сильно уже

А Prosody вообще может вместо СУБД писать данные в текстовые файлы.
Если что-то пошло не так, просто открываешь в vi и чинишь. А не эти ваши сложные MyISAM.

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

да

А Prosody вообще может вместо СУБД писать данные в текстовые файлы.

Поздравляю их, они сделали свою реализацию примитивной СУБД, интегрированный в приложение. Не знаю только, зачем, ведь можно всегда установить нормальную базу. Ты путаешь примитивность и простоту/лёгкость. Нет самоцели «удалить сервер СУБД и вставить вместо него что-то намеренно-примитивное». Текстовые файлы - примитивны и неудобны. Чинить в vi - долго, это неудобная ручная работа. Лучше сделать автоматическую программу-чинилку этих текстовых файлов. А зачем текстовых то? Бинарный формат (для починки) парсить проще и быстрее чем текстовый, да и сам движок базы бинарный формат будет обрабатывать быстрее. И да, в MyISAM есть автоматическая чинилка. А в InnoDB - нет. Так что к текстовым файлам ближе оно, несмотря на перегруженность ненужными для 90% пользователей фичами (которые, кстати, можно и в текстовых файлах реализовать, что ещё раз подтверждает что твой пример неудачный).

Нет. Больше геморроя с запасом топлива. Вероятности возникновения пожара тоже больше.

Хватит молиться на транзакции. Их сфера применения сильно уже чем некоторые пытаются впарить.

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

А если ещё и сервер не теряет питание неожиданно и регулярно - то ещё уже.

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

Так и мускуль умеет в CSV же.

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

сдаётся мне нормальную печку ты только на картинках в сказках видел

Вероятности возникновения пожара тоже больше.

ага, а электрический обогреватель, особенно масляный, - верх пожаробезопасности, лол

Среди знакомых, сгоревших от обогревателя пока слава богу никого. А от печки несколько лет назад друган детства на даче сгорел.

блестящий комментарий местного юродивого по этому поводу.

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

Я знаю что такое транзакции и зачем они нужны, не надо мне расписывать.

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

Подавляющее большинство установок mysql - это штуки типа lamp, поставленные либо для личных блогов, либо для развлекательных лент, либо для интернет магазинов с ручной обработкой заказов (т.е. база на сайте это витрина + форма отправки письма менеджеру). Никакая транзакционность ни в одном из этих случаев нафиг не нужна. Изредка кто-то из них пытается финансовые дела тоже вести и автоматизировать с помощью той же базы, там уже могут пригодиться транзакции (но опять же, не для всей базы а только для финансово-критичных таблиц).

Заметно меньше установок - крупные сайты/сервисы. С одной стороны, кажется, им всё важнее, а с другой - ну что им будет если какой-то юзер потеряет пусть даже целиком свой аккаунт? Да ничего, в крайнем случае придётся сказать «ой, у нас тут технический сбой, попробуем вернуть ваши данные». Если сервис платный - вернуть месячную копеечную оплату в качестве компенсации. И всё.

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

Чел, ты всерьёз говоришь, что ради экономии на спичках нужно наплевательски относиться к данным, которые лично тебе показались недостаточно важными? У тебя точно всё хоть что-то хорошо?

ну что им будет если какой-то юзер потеряет пусть даже целиком свой аккаунт? Да ничего (...) вернуть месячную копеечную оплату в качестве компенсации. И всё.

О! Аналитика!

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

Я и не думал, что ты в этом узришь философию. Я не писал как нужно относиться к данным, это отдельная тема. Я писал про то, как происходит на самом деле. Если кому-то данные не важны - он будет относиться к ним наплевательски, ты можешь это осуждать сколько хочешь, но я удивлён что для тебя это было неожиданностью. А насчёт экономии - ну, на спичках она или нет - уже дискуссионный вопрос. Я не знаю, сколько своего, однозначно ценного, времени автор темы потратил на решение этой проблемы. И сколько времени потратил на починку ещё одной сломавшейся InnoDB другой автор с лора меньше месяца назад. Они могли бы его не тратить, если б там был другой движок.

Они могли бы его не тратить, если б там был другой движок.

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

Не знаю, почему тема не помечена как решённая, ответ тут: Повредили файлы базы данных в MySql ibd и frm (комментарий)

описанный тобой случай - редкость

Среди макак. ЧТД.

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

Круто, если это теперь починили, но всё остальное то осталось. Например если таблицу надо не дропать а починить.

Среди полной выборки. Если «не-макаки» там в меньшинстве - просто прими это. И очередного вопрошающего на лоре «у меня сломалось innodb» по статистике относи именно к «макакам» и отговаривай его от ненужных ему транзакций. Хотя я не разделяю твою привычку так оскорбительно отзываться о веб-кодерах, хоть и согласен что качество получаемого кода у них ниже чем надо бы.

Если это твой личный проект то оцениваешь ты сам. Если ты сотрудник в бизнесе - спрашиваешь у руководства «Вот тут можно потратить доп. средства ради того, чтобы раз в 5 лет какой-то никчемный юзер не потерял свои данные, тратим?» Бизнес не любит тратить даже копейки на то, что ему не нужно (не влияет на прибыль/убытки).

чтобы раз в 5 лет какой-то никчемный юзер не потерял свои данные

А потом программа перестаёт работать с вариантом assertion error и руководство начинает задумываться о твоём увольнении.

Выставляй innodb_force_recovery и чини всё, что нужно.

Бизнес не любит

когда возникают проблемы. И ещё он не любит тех кто создает ему проблемы. Ваш же подход создает проблемы, так как вы даже не умеете правильно подойти к вопросу. Когда через 5 лет этот никчемный юзер окажется совсем не никчемным, иметь будут вас. И вопрос «Какого юха?» будет оправдан на все 146%. А вот ваше блеяние «Ну я же говорил...» никто слушать не будет.

Это перевод темы на какие-то надуманные обвинения.

Да я в курсе про него. Когда-то для починки потребовалось:

1) подбирать перебором (create/drop/create/drop/create) id-ы таблиц чтобы они подошли к имеющемуся tablespace

2) включать этот самый recovery

3) продираться через сегфолты без диагностики, копируя данные из битой таблицы маленькими порциями (благодаря транзакционности - сегфолт в длинном запросе приводил к не копированию ничего вообще)

Уже думал забить на это поделие и писать свой парсер таблиц без сегфолтов и с нормальной диагностикой, но обошлось. А ведь где-то достаточно было бы одного repair table с тем же результатом.

Когда через 5 лет этот никчемный юзер окажется совсем не никчемным, иметь будут вас.

Ну, такой риск конечно имеется.

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

И если она не помогает до такой степени, что БД просто не стартует, то единственное, что может предположить оф документация

Если MyISAM сломать до такой же степени, то и совет будет такой же.

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

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

И мне довольно-таки пофиг на MyISAM, кто в здравом уме в 2k19 эту наивщину юзает.

Но хочется хотя бы иметь утилиты для выколупывания в ручном режиме горячих данных, которых в бэкапе нет, а не только кучу ругани и сегфолт.

Да есть куча разных, но сходу не назову, у меня ещё не было ситуации, когда всё настолько плохо, что даже с innodb_force_recovery=6 не добраться до данных никак.
Верю, что так тоже бывает, но вот не случалось.

И мне довольно-таки пофиг на MyISAM, кто в здравом уме в 2k19 эту наивщину юзает.

Я понимаю, но из-за контекста нужно проговаривать.

что даже с innodb_force_recovery=6 не добраться до данных никак.

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

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

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

ВОПРОС:

А теперь представь альтернативную реальность - таблицы, которые у них сейчас сломались, были бы в MyISAM. Как думаешь, пришли бы они сейчас за помощью? Или, может, пришли бы раньше? Или позже?

Ну, точный ответ дать, конечно, нельзя. Но я, ну скажем, на 90% думаю, что в случае MyISAM они бы вообще никаких значимых проблем (из-за которых надо просить помощи на лоре в починке) не заметили бы ни сейчас, ни раньше. Просто потому, что они бы ввели repair table и не парились. Может быть, они и не знали бы, что repair table это не магическое заклинание, убирающее все проблемы, что repair table восстанавливает не все данные, а только те, которые может, ну и индексы. Но скорее всего они бы отличий не заметили (ну то есть, вот например конкретно у этого - даже если пропали бы часть записей из лога - да кого бы это волновало?). У тебя другой ответ на вопрос выше?

Вот есть тема, в который мы сейчас общаемся. Недели две назад была ещё одна похожая. Ещё довольно недавно назад - ещё одна. У конкретно этих пользователей проблемы с InnoDB.

Угу, а если зайти на сайт пользователей mssql то внезапно наткнешься на темы про поломанную mssql. Сломать можно и dbf. И то что тем про поломанный dbf много, а про поломанный txt мало, совсем не означает что хранить данные лучше в txt.

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

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

А теперь представь альтернативную реальность - таблицы, которые у них сейчас сломались, были бы в MyISAM. Как думаешь, пришли бы они сейчас за помощью? Или, может, пришли бы раньше? Или позже?

Ларчик открывается очень просто: их вопрос звучал бы как «почему-то не открывается сайт», «при регистрации нового пользователя ошибка», «пользователи жалуются, что не могут оформить товар» и т.п.
И помочь на форуме уже никто не сможет, нужно лезть в базу и разбираться, что там пошло не так.
Зато REPAIR TABLE, удобно.

Это твой опыт использования MyISAM или предположения? Потому что мой - обратный, никаких фатальных поломок не случается, максимум терялась мизерная часть данных, пара пользователей в итоге могут обидеться, и на этом всё. Так что проблемы скорее всего были бы из разряда «перед крашем сервера кто-то оформил заказ, заказ после краша пропал и пришлось оформлять заново» или «дата последнего обновления темы не совпадает с настоящим последним постом в ней, пришлось создать и удалить тестовое сообщение в ней чтобы всё исправилось». В крайнем случае «деньги за заказ списались а заказа нет, пришлось вручную поправить баланс в нужной колонке таблицы по логам».

как хорошо, что погромистов обычно не допускают к руководству которое решает такие вопросы