Tracy Perry Posted September 29, 2015 Posted September 29, 2015 Why, when your default engine is InnoDB, and you have converted your existing tables over to InnoDB does IPS insist on using MyISAM for tables that it really doesn't need to? I'm specifically referring to Pages and when you create a new DB instance via it.
Rhett Posted September 29, 2015 Posted September 29, 2015 If your server/hosting supports full text indexes (mysql 5.6+) then it will use innodb if you have that selected, however if you are an older version of mysql, it will use myisam. If that's not happening, then submit a support ticket and we can look into this for you.
Tracy Perry Posted September 29, 2015 Author Posted September 29, 2015 1 hour ago, Rhett said: If your server/hosting supports full text indexes (mysql 5.6+) then it will use innodb if you have that selected, however if you are an older version of mysql, it will use myisam. If that's not happening, then submit a support ticket and we can look into this for you. This is the version I'm running.... so it should support it. [root@whiskey nginx]# mysql -V mysql Ver 15.1 Distrib 10.0.21-MariaDB, for Linux (x86_64) using readline 5.1 When I try to convert it to InnoDB, it gives an error (when doing via PhpMyAdmin - which is the only thing I use it for is this type of simple stuff. I don't use FTP on my server (only sFTP via SSH) so would have to actually set up an SSH account for access - and I'm not comfortable doing that honestly. I was just wondering if anyone else had any issues since InnoDB is not really a "supported" DB engine for IPS apparently since even with InnoDB set up as default engine on my setup it pushed them out as MyISAM and I had to manually convert them.
Rhett Posted September 30, 2015 Posted September 30, 2015 I would file a support ticket on this and we can look into it further for you, phpmyadmin access is fine as well for our team to look at this.
Flitterkill Posted September 30, 2015 Posted September 30, 2015 When you guys get this sussed out could you post a note in the documentation section? I've run across this exact thing with CMS dbs on converting to 4.0/Innodb. Just test installs but when I do go live I;d love to know the solution. I've looked into it somewhat but always nice to have a ready answer on hand.
sudo Posted September 30, 2015 Posted September 30, 2015 This may help: http://mechanics.flite.com/blog/2014/07/29/using-innodb-large-prefix-to-avoid-error-1071/ I think you need to switch to Barracuda storage to fix it first in your mysql server config file: At the database level you have to use innodb_file_format=BARRACUDA At the table level you have to use ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED
Tracy Perry Posted September 30, 2015 Author Posted September 30, 2015 Really shouldn't have to. I know all my other scripts do just fine with creating into InnoDB without forcing MyISAM for most things. The issue is that in the CMS (pages) it (for some reason) insists on MyISAM. 18 hours ago, Flitterkill said: When you guys get this sussed out could you post a note in the documentation section? I've run across this exact thing with CMS dbs on converting to 4.0/Innodb. Just test installs but when I do go live I;d love to know the solution. I've looked into it somewhat but always nice to have a ready answer on hand. Glad to know it's not limited to my setup then... so odds are it IS an IPS related "feature" that forces it. It sounds like it's really targeted towards a MyISAM environment than compatible with InnoDB withough requiring use of Barracuda (which no other script that I use requires) that so it's something to do with the way IPS creates the tables.
sudo Posted September 30, 2015 Posted September 30, 2015 When we went from MyISAM to InnoDB on vBulletin 4 I ran into the same Barracuda problem when restoring the db backup which is why I was aware. Its more an issue for MyISAM designed systems moving across because I dont think they had the problem under MyISAM. Some tables run better under MyISAM than under InnoDB (or that was the case) so they dont really need to be moved across although InnoDB has improved a lot in later versions but InnoDB generally requires more ram for the same data I believe so its not necessary to use it across the board although nice. If you were to use RDS on AWS though the whole dataset needs to be in InnoDB otherwise AWS cant guarantee replication properly.
Tracy Perry Posted October 1, 2015 Author Posted October 1, 2015 RAM is not one of my worries right now... and yes, some tables are better in MyISAM (that's why I have a guide out over at XenForo for those that got stuck with their DB's in in pure MyISAM on what should be converted to InnoDB and what should be left as memory and MyISAM for that script). The issue is the way the indexes are done to assume MyISAM - setting up a barracuda storage when antelope is default should be detailed if required - which I haven't seen it anywhere on the support site.
motomac Posted November 30, 2015 Posted November 30, 2015 Have the same issue. After converting from 3.4 to 4.1 got some MyISAM tables on MariaDB. Before in 3.4 I used only InnoDB. Now I'm trying to convert them from MyISAM back to InnoDB, but I'm not sure that in future new MyISAM tables will not appear. How can I set default table engine in IPS 4.1?
Thomas P Posted December 21, 2015 Posted December 21, 2015 Hello, I don't mean to overtake this topic, but have the same issue - just converting to 4.1 from 3.4.(latest) and see mixed tables, some are InnoDB some were converted to MyISAM. I use MySQL 5.6.x. Why is that? Thank you, Thomas
Recommended Posts
Archived
This topic is now archived and is closed to further replies.