AG
В общем хранил 14 дней бинлоги, но диск никогда так не переполнялся за 2 года
Size: a a a
2021 June 02
AG
Скачок просто бешеный - расхождение от нормы 500гб и судя по времени все за примерно 3 часа
G
Значит на базе были нетипичные нагрузки. Что то архивировали или переносили или копию таблицы делали
G
Запись/удаление на много гигабайтов делали
G
Даже апдейт на 1кк записий текстового поля в 500кб может дать тебе такой эффект
G
Он же каждое изменение в бин-лог пишет
AG
я это так и понял, просто на сервере ~36000 маленьких баз - каждая примерно 6-20МБ
G
Ну открой бинлог и посмотри)
G
Он же читаемый
СК
> просто на сервере ~36000 маленьких баз
G
была какая то консольная утилита. mysqlbinlog что ли
СК
а так да, открыть бинлог да почитать, как минимум конкретная база там будет, и даже конкретные таблицы
но вообще, попробуйте поискать так же конкретный файл таблицы, возможно есть какой-то распухший сверх обычного размера, если у вас все таблички маленькие
но вообще, попробуйте поискать так же конкретный файл таблицы, возможно есть какой-то распухший сверх обычного размера, если у вас все таблички маленькие
AG
был у меня сервак даже с 75000 базами - норм работает .... много крови и пота ушло чтоб все это довести до ума
G
Хз, может в 2007-м это было нормой
G
Но с нынешним развитием виртуализационных технологий держать столько баз на одном хосте
G
Ну хуууй знает
G
крашнется один - упадут все
AG
дорого!!! Гугл ограничивал 12000
базы сами по себе аж до байта оптимизированы, прежде чем переносить на свой сервер тестил Перкона тулзами
базы сами по себе аж до байта оптимизированы, прежде чем переносить на свой сервер тестил Перкона тулзами