Игорь З.
29 сообщений
#14 лет назад
Есть один UPDATE запрос в mysql, который изменяет в базе 10 значений. Подскажите, как работает мускул - что произойдет, если в процессе обновления вырубится питание? Т.е. может так случиться, что 5 значений в базе изменятся, а 5 нет? Сам запрос один. Таблица MyISAM.
Роман Ч.
171 сообщение
#14 лет назад
Такой запрос выполняется пару микросекунд, врятле кто так подгадает чтобы выключить свет именно в середине операции
Игорь З.
29 сообщений
#14 лет назад
Да, вероятность маленькая, но тем не менее она есть. А учитывая, что таких запросов может быть о-о-очень много и сам запрос может быть намного сложнее, вероятность сильно увеличивается.

Т.е. тут хотелось бы выяснить сам принцип работы MySQL - если в момент выполнения какого бы то ни было UPDATE запроса вырубится питание, возможно ли некорректное обновление данных? Или мускул устроен так, что один запрос, какой бы он ни был, либо выполнится целиком, либо не выполнится вообще?
Игорь Г.
44 сообщения
#14 лет назад
Запрос хоть и один но выполняется последовательно, например, это можно увидеть если создать более миллиона записей, выполнить запрос и сбросить питание компьютера или оставновить выполнения скрипта.
Будет давать crash базы ( Table is marked as crashed and should be repaired), т.е незамеченными такие действия не останутся.
Решается этот вопрос уже не программно, а обеспечением бесперебойного питания сервера.
Игорь З.
29 сообщений
#14 лет назад
Microscript,
А что произойдет с самими данными при этой ошибке, могут они некорректно измениться? Или после этой ошибки с таблицей, затронутой update-ом работать будет вообще нельзя, до того, пока вручную не восстановить базу? Смоделировать эту ситуацию и воспроизвести, действительно, очень проблематично ввиду мизерной вероятности такого события.
И, кстати, еще, если база вообще не будет работать, то после ручного восстановления какое будет состояние - как до выполнения сбойного запроса, или как после его выполнения?
Олег Казакевич
702 сообщения
#14 лет назад
Хреновая СУБД, которая не дает гарантий атомарности операций.

В реализациях таких систем принято выполнять критическую операцию в кэше, а
по ее окончанию устанавливать определенный флаг. Только тогда транзакция
считается завершенной. Если в процессе выполнения случается сбой или какая-то
аварийная ситуация типа отключения питания, то после перезапуска система должна
оказаться в том же самом состоянии, которое предшествовало операции.
Это базовая модель, реализованные в очень многих областях - от файловых систем до
идиом языков программирования. Очень удивлюсь, если популярная СУБД такого не умеет.
Евгений О.
263 сообщения
#14 лет назад
Цитата ("tri777ki"):
Есть один UPDATE запрос в mysql, который изменяет в базе 10 значений. Подскажите, как работает мускул - что произойдет, если в процессе обновления вырубится питание?

В первом приближении, это завист от:

1. Являются обновляемые поля индексированными или нет: если индексированными, то при перезапуске MySQL, скорей всего, обнаружит нарушение структуры индексов и потребуется "починка" таблицы утилитой myisamchk. Если поля не индексированы, то все может пройти "гладко": MySQL ничего не заметит. В любом случае, вполне вероятно, что часть данных будет обновлена, часть - нет (нарушение семантической целостности данных);

2. Момента времени в который будет выключено питание. С учетом специфики "подстилающей" файловой системы, возможны варианты от "исчезновения" БД на физическом уровне или разрушения файловой системы до нарушения семантической целостности данных.

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

PS. Я предполагаю, что под "мускул" Вы понимаете MySQL?
Евгений О.
263 сообщения
#14 лет назад
Цитата ("okman"):
Хреновая СУБД, которая не дает гарантий атомарности операций.

Если Вы про MySQL, то, с точки зрения прикладной программы, любая операция является атомарной. На уровне "железа", каждая "атомарная" операция состоит из тысяч более простых действий атомарность которых обеспечивается схемотехникой, а не реализацией СУБД. Впрочем, MySQL - СУБД, действительно, хреновая.

Цитата ("okman"):
...Если в процессе выполнения случается сбой или какая-то
аварийная ситуация типа отключения питания, то после перезапуска система должна
оказаться в том же самом состоянии, которое предшествовало операции.


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

Цитата ("okman"):
Очень удивлюсь, если популярная СУБД такого не умеет.

