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

DROP TABLESPACE, наверное.

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

Поучаствуй плз в соцопросе:

1) нужны ли тебе (не бесплатные) транзакции в этой таблице?

2) нужна ли тебе (не бесплатная) 100% консистентность при неожиданных потерях питания или kernel panic-ах сервера или segfault-ах процесса базы?

3) выбирал ли ты осознанно innodb или это был дефолт?

4) если выбирал осознанно - чем руководствовался? если не выбирал, о выбрал бы innodb, если бы выбирал?

5) знаешь ли ты, что у того же myisam подобных проблем (как у тебя) в принципе быть не может?

Найди любой .frm файл, скопируй его на место, где был удалённый – и после сделай DROP TABLE.
Да, всё так просто.

2. нужна ли тебе (не бесплатная) 100% консистентность при неожиданных потерях питания или kernel panic-ах сервера или segfault-ах процесса базы?

БД, разваливающейся после отказа питания, OOM или других багов, будет пользоваться только умственно-отсталый.

Чего уж там, от INSERT, DELETE или UPDATE в случае ошибки она тоже может перейти в непредсказуемое состояние (и это может не быть сразу заметно).
Но это лишь данные, в мире firkax они достойны максимум того, что получают отходы на мусоросжигательном заводе.

Я не у тебя спрашивал. Когда придёшь на лор с жалобой на сломавшуюся innodb тоже поучаствуешь.

6) знаешь ли ты, что dbf файл можно поправить в обычном текстовом редакторе?

Это не работало, писало что таблица отсутствует. Хотя show tables ее показывало.

Я так понимаю, IBD файлы это непосредственно сами данные, с какими то хитрыми журналами, но вот не понимаю, почему если я удаляю из /var/lib/mysql/dbname/table_name.ibd, /var/lib/mysql/dbname/table_name.frm эти файлы, не могу просто взять и создать заново таблицу table_name. CREATE TABLE пишет, что таблица существует

В InnoDB всё сложно, часть информации о таблице хранится в другом месте (про все таблицы всех баз вместе), отделить её оттуда невозможно, а обрабатывать ситуацию «в файлах метаданных не то, что ожидалось» оно за 20 лет так и не научилось.

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

в случае ошибки

1) давно ты такие «ошибки» ловил?

2) в 99.99% случаев, даже после так называемой ошибки (которых в норме не случается, так же как и неожиданных отключений питания, ведь есть упс), всё будет автоматически починено с потерей в последние несколько секунд перед крашем.

3)

Но это лишь данные, в мире @firkax они достойны максимум того

Ты слишком категоричен, но направление верное: в подавляющем большинстве случаев потеря пары строчек несущественна. Где существенна, обычно не используют mysql вообще.

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

Повредели файлы

как бы намекает, что срочно пора менять админа.

Не знаю, что там за админы. В общем мне надо было настроить там свое приложение и пара некритичных таблиц развалилась. Был выбор либо все начать разворачивать с нуля или попытаться восстановить. Все как всегда, Старый админ уволился, а новый админ взял и отключил скрипты дампирования БД, т.к. их забыли занести в инструкции как обязательные. А свои дампы я вообще в другом городе сохранил по правилам безопасности, туда физически добраться не могу. Так что тут сложно винить MySql, единственное что не удалось сделать, это по FRM восстановить структуру таблиц, посмотреть тип полей, т.к. за базой никто не следил особо, а разрабы могли там где-то что-то поменять. Если немного не по теме, то сейчас везде чехорда с it кадрами и люди с которыми я по 5 лет контактировал начали резко менять места работы и бывает каждые полгода новый специалист. Дошло до комичного. Сперва «админ Сергей» звонил из конторы А, а потом он с этого же номер стал звонить из конторы Б.

Когда придёшь на лор с жалобой на сломавшуюся innodb тоже поучаствуешь.

Т.е. innodb ломается, но использовать все равно нужно myisam, потому что… она менее надежна, с твоих же слов? Лол

