InnoDB provides MySQL with a transaction-safe (ACID compliant) storage engine that has commit, rollback, and crash recovery capabilities. However, it cannot do so if the underlying operating system or hardware does not work as advertised. Many operating systems or disk subsystems may delay or reorder write operations to improve performance. On some operating systems, the very system call that should wait until all unwritten data for a file has been flushed - fsync() - might actually return before the data has been flushed to stable storage. Because of this, an operating system crash or a power outage may destroy recently committed data, or in the worst case, even corrupt the database because of write operations having been reordered. If data integrity is important to you, you should perform some "pull-the-plug" tests before using anything in production. On Mac OS X 10.3 and up, InnoDB uses a special fcntl() file flush method. Under Linux, it is advisable to disable the write-back cache.[http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html]
In ubuntu server, it is ON by default
hdparm -W0 /dev/hda1
Beware that some drives or disk controllers may be unable to disable the write-back cache.
These changes will NOT be saved on reboot. You must edit /etc/hdparm.conf. Also If you have a raid, hdparm works on the actual drives (/dev/sda1) not the raid drives (/dev/md0)...
So to disable write-cache for my raid5 on boot, just add this to the end of /etc/hdparm.conf
#mReschke for mysql optimization, see mreschke topic#108 /dev/sda3 { write_cache = off } /dev/sdb3 { write_cache = off } /dev/sdc3 { write_cache = off }
The mysql log files in /var/log/mysql can sometimes grow out of control. You can manage them with your /etc/mysql/my.cnf
expire_logs_days = x max_bindlog_size = xxM
