|
| Re: InnoDB -> MEMORY Master-Slaves configuration [message #515 is a reply to message #514 ] |
Fri, 29 December 2006 09:18   |
Peter Messages: 405 Registered: August 2006 |
Senior Member Super Guru |
|
|
Hm,
First if you use it mainly for reads and all data fits in memory Innodb tables normally perform already really well eliminating need for in memory tables.
And regarding memory tables and crash what would you expect ? You would need to reclone one way or around.
I would probably do physical clone ie via LVM and then run ALTER TABLE to convert tables to MEMORY before restoring replication.
Peter Zaitsev, MySQL Performance Expert
MySQL Performance Blog - http://www.mysqlperformanceblog.com
MySQL Consulting http://www.mysqlperformanceblog.com/mysql-consulting/
|
|
|
| Re: InnoDB -> MEMORY Master-Slaves configuration [message #516 is a reply to message #514 ] |
Fri, 29 December 2006 09:44  |
delirii Messages: 5 Registered: December 2006 |
Junior Member |
|
|
Thank you for your answer. If I understand, InnoDB tables can be as fast as MEMORY tables for SELECT queries (if the memory is large enough to store all the data) ? At least if the innodb_buffer_pool_size is set correctly ?
So there is no good reason to use a different storage engine on the slave servers (even MyISAM) ? That can be a good news.
Regarding memory tables restoring process, i was thinking about that way :
- export master's data (dump) and save the binary log point right after this export (for instance each night).
When a slave crashes, the only thing to do is to modify the dump file to change the storage engine from Innodb to Memory, restore the dumped data and specify the new binary log point to the slave. Then start the slave (START SLAVE cmd).
Once again, because I'm quite new to all of this, I am still looking for the most robust and fastest solution.
|
|
|