Добавлю в тот же топик. Поскольку не вижу анонсов этого события в сети, на правах новости.
С некоторых пор (ориентировочно, 1-2 неделя мая 2016) Яндекс Бот индексирует не только содержимое веб страниц, но и скачивает и проверяет на вирусы (предположительно Dr.Web) все двоичные файлы с сервера.
В результате этого, на страницах, содержащих ссылки на зараженные файлы, в поиске появляется пометка "По данным Яндекса, на сайте могут быть опасные файлы" (на других страницах сайта ее нет).
В Яндекс.Вебмастер на вкладке Безопасность выводится список зараженных страниц и исполняемых файлов.
Я сейчас разбираюсь с чужим пациентом, но подобное вижу впервые. Не лень же Яндексу траффик расходовать.
Канал то я ограничу когда пойму что оно работает.
С чем может быть связано такое поведение rTorrent на некоторых VPS?
Точно не с виртуализацией, на OpenVZ я уже запускал когда-то.
Более того видал приколы от провайдера когда процесс какая-то зараза саспендила в фон кроном, пришлось тогда переименовать бинарник и все работало. Тут не то, вроде глюк самого торрента
apache 2.4+nginx + vestacp на бюджетный VPS влезет только если без MySQL.
Базу можно при этом подвесить на какой-нибудь хостинг типа 1GB, где анлим баз и они не входят в квоту, а минимальный тариф все равно под что-то заказан. Если же с MySQL - то apache нужно выпилить. Ligttpd+php либо nginx+php-fpm+vesta
Скорее всего на форум phpbb валят боты стадами, автоматическая регистрация, рассылка писем. Рекомендую усложнить капчу или добавить левое поле, о котором боты, заточенные под стандартный движок, не знают.
Лог я в 1м посте приводил.
Проблема, кажется, решена - больше их нет.
поставил BACKUP,FORCE и обновил mysql server. Что именно решило проблему - не уверен. Пока не актуально, всем спасибо
Свободного места на диске 3 GB, таблица занимает 300 Мб потолок.
С какого перепугу запускается проверка - остается только гадать.
Место заканчивается ТОЛЬКО после того как таких бекапов наберется десяток.
Веду записи. Файл tablename-160423061542.BAK появился 23.04 06:15
Я его удалил нафиг, сейчас вижу файл tablename-160423061542.BAK датой 23.04 10:15
Как видно, имя то же за 6 утра, а создан в 10 утра вчера. За сегодня пока ничего. Удалил. После того как удалил в прошлый раз всю пачку понял, что нужно было посмотреть на их даты и вычислить периодичность...
Нет, причина в том что table is marked as crashed or was not closed properly
как результат - MyISAM запускает Recovery (следствие 1), возможно в этот момент идет запись (второстепенная проблема) и файл бекапа не удаляется после завершения (следствие 2).
Какого черта крашится таблица - не имею понятия, у меня такого никогда не было ни на одном сервере, редкий краш очень часто используемых таблиц при внезапном отключении электропитания или остановке сервера хостером за неуплату разве что.
По проверке диска - создал тикет, гуляю до понедельника.
Это VPS, за состоянием дисков по идее следит хостер, да и RAID там должен быть.
Просто не вижу проблем с той таблицей, REPAIR работает на ура, спрашивается чего оставлять лишние копии причем в десятке экземпляров.
Подымал и долгое время использую Master-Slave репликацию MySQL + ручное обновление файловой структуры (скриптов) при модификации кода. Запросы БД на чтение идут на рандомный слейв (преимущественно на тот слейв который стоит на том сервере с которого вызван пхп скрипт), запросы на запись - идут в мастер.
Минусы: репликация периодически падает и подымается не без гемора. Причины падения - неведомые лаги, нехватка места на диске слейва в момент создания бекапа другого проекта, какие-то mysql коллизии в результате чего сбойный запрос летит и все после него перестают выполняться. После поднятия репликации при длительном падении - slave может лечь в состояние DoS как раз из-за репликации (много данных летит по сети или скорость записи на диск упирается в потолок)
ИМХО если на один ВМ будет подключено сразу 2 магазина - ничего не случится. На край один будет работать с order id выписанным другим. Главное чтобы тот что официальный работал и если что прошел ручную проверку на предмет выдачи товара. Например, семки должны быть доставлены покупателю в срок
