Коллеги приветствую!
Столкнулся с неприятной и непонятной ситуацией. При тестовом обновлении Zabbix до 6 версии очистка базы данных от значений неактивных item-ов прошла успешно и свободное место увеличилось. Запустив обновление на свежем клоне столкнулся с тем, что очень быстро при выполнении тех же самых скриптов заканчивается свободное место, причем даже не тогда, когда OPTIMIZE создает временную таблицу, а когда выполняется DELETE FROM. При этом графики в WORKBENCH показывали, что операции чтения-записи в таблицу продолжаются с той же скоростью даже при 0 свободного места. В логах чисто. Раздувался файл ibdata1.
"Файл ibdata1 является частью InnoDB, и хранит в себе данные таблиц, их индексы и другую служебную информацию. Со временем этот файл может увеличиться до совсем неприличных размеров. Что бы упростить работу с этим файлов можно разделить его, создав отдельный файл для каждой базы данных и таблицы, с помощью опции innodb_file_per_table. В MySQL версии 5.6 и выше эта опция включена по-умолчанию."
На момент создания клона его размер составлял 5 Гб. Версия MySQL 5.7.37, опция innodb_file_per_table включена. Изучил кучу мануалов, где говориться одно - этот файл может только расти и физически не умеет уменьшаться в размерах. Лечение - дамп всей базы, удаление файла и загрузка дампа обратно, затем включение innodb_file_per_table.
Но почему он раздувается? Как так? Все ведь было нормально на тестовом клоне? Сначала думал, что не заметил роста этого файла, так как он компенсировался высвобожденным местом. Ох и повеселился я с созданием - заливкой данных, но на самую большую таблицу history_uint весом в 350 Гб этого оказалось недостаточно. Начал еще раз проверять свои записи, все делал по шагам. Единственное, что изменил порядок выполнения шага, на котором настраивал в файерволе блокировку всех пакетов в цепочке OUTPUT, так как сервер мониторинга на клоне был сразу остановлен и IP-адрес изменен.
Сегодня, на вновь созданном клоне я запустил очистку только после настройки файервола и ibdata1 не изменился ни на байт! Правда еще не дошла очередь самой большой таблицы, но уже очевидно, что дело не в ней, а в странном поведении MySQL, объяснения которому я не нашел.
Столкнулся с неприятной и непонятной ситуацией. При тестовом обновлении Zabbix до 6 версии очистка базы данных от значений неактивных item-ов прошла успешно и свободное место увеличилось. Запустив обновление на свежем клоне столкнулся с тем, что очень быстро при выполнении тех же самых скриптов заканчивается свободное место, причем даже не тогда, когда OPTIMIZE создает временную таблицу, а когда выполняется DELETE FROM. При этом графики в WORKBENCH показывали, что операции чтения-записи в таблицу продолжаются с той же скоростью даже при 0 свободного места. В логах чисто. Раздувался файл ibdata1.
"Файл ibdata1 является частью InnoDB, и хранит в себе данные таблиц, их индексы и другую служебную информацию. Со временем этот файл может увеличиться до совсем неприличных размеров. Что бы упростить работу с этим файлов можно разделить его, создав отдельный файл для каждой базы данных и таблицы, с помощью опции innodb_file_per_table. В MySQL версии 5.6 и выше эта опция включена по-умолчанию."
На момент создания клона его размер составлял 5 Гб. Версия MySQL 5.7.37, опция innodb_file_per_table включена. Изучил кучу мануалов, где говориться одно - этот файл может только расти и физически не умеет уменьшаться в размерах. Лечение - дамп всей базы, удаление файла и загрузка дампа обратно, затем включение innodb_file_per_table.
Но почему он раздувается? Как так? Все ведь было нормально на тестовом клоне? Сначала думал, что не заметил роста этого файла, так как он компенсировался высвобожденным местом. Ох и повеселился я с созданием - заливкой данных, но на самую большую таблицу history_uint весом в 350 Гб этого оказалось недостаточно. Начал еще раз проверять свои записи, все делал по шагам. Единственное, что изменил порядок выполнения шага, на котором настраивал в файерволе блокировку всех пакетов в цепочке OUTPUT, так как сервер мониторинга на клоне был сразу остановлен и IP-адрес изменен.
Сегодня, на вновь созданном клоне я запустил очистку только после настройки файервола и ibdata1 не изменился ни на байт! Правда еще не дошла очередь самой большой таблицы, но уже очевидно, что дело не в ней, а в странном поведении MySQL, объяснения которому я не нашел.
Comment