The heap/memory tables seem ideal for the users online table. How many other tables are there that get corrupted and are they as suitable for heap/memory? Are they all just temp data tables?
Were the performance issues related to the time earlier this year when RAM was inadequate? Would you expect the increased RAM to accommodate the increase in memory use after converting the tables or will still more RAM be needed?
What are the pros/cons of a Mysql slave? Would it facilitate a faster recovery in the event of a primary database outage? Would you need an extra level of network infrastructure to detect and switch to the slave if an automated switchover were to occur?
The heap/memory tables will only take up a few hundred kilobytes, not enough to worry about. We can only convert the tables that have temporary data in them, and even then, we will only bother with tables that are very active. Performance was ram related earlier this year, we have enough ram free to allocate some to a heap table, this wont be a problem.
A slave database is running on a different server, every time an update occurs, the update gets replicated across to the slave giving us a database backup that is current as of the crash/failure of the master server. This means that in the event of data loss, we can recover pretty much up to the second of the outage, instead of X hours ago when the last backup was performed. This is not the only function of a slave database instance, but it would suit Dave's requirements quite nicely. Obviously we will still need to perform daily backups of the database in case a bad SQL statement is executed which gets replicated to the slave.