Я не у тебя спрашивал. Когда придёшь на лор с жалобой

Когда ЛОР-овцу нечего ответить по существу, он начинает кукарекать.

В Oracle MySQL 8.0 .frm вообще не используются. Возможно, поэтому.
Попробуй запустить CLI как mysql -A (или mysql --no-auto-rehash), и далее DROP TABLE уже оттуда.

давно ты такие «ошибки» ловил?

Внезапно, не давно.

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

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

Где существенна, обычно не используют mysql вообще.

Фантазии.

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

Если что, ситуацию da17 я воспроизвести не могу, DROP TABLE работает.
Но нужно узнать, какая версия СУБД там вообще, потому что у меня под рукою MariaDB 10.3-10.6 и Oracle MySQL 8.0.23.

Troubleshooting InnoDB Data Dictionary Operations говорит, что автодополнение может приводить к проблеме, потому я уже предложил попробовать без. Посмотрим.

Server version: 5.6.19

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

1. Делаю show tables; есть моя таблица Events;

2. Пишу drob table Events; пишет таблица не найдена, frm файл есть ibd файлов нет.

3. Пишу create table Events, пишет «не могу создать, таблица уже существует»

в подавляющем большинстве случаев потеря пары строчек несущественна.

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

Сперва «админ Сергей» звонил из конторы А, а потом он с этого же номер стал звонить из конторы Б.

И это ниразу не значит, что «админ Сергей» сменил место работы. Мог сменить, а мог и не сменить.

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

На каждый хитрый упс найдется свой электрик пасатижами, даже не так, на упсы (во множественном числе) найдется свой электрик. Один из лучших примеров в моей коллекции это электрик вася, спаливший эйписишный смарт таким образом, что специалисты апц не осилили найти ответа на вопрос: «Как этого можно было достигнуть?».

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

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

Я имел в виду не такой вид ошибки. А когда выполнения запроса просто неуспешно. С MyISAM это превращается в проблему.

Всмысле неуспешное выполнение? insert с конфликтующим ключом что ли? Вроде о такого не должно быть ничего.

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

Зависит от проекта.

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

И после этого ты будешь спорить о том, что им якобы нужна теоретически правильная база? По-моему вывод очевиден - не нужна. А указанная тобой категория - и есть основная (и, возможно, целевая) аудитория mysql.

Вроде о такого не должно быть ничего.

Только INSERT можно вносить одновременно сколько угодно значений. И если ему что-нибудь помешает, то в адекватной СУБД данные просто не будут внесены. С MyISAM же какая часть данных будет внесена, а какая-то – не будет.

Или представь себе, что UPDATE начал менять значения, а потом споткнулся об уникальный ключ.
Или DELETE начал удалять кортежи, а потом споткнулся о внешний ключ.

Если в MyISAM начали вноситься какие-то изменения, то если операция будет прервана, то порою сложно определить, а что в базе вообще есть, а чего нет.

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

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

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

Какая атомная чушь, очень похожа на сектантство, помешанное на синдром утенка.

Server version: 5.6.19

А, понятно.
Скопируй .frm как я ранее сказал, потом сделай ALTER TABLE table_name DISCARD TABLESPACE;, далее уже DROP TABLE.

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

Им - нет. Для вэба вообще, как и для любого другого места - да.

А указанная тобой категория - и есть основная (и, возможно, целевая) аудитория mysql.

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

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

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

Только INSERT можно вносить одновременно сколько угодно значений. И если ему что-нибудь помешает, то в адекватной СУБД данные просто не будут внесены. С MyISAM же какая часть данных будет внесена, а какая-то – не будет.

Ну, часть строк будет внесена, часть нет. Аналогично и с UPDATE (но не DELETE, ибо внешних ключей в MyISAM нет). Таблица останется в консистентном состоянии, с точки зрения базы. MyISAM не гарантирует транзакционность операций, даже если они заданы одной командой. Но вот каждая отельная строка всё же будет либо обновлена, либо нет. Просто надо это воспринимать не как отход от теоретического апи базы, а как другое апи. У него есть и плюсы: можно прервать тяжёлое DELETE в середине, если хочешь отложить его на потом (из-за нагрузки) и уже удалённое останется удалённым.

