Comments 10
тоесть я правильно понимаю что каждую минуту одна из системообразующих ваших служб падала с ошибкой, но никого это не настрожило, и никто не заметил, а техподдержка решала проблему клиента
Не совсем так. Миграция из схемы 1 в схему 2 прошла вроде без ошибок, но на самом деле не до конца.
Все службы работали. Не могла завершиться синхронизация узла. Из документации ISP Manager:
Периодически панель проверяет список рассинхронизаций для каждого узла кластера и запускает синхронизацию данных, описанную синхронизатором. Для каждого узла кластера в один момент времени может выполняться синхронизация только одного типа данных, порядок запуска синхронизаторов жёстко определён их приоритетом.
К сожалению, в самой панели, в списке системных уведомлений мы не видим сообщений о том, что какая-то из синхронизаций завершилась с ошибкой. Мы уже сталкивались с зависшими синхронизациями ранее, но в данном случае не было очевидно, где искать виновника.
Эм… а вы разве не мониторите количество 500-х? Скачок на графике сразу же после обновления ISP Manager быстро бы навёл на мысли откуда ноги растут.
Они всё продолжают использовать апач, который надо было выкинуть ещё 10 лет назад.
(хотя я конечно понимаю что статья не об этом; хотя, не будь апача, вы бы не занимались остальными сопуствующими ему костылями и проблема в этом виде возможно и не появилась бы)
Сайт использовал базу данных на сервере Mysql 5.7
сконвертировали базу данных сайта под нативную в Centos 7 версию СУБД 5.5.65-MariaDB
даунгрейдим базу
Как раз, среди этих сообщений были сообщения о прерванном подключении исследуемого сайта. Это дало предположение, о том, что подключение к СУБД выполняется некорректно
По выдуманной причине, ибо те сообщения означают что уже подключённый клиент отвалился (о чём вы и так знали).
Как говорили в одном фильме — «не мы такие, жизнь такая».
«Они» — это почти 99% пользователей shared хостинга.
По вашей логике надо убрать апач и работать лишь с тем 1% с сайтами чисто на статике или без cms, использующих .htaccess?
А еще тут есть персонажи, кто с php 5.4 никак не съедет… а вы говорите апач выкинуть.
Все просто — если у этого хостера не будет нужного клиенту софта, он пойдет к другому.
А автору пожелаю лишь скорей прийти к пониманию, что от сторонних «продуктов» надо уходить. Есть вы и есть клиенты ваши. Они видят проблему и требуют решения именно от вас. Вы же вместо максимально быстрого решения оббиваете чужие пороги — cloudlinux, ispmanager…
По этой причине в своем хостинге изначально решил, что не будет никогда никаких чужих «панелек», в которых поди разберись в случае если что-то пойдет не так. Клиенты будут стоять над тобой и дышать в спину т.к. их не волнуют все эти нюансы. Они лишь видят что у этого хостера что-то не работает, значит пойдем к другому.
Так что весь используемый софт надо знать лично от и до, в точности понимать как и что работает, не надеясь что кто-то другой сделает лучше. Ошибки случаются у всех, но свои ошибки куда быстрей можно обнаружить и исправить.
«Они» — это почти 99% пользователей shared хостинга.
По вашей логике надо убрать апач и работать лишь с тем 1% с сайтами чисто на статике или без cms, использующих .htaccess?
А еще тут есть персонажи, кто с php 5.4 никак не съедет… а вы говорите апач выкинуть.
Все просто — если у этого хостера не будет нужного клиенту софта, он пойдет к другому.
А автору пожелаю лишь скорей прийти к пониманию, что от сторонних «продуктов» надо уходить. Есть вы и есть клиенты ваши. Они видят проблему и требуют решения именно от вас. Вы же вместо максимально быстрого решения оббиваете чужие пороги — cloudlinux, ispmanager…
По этой причине в своем хостинге изначально решил, что не будет никогда никаких чужих «панелек», в которых поди разберись в случае если что-то пойдет не так. Клиенты будут стоять над тобой и дышать в спину т.к. их не волнуют все эти нюансы. Они лишь видят что у этого хостера что-то не работает, значит пойдем к другому.
Так что весь используемый софт надо знать лично от и до, в точности понимать как и что работает, не надеясь что кто-то другой сделает лучше. Ошибки случаются у всех, но свои ошибки куда быстрей можно обнаружить и исправить.
Спасибо за подробный гайд! Столкнулись с такой же проблемой, не могли отловить несколько дней.
Благодаря Вашей статье устранили ошибку.
Благодаря Вашей статье устранили ошибку.
Sign up to leave a comment.
HTTP Error 503. Service Unavailable: случай в поддержке хостинга