ты должен будешь чем-то пожертвовать :
В распределённой системе невозможно обеспечить одновременное выполнение всех трёх условий: корректности, доступности, устойчивости к сбоям узлов. Это доказанная теорема
http://softwaremaniacs.org/blog/2010/01/31/brewers-cap-theorem/
Проще всего резервные каналы оплачивать - это ты точно сможешь.
построить систему, которая автоматически исправляет данные, будет не менее дорого.
и нагрузил его еще больше. ай, малацца.
Сделай так, чтобы знал. Или ты думаешь что на форуме угадают? Выводи при возникновении ошибки сам запрос.
Значение конечно маленькое, но может так и было задумано при настройке сервера.
По-умолчанию там 18446744073709551615.
Miracle, ты определись выполняется или получаешь ошибку. Я только ошибку имел ввиду.
покажи еще show variables like '%max_join%';
Miracle, представь, что бы выдал этот запрос не будь в нем LIMIT, DISTINCT и GROUP BY.
Наверняка у тебя там неправильно пересечение кучи строк N с еще большей кучей M, что в JOIN в результате даст N*M строк.
Для защиты от ошибок и чтобы не перегрузить сервер и сделан этот лимит.
А это не зависит от наличия LIMIT. Зависит от предсказанного объема объединяемых элементов.
Если он слишком большой, значит, вероятно, забыли условия объединения в WHERE .
maxim77k, высокий тупизм - симптомы суеты вокруг бага #12309, а высокий WA просто показатель для оценки нагрузки ввода-вывода.
Зато у всех есть mysql, а там есть LOCK TABLES.
Buenos, у тебя же один массив для всего. копируешь файлы, а тормозит mysql.
"HW RAID1" на дешевой raid-карте наверняка не самый лучший вариант. Ты же копируешь файлы и записываешь на те же самые диски.
Может поставить еще один винт для хранения бекапов? Это потребует от тебя минимум настроек в софте.
aristan, попробуй в командах exec обрамлять аргументы в дополнительные кавычки
то есть из php это будет выглядеть так
exec("convert \"$filename\" ");
впрочем ошибки могут быть и другие. стоит обрабатывать вывод программы, вдруг она там ругается на содержимое файла.