Если в MyISAM начали вноситься какие-то изменения, то если операция будет прервана, то порою сложно определить, а что в базе вообще есть, а чего нет.

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

Только и чинится она тоже одним пинком. Но у всего есть свои плюсы и минусы, да.

Но вот каждая отельная строка всё же будет либо обновлена, либо нет.

С INSERT – очевидно, да. Как может быть иначе?
С UPDATE – а вот хренушки.

Только INSERT можно вносить одновременно сколько угодно значений. И если ему что-нибудь помешает, то в адекватной СУБД данные просто не будут внесены. С MyISAM же какая часть данных будет внесена, а какая-то – не будет.

Транзакции для слабаков.

Хотя нет, это я лох, myisam в них не умеет.

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

Немного поправлю: обывателю не нужно, чтобы база идеально хранила каждый байт и следила за «консистентностью для приложения», если цена этого всего - пониженная производительность и такие поломки как у автора. В MyISAM бы как раз поломки не было - после автоматического repair table из таблицы бы молча пропало какое-то количество (ненужных, автор темы сам подтвердил) записей и она продолжила бы работать как будто ничего не случилось.

С UPDATE – а вот хренушки.

Ладно, как-нить проверю. Конечно не очень хорошо если апдейт может половину строки обновить, но вроде это несложно должно фикситься, ведь в инсерте вся нужная логика есть. Может поправят со временем.

после автоматического repair table из таблицы бы молча пропало какое-то количество (ненужных, автор темы сам подтвердил) записей

Эм, он всю таблицу потёр случайно. Не тот случай.
И если бы у него была MariDB или более новая версия Oracle MySQL, то достаточно было бы сделать DROP TABLE.
Мы сразу версию не спросили, потому были непонятки.

InnoDB тоже не сложно чинить, если он не совсем сломан.
А совсем сломанность, она и в MyISAM совсем сломанность.

Может поправят со временем.

Как? Добавив в MyISAM рудиментарную транзакционность? Тогда это уже будет не MyISAM, а Aria.

Всего лишь подсчёт ключей и выявление конфликтов по уникальным до апдейта (одной строки) а не в середине.

А говоришь, медленно == плохо.
Но при сём легко готов пожертвовать скоростью успешных запросов.

Впрочем, вряд ли замедление MyISAM от затычек в ядре для процессорных уязвимостей кто-то будет исправлять, потому понятие производительности тут – штука такая (Aria, кстати, не подвержена).

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

A int, B int, UNIQUE KEY (A,B)

есть записи 1,2 2,2

делаем update set A=2,B=3 where A=1 and B=2

Если он обновляет колонки отдельно то должен упасть на записи двойки в A.

Не удивлюсь, если в Game of Life ты тоже всегда заведомо знаешь конечное состояние системы.

Aria, кстати, не подвержена

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

Но я не особо с ним сталкивался.

MariaDB по умолчанию использует InnoDB, свою версию.

А упомянул я это потому, что заявления о производительности с твоей стороны – это немного лицемерие.
MyISAM давно замедлился, а ты даже не придал сему никакого значения.

Не слежу. У InnoDB замедленение в глаза просто бросается.

У InnoDB замедленение в глаза просто бросается.

А ты знаешь, что InnoDB для большей производительности (когда настроен) опирается на собственный кэш, который выделяется заранее, его размер определяется innodb_buffer_pool_size.
Можешь пинать InnoDB за это, но это просто правда жизни: InnoDB без настройки не будет нормально работать.
Как отправная точка, можешь посмотреть на советы MySQLTuner по оптимизации. Они не всегда хорошие, но они дают понять, куда смотреть.

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

но оно какбэ так и есть, безотносительно закона ома

оно какбэ так и

нет.