Recovering mysql data - mysqlbinlog
fbsd.questions at rachie.is-a-geek.net
Thu May 1 19:52:09 UTC 2008
On Thursday 01 May 2008 21:13:41 John wrote:
> Thank you Mel and Paul for the suggestions. From what I understand the
> general query log is more for debugging and the binary log is for point in
> time recovery and replication. I'll be adding a my.cnf file (using the
> my-large.cnf as a skeleton) soon. I'm glad the issue was caught earlier on
> and now I'm the wiser thanks to you guys. I wonder why the default is no.
> I can't think of anyone who wouldn't find the binary logging beneficial.
I can think of a reason for FreeBSD. The binary logs are never deleted and
upon every server restart a new one is created. If you're like me, developing
on a laptop with a webenvironment including 'Mysql server', shutting down
your laptop daily, you quickly find yourself having full /var partition.
People running dedicated or semi-dedicated MySQL installations, are encouraged
to tweak their installation anyway. The most common ones being:
- put the binary logs on a large enough disk, if possible a seperate disk
all together for performance.
- by default, /tmp is used for temporary sorting tables, when JOINs demand it.
If that's a small partition or worse a 64MB memory disk, expect to get in
trouble, system wide. Use the tmpdir configuration variable.
- thread_concurrency as indicated in the templates
- skip-networking for security if all traffic is local
- sort and key buffer + max_connections to limit/max out memory usage.
Problem with today's modular software: they start with the modules
and never get to the software part.
More information about the freebsd-questions