- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Доброго времени суток.
Есть у сайта средне используемая таблица БД. Характер использования - периодически все данные с определенным значением индекса удаляются (до 1/10 строк от общего числа) и заносятся новые, регулярно кто-то что-то из не читает.
Уже 2 раз за этот месяц происходит вылет сайта - заканчивается место на диске.
В каталоге mysql data кроме файлов этой таблицы обнаруживаю кучу их бекапов (*.BAK именно большими буквами) которые и заполняют все место. Таблица занимает приличный объем, потому увеличение места на диске сервера приведет только к увеличению промежутка времени между вылетами.
В логе:
Как бороться с этим бредом?
rm -rf *.BAK в крон - не предлагать, нужно устранить причину.
У вас виртуальный хостинг или сервер свой?
---------- Добавлено 22.04.2016 в 23:59 ----------
Таблицы все myisam ?
Попробуйте обновиться на 5,6
Также проверьте диски, возможно они просто вышли уже из строя или что-то с сервером не так. Какие-то сбои.
Это VPS, за состоянием дисков по идее следит хостер, да и RAID там должен быть.
Просто не вижу проблем с той таблицей, REPAIR работает на ура, спрашивается чего оставлять лишние копии причем в десятке экземпляров.
Читаем описание опции
Для значения "BACKUP" описывается причина такого поведения, как у вас.
;14447909']Читаем описание опции
Для значения "BACKUP" описывается причина такого поведения, как у вас.
Ну я так понимаю надо перевести в режим: FORCE
НО, так не должно быть, надо найти причину падения.
Это по идеии. Опишите ему ситуацию, пусть проверит диск. Ну и mysql как и писал попробуйте обновить, вполне возможно какой-то баг.
Ну я так понимаю надо перевести в режим: FORCE
Скорее, в режим "BACKUP,FORCE"
НО, так не должно быть, надо найти причину падения.
Причина в забивании диска бэкапами.
Причина их появления в том, что в табличку идёт запись в момент починки таблицы.
Нет, причина в том что table is marked as crashed or was not closed properly
как результат - MyISAM запускает Recovery (следствие 1), возможно в этот момент идет запись (второстепенная проблема) и файл бекапа не удаляется после завершения (следствие 2).
Какого черта крашится таблица - не имею понятия, у меня такого никогда не было ни на одном сервере, редкий краш очень часто используемых таблиц при внезапном отключении электропитания или остановке сервера хостером за неуплату разве что.
По проверке диска - создал тикет, гуляю до понедельника.
table is marked as crashed - это следствие.
А вот причина скорее всего - падение мускуля (signal 11 например - segmentation flow).
периодически все данные с определенным значением индекса удаляются (до 1/10 строк от общего числа)
Сразу после этого не пробовали делать чек?
Таблицы бьются по причине отсутствия места на диске.
После чего уже запускается проверка, но т.к. места нет и она не выполняется.
Решите проблему со свободным местом.
Свободного места на диске 3 GB, таблица занимает 300 Мб потолок.
С какого перепугу запускается проверка - остается только гадать.
Место заканчивается ТОЛЬКО после того как таких бекапов наберется десяток.
Веду записи. Файл tablename-160423061542.BAK появился 23.04 06:15
Я его удалил нафиг, сейчас вижу файл tablename-160423061542.BAK датой 23.04 10:15
Как видно, имя то же за 6 утра, а создан в 10 утра вчера. За сегодня пока ничего. Удалил. После того как удалил в прошлый раз всю пачку понял, что нужно было посмотреть на их даты и вычислить периодичность...