Mysql – mariadb won’t start (InnoDB error: space header page consists of zero bytes in data file ./ibdata1)

Yes it is safe to delete the log file once mysqld has been shutdown

In light of this, just perform the following steps:

mysql -uroot -p... -e"SET GLOBAL innodb_fast_shutdown = 0"
service mysql stop
mv /var/lib/mysql/ib_logfile[01] /tmp
service mysql start

Starting up mysqld will recreate ib_logfile0 and ib_logfile1

Give it a Try !!!

UPDATE 2011-10-20 16:40 EDT

It cleanly page out all data in the InnoDB Buffer Pool prior to redoing the Log Files, you should set this option about 1 hour before shutdown:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

By default, innodb_max_dirty_pages_pct is 75 (MySQL 5.5+) or 90 (prior to MySQL 5.5). Setting this to zero keeps the number of dirty pages under 1% of the InnoDB Buffer Pool. Performing service mysql stop does this anyway. In addition, a shutdown will finish up any remaining items in the redo log. To keep to this option just add it to /etc/my.cnf:

[mysqld]
innodb_max_dirty_pages_pct = 0

UPDATE 2013-04-19 16:16 EDT

I updated my answer a little more with innodb_fast_shutdown because I used to restart mysql and stop mysql to do this. Now, this one-step is vital because every transaction uncommitted may have other moving parts within and outside of the InnoDB Transaction Logs (See InnoDB Infrastructure).

Please note that setting innodb_fast_shutdown to 2 would clean the logs out as well but more moving parts still exist and gets picked on Crash Recovery during mysqld's startup. Setting of 0 is best.

Uncommitted data is what the name suggest: uncommitted. This means the transaction that was running failed when MySQL crashed. Therefore the data should not be available because it could cause inconsistent state. Any ACID compliant database should roll back these transactions.

Ib_log files do contain uncommitted changes to the tablespace but chances are these are already checkpointed and overwritten many times.

There is a possibility to get back (some) uncommitted data from the ibdata and the .ibd files. For this you can use something like innodb_ruby to read the pages on disk and the history for each row from undo space. Be aware this will be a tedious work though.

If MySQL was started it will do the cleanup and rollback from the undo space which means pages in .ibd files will get back their original (last committed) state and your undo history will be purged. After this all the uncommitted data is lost for good.

ps.: If you really have transactions running for 10 days fix the application first. Of course this depends on the use case but majority of transactions shouldn't run longer than a couple of seconds.