marenda, может пусть панель перезаписывает конфиг ? наверняка там есть способ изменять значения через панель.
Что-то кончились идеи. Ну разве что права на запись файлов есть, а на чтение нет.
Может админа нанять, чтобы посмотрел настройки и прочее на месте ?
ну тогда mysql при старте чего-то ругается в логи? что там?
marenda, странно. а вы не путаете файлы данных и файлы логов?
в любом случае, советую ту же схему - дамп, изменение параметров, восстановление.
не забывайте только про inndb в других базах, ведь там в одном файле хранятся данных из всех баз.
Что-то меняли в innodb_data_file_path ? Попробуйте снять дамп, позволить таки mysql создать новые файлы и закатить дамп назад.
Pilat, я специально отметил про 3 дня простоя. За 3 дня можно заметить. А если не заметят, то такой сайт им вообще не нужен.
И не править ручками зоны, а запустить по кнопке предварительно продуманную процедуру активации.
Pilat, ну почему же? Если опасаетесь преждевременного срабатывания автоматики, то можно в ручном режиме это делать. Владелец сайта замечает неполадки, оценивает масштаб проблем и состояние сетей (спрашивает у друзей работает ли у них инет, звонит в датацентр) и принимает Экспертное Решение . После чего заходит на оставшийся в живых сервер и жмет там кнопку ( к вопросу о кнопках и webmin).
Уж точно не 3 дня проваляется.
Перегрузить то сможете? На дешевом VPS mysql, как самый большой процесс, мог быть убит из-за нехватки памяти.
Перезагрузка действенная и простая методика. В вашем случае еще и единственная.
Pilat , ну знаете. Вот у меня уже два часа валяется часть недешевого такого датацентра stack. пока терпим.
может быть у вас две разных проблемы и обе приводят к 504 ? избавились от одной (Too many open files) , но не от другой.
Попробуйте теперь поднять значение net.core.somaxconn до 1024 ( это там же в sysctl) и снова перевести на fastcgi.