MySQL такое умеет. Но если диск обесточивается при записи кеша файловой системы, то MySQL уже не многое может сделать.
Олег Казакевич
702 сообщения
#14 лет назад
Цитата ("Illarion_SA"):
Если Вы про MySQL, то, с точки зрения прикладной программы, любая операция является атомарной. На уровне "железа", каждая "атомарная" операция состоит из тысяч более простых действий атомарность которых обеспечивается схемотехникой, а не реализацией СУБД.


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

Цитата ("Illarion_SA"):
Но если диск обесточивается при записи кеша файловой системы, то MySQL уже не многое может сделать.


И свойства диска тут вообще не при чем.
Александр В.
771 сообщение
#14 лет назад
Если я не ошибаюсь, если группа запросов явно не оборачивается в транзакцию, то MySQL на каждый update/insert/delete создаёт свою. Соответственно невозможно повредить базу данных отключением питания при выполнении запроса к одной записи.
Но если UPDATE затрагивает более одной записи - mysql может на часть записей его выполнить, на часть нет. Откат/коммит транзакции на одну запись произойдёт при следующем запуске сервера mysql
Николай М.
1895 сообщений
#14 лет назад
О май гад....

1. На сервере обьязательно должен бить упс, впервые слышу что сервер без упса)))
2. Все операции пачками - должны работать через транзакции и никак иначе.
3. Используйте надёжные СУБД - MySQL я бы таковой не назвал, тупая и медленная СУБД, а за даты... Вообще бы убыть мало.
4. MyISAM ненадёжная модель, которая не поддерживает транзакции, а значит что случится? Да все что угодно.
Евгений О.
2989 сообщений
#14 лет назад
Цитата:
Даже в транзакционной системе возможна потеря данных в случае внезапной остановки сервера (если сервер ``упадет''. Разница между различными системами состоит только в том, насколько мал промежуток времени, в течение которого данные могут быть потеряны. Ни одна система не является надежной на 100%, только ``достаточно надежной''. Даже для сервера Oracle (эта база данных считается наиболее надежной транзакционной базой данных), по сообщениям, в подобных ситуациях иногда возможна потеря данных. Что же касается использования сервера MySQL, то в любом случае, независимо от того, применяются или нет транзакционные таблицы, для обеспечения безопасности необходимо только иметь резервные копии и включенную регистрацию обновлений. Благодаря этим мерам в MySQL, так же как и в других транзакционных базах данных, можно восстановить информацию в любой ситуации. Резервные копии вообще хорошо иметь всегда, независимо от того, какая база данных используется.
Цитата:
В ситуациях, где целостность данных чрезвычайно важна, сервер MySQL обеспечивает даже для нетранзакционных таблиц надежность и целостность данных уровня транзакций или лучше. При блокировании таблиц с помощью LOCK TABLES все обновления останавливаются до тех пор, пока не будут выполнены все проверки на целостность. При наличии только блокировки чтения (в противоположность блокировке записи) операции чтения и вставки, тем не менее, производятся. Новые внесенные записи не будут видны никому из имеющих блокировку чтения клиентов до освобождения этих блокировок. С iомощью INSERT DELAYED вставки становятся в очередь и находятся там до тех пор, пока не будут сняты все блокировки. При этом клиент не вынужден ждать, пока отработает INSERT.
Сергей Ф.
83 сообщения
#14 лет назад
Если у вас транзакции, то Вы выбрали неверный тип таблиц для этого дела
Используйте InnoDB и не будете иметь головных болей по этому поводу
Вадим Т.
3240 сообщений
#14 лет назад
Цитата ("tri777ki"):
Есть один UPDATE запрос в mysql, который изменяет в базе 10 значений. Подскажите, как работает мускул - что произойдет, если в процессе обновления вырубится питание? Т.е. может так случиться, что 5 значений в базе изменятся, а 5 нет? Сам запрос один. Таблица MyISAM.

Да, то, что в случае сбоя изменится только 5 записей из 10, возможно. Также возможно, что и вообще вся таблица будет повреждена.
После таких случаев нужно делать CHECK TABLE, затем при необходимости REPAIR TABLE, или же можно использовать утилиту myisamchk при остановленном MySQL.

Использование InnoDB значительно снизит подобные риски, хотя все равно не даст полной гарантии.
Главная проблема в том, что при вырубании питания крешится не только MySQL, но и файловая система.
Игорь З.
29 сообщений
#14 лет назад
Ясно. Спасибо за информацию!