Восстановление базы из /var/lib/mysql

Нечего было innodb использовать, теперь мучайся. В случае с нормальным движком (MyISAM) достаточно было бы просто скопировать файлы и сделать всем check table / repair table.

Хотя у тебя не очень понятно что именно пропало.

В случае с нормальным движком (MyISAM)

Это троллинг такой?

Восcтанавливай структуру. Потом клади файлы и читай https://backup.ninja/news/recovering-orphaned-innodb-tables-guide

Нет, это не троллинг.

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

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

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

Я сам и написал что там нет транзакций. Повторюсь, подавляющему большинству (>99%) пользующихся mysql не нужны ни транзакции, ни остальные теоретические плюсы innodb. А вот возможность починить таблицу в один клик после сбоя или неудачного бекапа - очень даже нужна. И более быстрая работа (не нужно тратиться на поддержку теоретических требований к «правильной» бд) - тоже однозначный плюс. Поэтому MyISAM вне всяких сомнений для этих целей лучше.

Поэтому MyISAM вне всяких сомнений для этих целей лучше.

Там еще локов на запись нету (поэтому я отказался от myisam в своё время). Хз innodb - это более-менее нормальный acid, а myisam - файлоподелка.

MyISAM быстрее

Для локалхоста с 1 посетителем (тобой). Для прода его ставить нельзя, в MyISAM вся таблица лочится при insert/update, один пишет, все остальные в очереди курят бамбук.

Локи там есть, как шаред на чтение так и эксклюзивные на запись. https://dev.mysql.com/doc/refman/8.0/en/lock-tables.html Или ты про другое?

innodb - это более-менее нормальный acid, а myisam - файлоподелка.

Третий раз: 99% пользователей НЕ нужен acid, им нужен движок для хранения таблиц и поиску по ним. Без acid он получается быстрее и проще, соответственно выбирать нужно именно этот вариант. acid оставь тем кто знает зачем он им и готов ради него жертвовать ресурсами.

Я вот недавно видел как на проде таблица жутко лагала (из-за того что нуб по дефолту сделал её innodb и ни о чём больше не заботился) а после конвертации в myisam - всё стало в разы быстрее. Апдейты перестали копиться в 20 лагающих потоков и стали выполняться по очереди и быстро. Да, можно было доп. логикой и в innodb заставить их делаться по очереди, но зачем? MyISAM просто работает как надо, InnoDB потребовалось бы обвешивать костылями против мультипоточности и она всё равно тупо больше байт занимает на диске и гоняет в памяти.

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

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

Вопросов больше не имею.

Спасибо. Установил программу Вот только запускаю как там сказано командо: ibdconnect -o /var/db/mysql/ibdata1 -f /var/db/mysql/XXX/xxx_xxx.ibd -d XXX -t xxx_xxx

А мне выдает -bash: -f: command not found

Надо внимательно смотреть в синтаксис и не тупо копировать команды из статьи

Подскажите, пожалуйста, как правильно?

Видимо, не начинать команду в консоли с -f

Мне это ни о чем не говорит, без нее так же не работает

Выложи скриншот

https://ibb.co/0ZpkRYk

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

Да Вы правы она установлена https://ibb.co/3yNjcvL

Это просто каталог с исходниками, ее, как минимум, еще собрать надо.

Не подскажите инструкцию как это сделать пожалуйста

Ну там же файл INSTALL есть, там должно быть указано

Где есть понимание что нужны именно параллельные insert/update - можно и innodb посмотреть, но на деле такие ситуации редки

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

И что этот пример должен показать? Какую конкретно проблему? По-моему ни одной проблемы там произойти не должно в описанных условиях.

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

И какая от этого произойдёт неприятность?

Зависит от конкретной БД.

Ну, я не вижу ни одного варианта проблем от описанного случая, если БД вменяемая. И не понимаю, к чему он был приведён.

попали на ситуацию с одновременной записью.

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

не нужны ни транзакции, ни остальные теоретические плюсы innodb

Метапрог, ты?

нет

99% пользователей НЕ нужен acid, им нужен движок для хранения таблиц и поиску по ним

так пусть юзают sqlite

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

И не понимаю, к чему он был приведён.

Вот к этому

параллельные insert/update ... но на деле такие ситуации редки

Что даже кажущийся редким случай, на практике происходит гораздо чаше.

Мне казалось, очевидно и не требует специальных пояснений, но видимо нужно. Распишу тогда максимально подробно (может быть слишком подробно, но я думал что тут вообще нечего расписывать), чтобы не было ещё где понять не так.

То, что запросы иногда могут приходить одновременно - это очевидно. И если это например база сайта у которого есть постоянная посещаемость (а не раз в час) - такое будет происходить регулярно. Движок базы такие случаи должен обрабатывать корректно (без межпоточных багов), это даже не тема для обсуждения. То есть, если приходят одновременно для insert, то база не будет пытаться тупо делать их в два потока, не знающих друг о друге, попадающих в race conditions и портя данные. Естественно, существует межпоточная синхронизация, гарантирующая корректный доступ к данным.

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

[1] если пришло два инсерта, то сначала делаем первый, а потом (когда первый завершился) начинаем делать второй. В этом случае инсерты никогда не будут друг с другом конфликтовать, ведь каждому из них достаётся консистентная таблица на входе, в персональное пользование, и на выходе от него требуется консистентная таблица с изменёнными данными. Кроме того, пока делается инсерт, из таблицы нельзя и читать тоже - ведь какие-то байты в ней перезаписываются, и не факт, что чтение прочтёт что-то корректное, а не какое-то промежуточное неконсистетнтное состояние.

