Скорее всего на форум 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 выписанным другим. Главное чтобы тот что официальный работал и если что прошел ручную проверку на предмет выдачи товара. Например, семки должны быть доставлены покупателю в срок
Basic access authentication + сохранение пароля в браузере.
Конец тестирования - офф Basic в .ht и все
Ну во первых "законодательно ходить низзя" это только если полицаи способны зафиксировать факт того что ты туда ходишь.
Во вторых, у нас в Украине хотя и существует такая же диктатура, но до блокировки трекеров пока не додумались.
В четвертых, я имел в виду тупые законы от тупых политиков.
В пятых, конкретно в данном случае мне OpenVPN нужен не для серфинга а для защиты передачи данных на сервак от прослушивания, там gateway не прописывается при подключении :)
Всем спасибо, вопрос закрыт. Не знаю почему с этим моментом
никогда не сталкивался, может просто у других хостеров в дистрибутиве было всегда свежее ядро...
Мистика. После перезагрузки заработал modprobe.
Сколько лет уже имею дурную привычку при заказе VPS делать apt-get upgrade - первый раз вижу такую ботву, хотя OpenVPN ставлю достаточно часто.
в syslog при каждом modprobe появлялось по строке
tun: Unknown symbol ipv6_proxy_select_ident (err 0)
uname -a
Linux VPS 3.2.0-4-686-pae #1 SMP Debian 3.2.63-2 i686 GNU/Linux
после рестарта
Linux VPS 3.2.0-4-686-pae #1 SMP Debian 3.2.73-2+deb7u2 i686 GNU/Linux
