handling mysql binlog data
eagletree at hughes.net
Fri May 2 19:03:09 UTC 2008
On May 2, 2008, at 9:28 AM, Zbigniew Szalbot wrote:
> Hi Chris,
> Chris Pratt pisze:
>>> Thank you anyway - this was very helpful and I instantly saved a
>>> lot of space on a shrinking /var partition!
>> I find it most comfortable to do this manually so I can check
>> my backups first. There is an example in the reply comments
>> below the documentation on the 5.0 version of the mysql
>> doc page that shows a "unix" way to set up a cron script
>> and automate the process. I've not tried it.
>> Shrinking /var partition?: I found the ports setup of mysql to
>> be overly restrictive by using the /var method. It was simple
>> to install, shutdown mysqld, copy the contents of the /var
>> database files (preserving the appropriate ownership and
>> permissions). I then added (assuming /usr is your large
>> to /etc/rc.conf and restarted. It is an outage but it helped given
>> I'd never have thought to size /var anywhere near what a
>> medium size database required.
> Yeah, I am in the same boat so to say... I guess copying mysql data
> using cp -p will preserve all the file attributes?
I didn't do that so I can't say. I actually tarred and untarred.
> Will any future upgrade (by means of portupgrade) not change the
> custom mysql location back to /var/db/mysql?
I ran through portupgrade on both systems twice but
I can't recall if mysql was updated. Given the change
is in /etc/rc.conf, the upgrade shouldn't have an impact.
If an upgrade uses a supplied script to alter the installation
I'd presume it would be an issue. Usually you can provide
these directories as command line options on scripts
provided with mysql.
The saving grace is that since you are not hurting your
original installation, a trial run is rather simple, falling back
is as pretty much a vi /etc/rc.conf and a reboot.
> Thanks again Chris!
> Zbigniew Szalbot
More information about the freebsd-questions