Как предложенный Bill Weiss, хотя более старые файлы сжаты, выполнение zgrep
на них. Можно также использовать tail
видеть требуемые файлы в режиме реального времени:
tail -f /var/log/httpd/access.log | grep "/path/to/file"
или контролировать несколько файлов:
tail -f /var/log/httpd/access.log | grep -E "(/path/to/file|/path/to/other/file)"
Innodb
не передает свободное пространство файловой системе, вместо этого оно будет использоваться в будущих вставках. Если вы используете в своей конфигурации параметр innodb_file_per_table , вы можете освободить свободное пространство, выполнив OPTIMIZE TABLE
. Если не единственный известный мне способ, это экспортировать базу данных, остановить mySQL и вручную удалить файлы данных, а затем снова импортировать базу данных.
Там очень похожий вопрос по SO.
Если возможно, вам следует изменить название своего вопроса: заголовок ссылается на Innodb, но ваш вопрос касается NDB.
В любом случае, когда вы выполняете удаление в NDB, это просто освобождает место в памяти для будущего использования этой таблицей. Если вы хотите действительно освободить его, вы можете выполнить непрерывный перезапуск узлов данных или оптимизировать таблицу (в зависимости от вашей версии). См .: http://docs.oracle.com/cd/E17952_01/refman-5.1-en/mysql-cluster-limitations-limits.html
Соответствующая цитата: «Оператор DELETE в таблице NDB делает память, ранее использовавшуюся удаленными строками, доступной для повторного использования путем вставки только в ту же таблицу. Однако эту память можно сделать доступной для общего повторного использования, выполнив скользящий перезапуск См. Раздел 17.5.5, «Выполнение последовательного перезапуска кластера MySQL».
Начиная с MySQL Cluster NDB 6.3.7, это ограничение можно преодолеть с помощью OPTIMIZE TABLE. См. Раздел 17.1.6.11, «Предыдущий кластер MySQL Проблемы, решенные в MySQL 5.1, MySQL Cluster NDB 6.x и MySQL Cluster NDB 7.x », для получения дополнительной информации.«
Надеюсь, что это поможет.