Рабочий день медленно, но верно подходил к концу.
Солнечный свет струился сквозь жалюзи и наполнил кабинет золотисто-малиновым светом.
Где-то в углу жужжала кофемашина, выжимая остатки кофе из капсулы.
Наш проект оживленно обсуждался с дизайнером, и я исправлял ошибки, любезно оставленные мне младшим программистом.
И всё казалось бы хорошо, если бы не сообщение: «Что не так с вашим сайтом ТЭ» Мой хороший друг заметил, что один из наших сайтов отображается неправильно, и сообщил мне об этом.
Я бросил все и загрузил страницу сайта.
Никаких проблем с этим не было.
Ну разве что понадобился небольшой редизайн.
«С сайтом все хорошо», — написал я другу и снова окунулся в увлекательный мир кода и ошибок.
Через какое-то время мой мозг окончательно выкинул из памяти сигнал тревоги моего друга, и я невольно пошел проверить сайт еще раз.
Почему-то, уверенный в работоспособности сайта, я почувствовал легкое чувство уверенности в себе.
Главная страница сайта печально встретила меня ошибочной кодировкой и полным отсутствием CSS. Черные символы абракадабры на девственно белом фоне вернули меня в реальность.
Моя уверенность в себе мгновенно исчезла, и я начал лихорадочно нажимать CTRL+F5 на клавиатуре.
«Это просто тайник.
Да.
Это просто тайник.
» — повторял я про себя снова и снова.
Когда я понял, что моя десятая попытка сбросить кэш браузера не дала никаких результатов, а главная страница сайта продолжала менять свой внешний вид при каждом нажатии заветных клавиш, первое, что промелькнуло у меня в голове, было «Взлом? !” Мои опасения начали усиливаться, когда после очередной перезагрузки страницы я увидел красно-белую надпись, гласившую, что такая-то таблица не найдена.
Руки сами стали менять все доступы, связанные с сайтом: админка, база данных, SSH. После этого я начал внимательно изучать логи.
Хотя логи – это громкое слово.
В моем распоряжении были только отчеты о работе веб-сервера.
На виртуальном хостинге не предоставляются журналы сбоев MySQL и неудачных попыток входа через SSH. Ничего странного в логах обнаружено не было и я сразу перешел к SSH-консоли, чтобы напрямую подключиться к MySQL, поскольку четко помню, что сайт жаловался на отсутствие таблиц в базе данных.
Очень странно, но все таблицы оказались на месте (по крайней мере те, на которые жаловался сайт, точно были на месте).
В качестве CMS на сайте Т используется 1С-Битрикс.
Мы очень любим эту систему и с большим энтузиазмом относимся к ней (за редким исключением).
Каково же было мое удивление, когда, зайдя в настройки сайта, я увидел данные с совершенно не связанного сайта R. Был изменен путь к корню, имя домена и некоторые другие настройки.
Я, ошарашенный, смотрел на монитор круглыми от удивления глазами.
В это же время где-то позади меня уже лилась настойка валерианы из нашего проекта.
Почему-то я нажал F5. То, что произошло после этого, повергло меня в глубочайшее потрясение и уныние.
Настройки сайта вернулись к нормальным значениям.
В этот момент я на мгновение усомнился в адекватности всей IT-индустрии в целом и начал верить в чудеса.
Из ступора меня вывел телефонный звонок жены.
Я взял трубку.
Я до сих пор не могу вспомнить, что она мне сказала, потому что ощущение чего-то загадочного не покидало меня и мой мозг лихорадочно пытался найти хоть какое-то объяснение произошедшему.
Я что-то пробормотал в трубку и повесил трубку.
Ну теперь, по крайней мере, я в чем-то уверен.
Уверен, что дома меня ждет много интересной информации о себе.
Но это будет позже, а сейчас нам нужно понять, что происходит. После очередной перезагрузки страницы настроек я снова увидел неправильные значения.
Судя по абсолютному пути к корневой папке веб-сервера, мы прописали настройки сайта, который находился на том же хостинге, что и мы.
Я сразу нашел трубку и позвонил в техподдержку хостинга.
Из разговора стало понятно, что решить наши проблемы они сейчас не в состоянии.
Сотрудник технической поддержки вежливо сообщил мне, что мне следует написать запрос по электронной почте, и мой запрос будет рассмотрен в течение 24 часов в порядке очереди.
После того, как я так же вежливо высказал им все, что думаю о них, я положил трубку и написал им письмо, наполненное эпитетами.
На всякий случай мы также написали письмо в техподдержку 1С-Битрикс.
Мертвую тишину офиса нарушало лишь тиканье больших настенных часов и едва слышный шум системы охлаждения системного блока.
Белоснежные часы круглой формы выполняли в офисе несколько функций.
Во-первых, они были элементом интерьера.
У нас в офисе не так много мебели, ничего лишнего.
Хотя, я совершенно не против купить большой и мягкий диван, чтобы в перерывах между делами можно было полежать с чашечкой кофе в руках и, вытянув ноги, погрузиться в мечты о том, что когда-нибудь мы переедем.
отойти от разработки сайтов и начать разрабатывать самые интересные и, конечно же, инновационные с точки зрения игрового процесса игры.
Во-вторых, эти белоснежные круглые часы выполнили свою функцию – показали время.
Если бы кому-то нужно было узнать время, он непременно обратился бы к этим часам.
У них есть какое-то необъяснимое и почти гипнотическое притяжение.
И никого не волновало, что на смартфоне под рукой или на экране монитора тоже есть часы.
И в этот момент наш педантичный надзиратель неумолимо отсчитывал время каждым шагом секундной стрелки.
И мы все ждали, что вот-вот наш почтовый сервер получит долгожданный ответ от кого-то из техподдержки.
Но письма все еще не было.
Ни о какой работе речи не шло.
Мой мозг, участвуя в работе серого вещества, пытался разгадать эту странную метаморфозу с Т-сайтом.
Понимая, что если посетители увидят сайт в таком состоянии, они явно не обрадуются, я решил закрыть его от общего доступа.
Более того, если есть взлом, то вполне возможно, что на сайте уже полно инъекций с целью кражи куки, а это значит, что посещение этого сайта категорически противопоказано.
После нажатия заветной кнопки в настройках основного модуля сайт погрузился в анабиоз.
Из любопытства я зашёл на сайт R, настройки которого были указаны в настройках нашего сайта.
«Сайт в разработке» был размещен на главной странице сайта R. Мозг попытался установить связь между двумя последними событиями и я снова открыл доступ к Т-сайту.
Вернувшись на сайт R, я увидел, что он тоже восстановил свою работоспособность.
Совпадение или зависимость? Повторив манипуляции в настройках основного модуля, я убедился, что существует зависимость сайта R от нашего сайта T и наоборот. Но как это может быть? Все сайты T и R связаны друг с другом с помощью хостинга.
«Давайте позвоним по телефону, указанному на сайте R, и попробуем объяснить им ситуацию», — неожиданно всем предложил наш проект. Не успели мы ощутить гениальность этой идеи, как вдруг в офисе зазвонил телефон.
На другом конце телефона были ребята, которые разработали сайт R и на данный момент тоже озадачены происходящими событиями.
Они передали мне телефон.
После недолгого разговора выяснилось, что они, как и мы, понятия не имеют о причинах происходящего.
«Видимо на хостинге каким-то непостижимым образом существует символическая связь между двумя нашими базами данных», — предположил я.
Ну какое еще объяснение можно здесь найти? Доступ к обеим базам данных разный, но каким-то странным образом изменения в их базе влияют на нашу и наоборот. «Вы пробовали создать другую базу данныхЭ» - Я продолжил.
«Да, это уже третий», — с грустью в голосе ответили мне на другом конце телефона.
Таким образом, вариант символической ссылки не выдержал критики.
Эти ребята также написали обращение в техподдержку Хостинга.
Мы обменялись именами, номерами Skype и номерами телефонов, договорившись держать друг друга в курсе событий.
Новостей от техподдержки хостинга по-прежнему не было.
Я еще раз набрал их номер и начал объяснять сотруднику техподдержки, что ситуация патовая и такая же проблема наблюдается уже на двух аккаунтах Хостинга.
Ничего вразумительного в ответ я так и не услышал.
В конце бессмысленного и бесплодного разговора я окончательно убедился, что техподдержка Хостинг нам точно не поможет. Ну по крайней мере было понятно, что это не взлом.
С этого момента я перестал полагаться на техподдержку Хостинг и взял все в свои руки.
Что-то мне подсказывало, что ответы на свои вопросы я получу, зайдя в список таблиц через админку 1С-Битрикс.
Ну, по сути, других вариантов, с чего начать поиск, не было.
Я был не менее удивлен, чем раньше, когда обнаружил, что содержимое таблицы b_lang (где хранятся настройки сайта) и содержимое административной страницы настроек сайта различаются.
Что за чертовщина?! Как это может быть?! «Их двое!» - пронеслось у меня в голове.
«Есть два подключения к базе данных» — в этой мысли я все больше убеждался.
Как еще можно объяснить, что админка показывает одно, а содержимое таблиц — другое? Развив эту идею еще немного, я вспомнил постоянные соединения с базой данных .
Хотя, судя по описанию технологии постоянных подключений, они разграничиваются как минимум логином и паролем при подключении к базе, а на сайтах R и T эти данные разные.
И все же, может ли система кэширования как-то запомнить соединение и обслуживать его для двух совершенно разных соединений? К этому моменту я был готов поверить во что угодно.
Функцию постоянных подключений я отключил в настройках 1С-Битрикс и при этом оставил пустым тип кэширования (до этого значение было «APC»).
Я попросил своих товарищей по несчастью сделать то же самое.
Когда все было готово, я нажал F5. Это были самые длинные и волнующие секунды в моей жизни.
Ну, это не может быть так просто.
Наконец страница загрузилась и.
сайт заработал! Сайт R тоже был в порядке.
Был только один способ проверить, все ли в порядке.
Я зашёл в настройки основного модуля и вернул сайт в состояние «В разработке».
Зона Т послушно выполнила эту инструкцию, и площадка R продолжила работу.
Этот факт подсказал нам, что проблема успешно решена и базы данных больше не связаны друг с другом.
Но в чем проблема? Постоянные соединения или кэширование? Нам удалось выяснить, что проблема заключалась в том, что у сайтов, никак не связанных друг с другом, был перепутан APC-кеш.
1С-Битрикс в файле dbconn.php принудительно кэширует следующие таблицы:
- b_файл
- b_file_bucket_size
- b_lang
- b_option
- b_lang_domain
- b_site_template
- б_событие
- б_агент
Среди других таблиц здесь хорошо виден тот самый b_lang, где хранятся настройки сайта.
Следовательно, сайты T и R поочередно записывали данные в эту таблицу и кэшировали их в APC. Когда сайт R кэшировал таблицу, сайт T забирал кэшированную копию и наоборот. Но вот самый главный вопрос: как можно смешивать кэш на хостинге с тысячами рабочих аккаунтов? Ведь получается, что любой сайт, использующий APC, может нарушить работу любого (почти) другого сайта (тоже использующего APC) в пределах данного хостинга (точнее, сервера).
Результат — потери из-за простоя сайта и, возможно, кражи данных, поскольку кешировать можно что угодно.
Действительно ли такая логика хостинга нормальна? После небольшого обсуждения с разработчиками сайта R мы пришли к выводу, что можно просто установить для наших сайтов разные BX_CACHE_SID. Очевидно, что существует определенная проблема, так как сайт Т проработал на этом хостинге около полутора лет и не вызвал никаких нареканий подобного характера.
И тут вдруг такой случай.
Почему наш кеш смешался с сайтом R? Почему на таком большом хостинге нет механизмов разделения кэша разных аккаунтов? С этими вопросами я пошел домой.
Они не выходили из моей головы до вечера.
На пороге меня тепло встретила уже соскучившаяся по мне жена, а на столе стоял горячий и вкусно пахнущий ужин.
«Это недоразумение закончилось», — с облегчением подумал я.
Да, когда-нибудь мы обязательно займёмся играми.
УПД 1: Рассмотрев комментарии, я пришел к выводу, что необходимо дать краткое изложение всего вышеизложенного.
Всегда устанавливайте уникальный идентификатор кэша и регулярно делайте резервные копии.
УПД 2: В результате общения с техподдержкой Хостинга выяснилось, что они вообще не предоставляют услугу разделения кэша аккаунта.
Нам дали контакты директора службы техподдержки, которому вы можете направить свои пожелания по работе хостинга.
УПД 3: Руководитель службы техподдержки хостинга поделился со мной замечательной информацией о том, что сейчас они разрабатывают новую среду хостинга, которая будет обеспечивать разделение кешей аккаунтов.
Теги: #php #кэш #APC #MySQL #bitrix #php #MySQL #1С-Битрикс
-
Акции Tesla Пошли На Попятную
19 Oct, 24 -
«341». Часть 2
19 Oct, 24 -
Msi Wind В России – От 9999 Рублей.
19 Oct, 24 -
Пиратство!?
19 Oct, 24
