On 2020-07-03 20:38, Chaz Vidal wrote: > Thank you for the response Phil, > > We do not have the option of adding disks space to the system now. I do have > a large /var/spool/bacula directory if that helps? > > I don't believe we have any binary log files in this filesystem that's worth > purging. It is the bacula directory and ibadta1 file that is chewing up all > the space: > > /var/lib/mysql# ls -larth > total 125G > drwx------ 2 mysql mysql 4.0K Jul 22 2015 lost@002bfound > -rw-r--r-- 1 mysql mysql 0 Feb 10 19:47 debian-10.3.flag > drwx------ 2 mysql mysql 4.0K Feb 10 19:47 mysql > drwx------ 2 mysql mysql 4.0K Feb 10 19:47 performance_schema > -rw-rw---- 1 mysql mysql 428K Feb 11 14:07 ib_buffer_pool > -rw-r----- 1 mysql mysql 0 Feb 11 14:56 multi-master.info > -rw------- 1 mysql mysql 16 Feb 11 14:56 mysql_upgrade_info > drwx------ 6 mysql mysql 4.0K Feb 11 15:29 . > -rw-rw---- 1 mysql mysql 24K Feb 11 15:29 tc.log > drwxr-xr-x 45 root root 4.0K Feb 17 21:42 .. > drwx------ 2 mysql mysql 4.0K Jun 26 23:54 bacula > -rw-rw---- 1 mysql mysql 88K Jul 3 23:03 aria_log.00000001 > -rw-rw---- 1 mysql mysql 52 Jul 3 23:03 aria_log_control > -rw-rw---- 1 mysql mysql 4.4G Jul 4 08:06 ibtmp1 > -rw-rw---- 1 mysql mysql 120G Jul 4 09:58 ibdata1 > -rw-rw---- 1 mysql mysql 48M Jul 4 09:58 ib_logfile0 > -rw-rw---- 1 mysql mysql 48M Jul 4 09:58 ib_logfile1 > > > I've checked the /etc/mysql/my.cnf config file and there is no line for > innodb_file_per_table which suggests we are not running this? > > And as per your next step then it would have to be the dump and reload > option. > > If so, is the right process to stop bacula, run the dump and restore and > restart bacula? > > Would doing any purging of old jobs help in this matter?
OK, if your filesystem is at 100% you're not going to be able to execute any writes, which means you won't be able to purge jobs. What's that tc.log? Do you need it? You have an aria.log, so you're running MariaDB. Which release? Is this an ext3/4 filesystem? Using the root of an ext3/4 filesystem for MySQL/MariaDB data causes problems because mysqld assumes that any subdirectory of its data directory is a database, and so the ext* filesystem's lost+found directory creates problems. If you have to nuke and repave anyway, you might consider switching the filesystem to XFS. If you have no way to expand the filesystem (say, by adding an LVM extent to it), and no way to free space on it (there's really nothing significant in here to give you any leeway), then your options for compacting your data are pretty much limited to dump-and-reload, but without knowing the extent of fragmentation in the tablespace there's no way to tell whether it will gain you enough to keep operating. If you have a disk-full condition and mysql/mariadb is stopped, it's a pretty safe bet it's already packed everything it can into the global tablespace. You PROBABLY won't recover significant space by a dump-and-reload in this case. Do you have somewhere else on the system where you could allocate a new, larger data directory? -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
