защита от сбоев MySQL сервера во время dump`a

[becool]

защита от сбоев MySQL сервера во время dump`a

Появилась проблема такого рода:
Есть небольшой dump данных (~200 смешанных инструкций: insert update delete). Во время обработки этого дампа, чёто случилось с серваком -- завис на пять минут, по какой то своей причине, без моего участия. Соответственно половина инструкций выполнилась, половина осталась. Это очень и очень плохо для конкретного проекта + сама таблица оказывается битой.
И вот вопрос:
Есть ли какие то автоматические встроенные процессы по недопущению такой проблемы?
Ибо щас приходится копировать всю таблицу (это долго и дико много данных), натравливать на копию свой список инструкций и затем, если всё окей, заменять обновлённую копию на оригинал.

С SQL`ом на ВЫ...

P.s.
MySQL 5.x.x
PHP 5.x.x
Apache 2.x.x
Win2003

 

[Апельсин]

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

если проблема воспроизводится на одних и тех же данных с одними и теми же запросами, то вам прямая дорога на bugs.mysql.com.

 

[becool]

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

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

 

[Апельсин]

ну для начала перед пиковыми нагрузками запусти mysqladmin что бы он куда-нибудь писал processlist. Посмотришь какие запросы в этот момент запущены, в каком состоянии.

mysqladmin -i 1 processlist > processlist.txt

Будет каждую секунду выполнять SHOW PROCESSLIST.

Потом по Ctrl+C стопнешь.

Из твоего рассказа непонятно, является ли это состояние временное и потом MySQL сам по себе из него выходит либо вы перезагружаете сервер.
Проверьте есть ли что-то в error log MySQL.

 

[becool]

MySQL сам выходит из такого состояния, думаю просто слишком много запросов (can`t connect to mysql server). повторюсь - проблема не в сервере. А если проект переедет на другой сервак, там тоже думать чо да как и почему?
Хотелось бы сохранять кучу данных без опаски и без потерь в таких условиях...

 

[Апельсин]

похоже просто кол-во открытых соединений достигает max_connections и соответственно все последующие соединения абортятся.

соттветственно посмотреть какие из запросов в этот момет создают наибольшую нагрузку для сервера и оптимизировать их. Можно сотавить одо соединение открытым и потом промониторить SHOW PROCESSLIST и SHOW INNODB STATUS (если используется InnoDB).

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

 

[becool]

хм. Зачем ты пишешь всё время про сервер? яж спрашиваю:

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

Меня интересует правильность SQL логики, может быть примеры каких-нибудь похожих действий и так далее. Делают так вообще? или не делают вовсе. И если нет то почему? А как тогда делают?

 

[Апельсин]

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

стандартный дамп mysql - это create table + insert. все.

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

 

[becool]

Делаю вот что.
Из mysql таблицы выбираю допустим 100 рядов в стороннее приложение, делаю с ними чо хочу - например пять рядов удалил, двадцать изменил, три добавил.
В этоге создаётся такой... ээ project_file в котором каждое действие записано как sql query, например:
delete from `table` where `id`='22'
insert into `table` (`field`) values ('value')
update `table` set `field`='value' where `id`='33'
и так далее...

Когда пользователь решает, что все изменения сделаны, он посылает весь этот сток комманд на сервак. Через foreach прогоняется mysql_query($query), и вот _ИНОГДА_ , во время massquery чёт случается с серваком (неважно что, не зависит от query). В этоге половина изменений сделанна, половина нет. И состояние/структура таблицы оказывается вовсе не та, которую ожидает пользователь.

Вот так может понятней?

 

[Krishna]

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

Проверять в частности через show full processlist, опять же, и slow query log.

Лечение - переходом на innodb, заодно можно будет обеспечить целостность данных при обновлении базы, ибо кучу операций можно будет впихнуть в одну транзакцию.