Resizing /var partition

nealdxmhost

Verified User
Joined
Jan 1, 2009
Messages
232
Location
Los Angeles CA
I am having trouble with my /var partition at the moment as it is maxed out. I need to either resize it and probably take some space from my /home partition to make that happen or should I add another hard drive to the system maybe move the entire /home partition to it thus freeing up space on the original hard drive.

This is what I have showing currently.

HTML:
[root@cp ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       29G   26G  1.9G  94% /
/dev/mapper/VolGroup00-LogVol02
                      992M   54M  888M   6% /tmp
/dev/mapper/VolGroup00-LogVol04
                      9.5G  9.0G   52M 100% /var
/dev/mapper/VolGroup00-LogVol03
                      9.5G  7.0G  2.1G  78% /usr
/dev/mapper/VolGroup00-LogVol05
                      851G  565G  243G  70% /home
/dev/sda1              99M   27M   68M  29% /boot
tmpfs                1002M     0 1002M   0% /dev/shm

Anyhow I am at a loss on how to fix this without breaking something and I have been getting lost looking online trying to find a solution that I can understand.

Thanks
 
I've never played with volume groups; my understanding is you can take space away from the one containing home and add it to the one with /var.

Or of course add a new drive for /home and move /var to your current /home partition, as you mention.

That said, why is your /var heavily used? Can't you figure out what you don't need, and remove it?

We've got a few old installations with only 10G var partitions, and with a bit of management they do fine.

Are you saving the mysql transactions file? Generally you don't need to do that and my guess is most of us don't.

(Unless of course you're Chase bank, which has been busy over the past few days restoring a database from last week; that's why their online banking has been having problems.)

Jeff
 
I've never played with volume groups; my understanding is you can take space away from the one containing home and add it to the one with /var.

I found an article last last night on that subject of resizing LVM volumes. Seems to be very informative but at the same time I am terrified of doing anything in terms of resizing.

Or of course add a new drive for /home and move /var to your current /home partition, as you mention.
I am currently considering that option of adding a new drive to the system and moving /home over to it. Once again that is something I will be doing with my fingers crossed the entire time

That said, why is your /var heavily used? Can't you figure out what you don't need, and remove it?
Good question! I have a few sites on there running either Wordpress or Joomla so needless to say the MySQL db is rather active and periodically the exim mail queue gets a spike in activity.

We've got a few old installations with only 10G var partitions, and with a bit of management they do fine.
That is the way I went during the initial setup and until recently I have not had any problems with it. Could be something that I am missing somewhere and that is why I post the problems here in case someone else has had the same difficulty as I am having now and has a solution. It is all about learning as we go, and the more I learn the more I realize how much I do not know.

Are you saving the mysql transactions file? Generally you don't need to do that and my guess is most of us don't.

(Unless of course you're Chase bank, which has been busy over the past few days restoring a database from last week; that's why their online banking has been having problems.)

Jeff
I am inclined to believe that I did something somewhere to cause that to happen, but how on earth I did it, I could not recall to save my life. Funny thing when you mention Chase bank, one of my customers does his banking with Chase and he mentioned the other day he was having problems getting his banking info online.
 
Followup on /var

I think I have it fixed, I did the following;
Code:
While in my root directory I did this as a precaution;
[root@cp ~]# mkdir -p var/lib/mysql/
[root@cp ~]# mv /var/lib/mysql/mysql-bin.* var/lib/mysql/

Once that was done, I went ahead and did this;
Code:
[root@cp ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       29G   20G  7.0G  75% /
/dev/mapper/VolGroup00-LogVol02
                      992M   54M  888M   6% /tmp
/dev/mapper/VolGroup00-LogVol04
                      9.5G  1.6G  7.4G  18% /var
/dev/mapper/VolGroup00-LogVol03
                      9.5G  6.6G  2.5G  74% /usr
/dev/mapper/VolGroup00-LogVol05
                      851G  565G  243G  70% /home
/dev/sda1              99M   27M   68M  29% /boot
tmpfs                1002M     0 1002M   0% /dev/shm
[root@cp ~]# /etc/init.d/mysqld restart
Shutting down MySQL... SUCCESS!
Starting MySQL.. SUCCESS!

I ran the df -h command again to see if there was any difference.
[root@cp ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       29G   20G  7.0G  75% /
/dev/mapper/VolGroup00-LogVol02
                      992M   54M  888M   6% /tmp
/dev/mapper/VolGroup00-LogVol04
                      9.5G  1.5G  7.5G  17% /var
/dev/mapper/VolGroup00-LogVol03
                      9.5G  6.6G  2.5G  74% /usr
/dev/mapper/VolGroup00-LogVol05
                      851G  565G  243G  70% /home
/dev/sda1              99M   27M   68M  29% /boot
tmpfs                1002M     0 1002M   0% /dev/shm

Now I need to understand why those transaction files were being created in the first place. Any ideas????

Neal
 
Followup on /var and mysql binary logs

added the following to my.cnf

Code:
expire_logs_days=10

Now I just have to keep an eye on it.

Neal
 
You need to keep your logs about a week after you do a complete backup, at the most.

Jeff
 
You need to keep your logs about a week after you do a complete backup, at the most.

Jeff

That is what I thought, I figured a couple of extra days beyond that just for good measure. In the meantime I will keep a close eye on things over the next couple of weeks to see how the old girl performs.
 
Hmm, is is the logs / MySQL files again? You'd also make a test box with the OS you're running at the moment and reproduce the LVG setup. That way, you can try to resize, and if it goes wrong, you sure as hell don't want to try this in production.

If it isn't the MySQL, you can try something like this
 
Hmm, is is the logs / MySQL files again? You'd also make a test box with the OS you're running at the moment and reproduce the LVG setup. That way, you can try to resize, and if it goes wrong, you sure as hell don't want to try this in production.

If it isn't the MySQL, you can try something like this

It's happening in the MySQL again, it seems like I am getting this about once every 10 days or so and when I run this:
Code:
[root@cp ~]# mv /var/lib/mysql/mysql-bin.* var/lib/mysql/
I can get things back down to a manageable level
This time around I also did this as well;
Code:
[root@cp ~]# mv /var/lib/mysql.backup/ var/lib/
and now I am at this level for disk usage;
Code:
[root@cp ~]# df -kh
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       29G   15G   13G  55% /
/dev/mapper/VolGroup00-LogVol02
                     1008M   84M  874M   9% /tmp
/dev/mapper/VolGroup00-LogVol04
                      9.5G  2.9G  6.2G  32% /var [COLOR="Red"][B](before I did this /var was at 100%)[/B][/COLOR]
/dev/mapper/VolGroup00-LogVol03
                      9.5G  7.4G  1.7G  83% /usr
/dev/mapper/VolGroup00-LogVol05
                      851G  680G  127G  85% /home
/dev/sda1              99M   27M   68M  29% /boot
tmpfs                1002M     0 1002M   0% /dev/shm
/var/tmpMnt          1008M   84M  874M   9% /tmp

Anyhow the mystery continues
 
Back
Top