Recovering mysql data - mysqlbinlog

[Mel]

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.

-- 
Mel

Problem with today's modular software: they start with the modules
    and never get to the software part.