Jump to content

Insistence on MyISAM


Tracy Perry

Recommended Posts

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. 

Link to comment
Share on other sites

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.

560b17c1e33a8_ScreenShot2015-09-29at4.36

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

560c7ac92a568_ScreenShot2015-09-30at7.12

 

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.

Link to comment
Share on other sites

  • 1 month later...

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?

Link to comment
Share on other sites

  • 3 weeks later...

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...