Если это был такой аргумент, то он плохонький. Некоторые и Мавроди верят.
Andreyka, если вы изменили стандартные правила, то изменился и "уровень защиты". стандартные правила хотя бы специалисты собирали. а вам кто поверит? может ваши правила ничего особо не блокируют ?
Если не сами настраивали сервер, то вопрос следует задать тому, кто вам услугу mysql-сервера предоставляет. Изменить-то параметры вы не сможете все равно.
Разве что найти на стороне клиента какое-то обходное решение. Например, с помощью оператора set time_zone= выставить подходящую зону, пусть и не имеющую отношения к Украине.
badiceandima, может они тупо закрылись или уехали на праздники ? от них хоть какая нибудь реакция на запросы есть?
в общем случае отнять домен будет очень сложно.
Скорее всего вам оставили php-шелл, который позволяет менять файлы просто обращаясь к этому скрипту, а не через ftp.
Поставить могли в один момент времени, хоть год назад, а пользоваться начать в другой. Так что нельзя уверенно установить связь между временем модификации файлов и взломом.
Каждый хакер стремится выдумать что-нибудь свое в данном вопросе для затруднения очистки. В том, что вы не нашли похожих случаев нет ничего удивительного.
Общих рецептов не так много можно придумать .
Для начала, если у вас vps, попробуйте "стабилизировать" все файлы отдав их в собственность root (chown) и запретив модификацию (chmod). Ужасно некрасиво, но что-то же надо делать.
Иногда помогает пройтись по всем файлам сайта обычным десктопным антивирусом. Они могут находить и веб-шеллы.
Чтобы имитировать заход из google, можно в первых строчках скрипта изменить переменные $_SERVER. Другой информации о посетителе вредоносному коду на php просто неоткуда взять.
Не менее важный вопрос найти каким образом этот веб-шелл возник. Если через ftp - это еще считайте повезло. Просто поменяете пароль. Но если через логическую проблему в коде сайта, то никаких рецептов уже не выписать. Нужно искать эту проблему анализируя действия злоумышленников по логам.
Тут еще местный Андрейка обычно вспоминает про mod_security. При отсутствии других идей и невозможности установить точно каким образом залили шелл, тоже сойдет в качестве защиты. Но в общем случае сайт под mod_security эксплуатировать и разрабатывать неудобно.
скрипты сайта должны знать который сейчас сервер из двух живой и куда им подключаться. если это специально не обрабатывается, при переключении придется править как минимум файлы-конфиги сайтов
А клиент готов менять код всех сайтов для переключения между серверами mysql?
Память имеет значение, потому что при архивации нужные файлы в кеше замещаются считанными архивируемыми и кеш активно вымывается. Если, конечно, об этом не позаботиться специальным скриптом для бекапа.
Когда памяти мало колбасит сам сайт.
собсно, никак. пока mysql живет на отдельной машине - это единая точка сбоя.
раз уж проекты реально отдельные, то перенеси 8 проектов на одну , 8 проектов на другую на глазок подбирая нагрузку.
потом бери приз и уезжай с этого поля чудес с малыми человеко-часами.
Проблемы с кешем возникают у тех, кто сильно увеличивает query_cache_size до нескольких сотен мегабайт, думая что тем самым повышает шансы на кеширование запроса. У вас вроде не так.
key_buffer = 16M . что так мало ?
А что innodb отключен ? У вас действительно bitrix ? по-моему их рекомендации как раз подразумевали innodb и ряд специальных (немного даже снижающих надежность) настроек для innodb.
Если lock time в этих медленных запросах большой, то однозначно надо переходить на innodb.
"инфоблоки" ведь используются чем попало, в том числе и самописными модулями не из поставки bitrix. может быть там запрос просто не продуман?
Вообще, гадать на форуме дело непродуктивное. Попробуйте что-ли скрипт mysqltuner.pl в качестве советчика, но отнеситесь к советам очень критически.
Не нужно увеличивать бесконечно всякие вторичные кеши, если он продолжает советовать повышать, но вы видите что в поведении сервера ничего не меняется.