Но этот подход может вызывать одну проблему: если insert/update выполняется долго, то остальным придётся это «долго» ждать в очереди, что не всегда желательно. Поэтому есть другой подход:

[2] сам механизм дозаписи/обновления данных в таблице (и формат её хранения) делается таким, что одновременно (без ожидания очереди) может делаться и другая запись (в другую строку) или чтение (откуда угодно). Такой алгоритм, очевидно, сложнее и медленнее, но он позволяет всё делать без очередей (ну, почти).

Первый подход используется в MyISAM, второй - в InnoDB.

Так вот, моё заявление было о том, что в подавляющем большинстве (99%) случаев (случай = конкретный проект или таблица, а не какое-то произошедшее событие) первый подход (с очередью) не вызывает никаких проблем - очередь, хоть теоретически и возможна, но на практике длинной не получается. Ну, допустим изредка кому-то придётся подождать 0.1 секунды (а раз в неделю - подождать 5 секунд) пока сделается какая-то запись, а большую часть времени очереди вообще не будет. А раз он проблем не вызывает, то незачем городить сложные алгоритмы из второго подхода - пользы они не принесут (всё и так хорошо) а вот вред от них будет - они медленнее и сложнее.

Да, есть 1% проектов, где в силу неисправимых архитектурных особенностей или специфики нагрузки очереди таки собираются и мешают работе. Обычно на таких проектах работают вполне компетентные сотрудники, которые могут оценить ситуацию и обоснованно выбрать второй подход. В этом случае - он оправдан. А вот если ты, будучи нубом, прочёл в инете «innodb круче» и теперь бездумно её суёшь везде по-дефолту - это идиотизм.

Вы описываете вариант трехзвенки ака тонкий клиент, я привел пример клиент-сервера.

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

межпотоковая синхронизация запросов в любом случае делается сервером

Вы про блокировки?

Ну что за странные вопросы опять. Где-то блокировки, да. В MyISAM, в частности - только блокировки. В InnoDB - хитрее, хотя формально оно там построковыми блокировками называется или как-то так.

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

Ну раз вам интересны подробности. Есть проверка на уникальность определенного набора данных в записях. Достаточно простая и при этом чуть сложная логика, уникальность вхождений задается тремя полями A,B,C, но сама возможность или невозможность повторного вхождения зависит от значения двух из этих полей B,C, точнее одно из полей C является fk на справочник в котором есть поле определяющее возможность дублирования. Например при A=N,B=любое-значение, поле C может иметь значение 1 только один раз. При A=N,B=M поле С может иметь значение 10 только один раз, то есть при A=N,B=M+1 поле со значением 10 может повториться.
Ух, надеюсь понятно объяснил. :)
Так вот, два пользователя умудряются менее чем в одну секунду сохранить данные со значением третьего поля на которое наложены ограничения.

Ну, я бы так сделал:

1) эксклюзивная блокировка таблицы (в терминах mysql она называется блокировкой на запись)

2) селект с проверкой наличия конфликта, если конфликт есть то выдаём ошибку и идём п.4

3) если конфликта нет - вставляем строку

4) снимаем блокировку

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

Хотя есть ещё один костыльный способ, для mysql, связанный с тем что оно считает NULL всегда уникальным. Можно сделать уникальный ключ по не по трём колонкам, а по четырём. В четвёртой будет либо какое-то значение (везде одинаковое), если дубликаты запрещены, либо NULL если разрешены. Тогда никаких доп. проверок на клиенте делать не надо, база сама разберётся. Оно подойдёт, если логика ограничивается только поиском дубликатов по всем трём полям в зависимости от их значения. Если сложнее - то только способ выше.

Нечего было innodb использовать, теперь мучайся. В случае с нормальным движком (MyISAM)

Откуда вы такие берётесь?

Так мы и так выдавали осмысленную ошибку :) На всякий случай напомню с чего начали «параллельные insert/update ... но на деле такие ситуации редки» я вам привел пример, что это не такая уж редкость даже в условиях двух пользователей которые теоретически если и должны такое делать, то не чаще одного раза в год по обещанию.

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

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

Простите, а нафига тогда вообще субд нужна? Может по старинке на файловой с блокировками на уровне фс жить?

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

СУБД нужна затем, что в ней уже реализовано всё то, что иначе пришлось бы переизобретать заново. Перестань накидывать шаблоны и посмотри по фактам: у тебя пришло два запроса (из двух интерактивных клиентов, за которыми сидят люди, как я понял), делаются они условно за 0.01с каждый. Заметит ли второй (которому не повезло оказаться вторым в очереди), что его нажатие на кнопку «отправить» обработалось на 0.01с позже? Разумеется, нет. И не надо придумывать себе лишние проблемы на этом месте.

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

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

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

Блин. Mysql давно уже используется не только на php сайтах с сотней посетителей в день и складах.

Посмотри, кому и на что это был ответ. У него ИНОГДА два запроса совпадали до секунды. Значит, нагрузки там нет, а кто использует базу уже не важно.

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

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

Более того сейчас сложно такое использование уже найти

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

Оттуда, где важны реальные результаты работы

Видимо, работы не зависят от скорости БД, от её возможностей. Вам даже внешние ключи не нужны?

1. ИнноДБ — нормальный движок.
2. Есть ария, которая и быстрее и в марие.