Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Quoting Rob Morin <rob at dido.ca>: > > > Rob Morin wrote: >> Hello all, i have heartbeat and drbd working 95% ok, i just have >> this weird issue with users that use InnoDB in mysql. It would seem >> that each time teh secondary takes over i have problems with any >> databases that are InnoDB, form what i found googling it has to do >> with mysql doing a crash recovery check after mysql comes up on the >> failover node... >> >> Can some point me in the right direction to try and resolve this issue? >> >> I am using DRBD version 8.0.7-1 via Debian Etch >> >> Thanks... >> > > I just thought that maybe the mysql logs should be on the DRBD > partition too..... so i will do a test and see what happens, i will > post the results tomorrow... > > Do you mean the InnoDB logs? (ib_logfile0, ib_logfile1, etc?) Yes, those should 100% be on the drbd device. Actually, all your log files probably should be, but those Innodb log files seem most relevant to the issue you've mentioned. They aren't human-readable notes about what's going on (like a syslog or error log), they're a list of transactions that Innodb hasn't yet flushed out to the data files. If MySQL was shut down cleanly (controlled migration) and the log files are missing, Innodb will just re-create them. After a clean shutdown, there are no unflushed transactions, so there's nothing interesting in the logs. Not a big deal. But, it will make startup take a lot longer as the log files are created. In the event of an actual crash of your master (unclean shutdown of MySQL) you must have those files available to get your Innodb data back into a consistent state. alex