innoDB

J

jechilt

Verified User
Joined
Jun 21, 2004
Messages
217
I am wanting to run Drupal 6 with civiCRM. In order to run civiCRM, it requires innoDB.
From what I have heard, innoDB is not integrated yet.
Is there an ETA for this to occur?
 
Uhm... I don't know about that feature request, but the page about MySQL in DirectAdmin is very limited and is obviously intended for beginners.
If you must create a database with InnoDB engine, just use phpMyAdmin.
 
InnoDB is a built in engine on MySQL. Just make sure your tables are setup to be InnoDB and that MySQL was compiled with it enabled.
 
jechilt said:
I am wanting to run Drupal 6 with civiCRM. In order to run civiCRM, it requires innoDB.
From what I have heard, innoDB is not integrated yet.
Is there an ETA for this to occur?
Click to expand...

Storage engines such as innoDB are done on a per table basis not per database. Since DirectAdmin does not create the tables DirectAdmin does not need to support any storage engine. DirectAdmin only creates the initial database with no tables.

The installation of Drupal would create the tables and therefore be responsible for enabling innoDB for each table.
 
You are saying innoDB is not required to be implemented into DirectAdmin. I guess I am confused. My current provider says the following:
<snip>
...them (DA) for a while to finish the integration - I don't have an eta or timeline for it's implementation, but we're actively waiting for them to complete it.
<end snip>

Until this happens, I don't get innoDB and my client site has to be installed at another company.
 
Hi, John... haven't seen you post for a while.

My understanding (I could be wrong) is that innoDB (as well as other formats) have to be compiled into MySQL. I believe DirectAdmin uses the MySQL already installed into your server if it's there, otherwise installs it's own.

Hopefully DirectAdmin staff will respond to this thread.

Jeff
 
jechilt said:
You are saying innoDB is not required to be implemented into DirectAdmin. I guess I am confused. My current provider says the following:
<snip>
...them (DA) for a while to finish the integration - I don't have an eta or timeline for it's implementation, but we're actively waiting for them to complete it.
<end snip>

Until this happens, I don't get innoDB and my client site has to be installed at another company.
Click to expand...

jlasman said:
My understanding (I could be wrong) is that innoDB (as well as other formats) have to be compiled into MySQL.
Click to expand...

So I guess if DA did not install MySQL then you may not have innoDB support. But the default MySQL that DA installs does have innoDB support. Its MySQL that has to have the innoDB support not DA. DA does not have anything to do with the storage engine that is used for tables since it does not create any tables at all.

You can use phpMyAdmin to create tables and change the storage engine format after DA creates the blank database. I can speak to this because I have done it. And DA, the control panel itself, has nothing to do with the storage engine for tables.
 
I believe floyd hit it right on.

"What he said" ;)

In addition, when you do the table creation queries, the format can be specified at the end of the query,eg:
Code: 
CREATE TABLE name ( ...your data ... ) TYPE=INNODB;

I googled and found code to change a MyISAM table to InnoDB as well:
Code: 
ALTER TABLE table_name ENGINE = InnoDB

But as floyd mentioned, this isn't related to DA, or even database creation. It's a table level thing, something specified after the database is created. (DBs can probably have a default engine put with it, that could be an option in the my.cnf file for the default engine to use for new DBs)

John
 
Thank you to all who responded. I am hoping for a positive outcome with the server I use.
thanks!
 
The part that screws the pooch for InnoDB is located in the my.cnf optimized file

/etc/my.cnf

it currently says "skip-innodb" ... comment that out to "#skip-innodb" and restart mysql - everything works fine.

This was a stupid issue that never should have happened, IMHO.
 
It turns out it's in our my.cnf files as well. Probably originally gotten from the one posted by DirectAdmin here.

John (of DirectAdmin Support), do you want to make this change?

Jeff
 
That's why you should never copy and paste stuff without knowing what its doing. Everybody has done it but we really shouldn't.

If jechilt had read the my.cnf file instead of just copying and pasting he would have known what the problem was. I am guilty of it too. That is why I didn't know what the problem was either.

skip-innodb is just as plain and simple as it can be.

The machine I was checking on did not have a my.cnf file so that is why I had no problem creating tables with innodb. A lot of my other machines did though.

From know on I am going to do my best to understand what I am pasting.
 
floyd said:
That's why you should never copy and paste stuff without knowing what its doing. Everybody has done it but we really shouldn't.

If jechilt had read the my.cnf file instead of just copying and pasting he would have known what the problem was. I am guilty of it too. That is why I didn't know what the problem was either.

skip-innodb is just as plain and simple as it can be.

The machine I was checking on did not have a my.cnf file so that is why I had no problem creating tables with innodb. A lot of my other machines did though.

From know on I am going to do my best to understand what I am pasting.
Click to expand...

This wasn't an issue with the my.cnf file of the user - this was server wide. He had no access to read the server file.

This my.cnf configuration is supplied by DA, it's also in ELS with the --mysqloptimizedb option, and probably a few other utilities. Admins should take a heads up on this piece of code.

I'd sincerely like to know if a user here developed this - or it was developed by DA before it was distributed. This makes my argument for user support code (distributed by DA without full testing) if it's the former.
 
I did not know that jechilt was just a user and not the administrator.

But it doesn't matter. My point is that we should learn from this and not just paste stuff without knowing what its doing. And I think we are in agreement on this.

configuration is supplied by DA
Click to expand...

Supplied but not installed. We as the administrators have to the choice to use it or not. Its not part of the installation, at least not the installation process I use. If I want to use the my.cnf file supplied by DA I have to intentionally go get it. I have to make a conscious choice to use it. Maybe ELS or Custombuild does it but that's why I don't use them yet.

I am in agreement with you that this should have never happened.
 
Hello,

The /etc/my.cnf that comes with our installs should only look like:
Code: 
[mysqld]
local-infile=0
As for the my-huge.cnf file for mysql 5, it doesn't have the skip-innodb.

For the mysql version pasted into the help file, I will remove the skip-innodb part. When optimizing a server, you always remove bits that you don't need, thus if the assumption is you mainly use MyISAM tables, then removing innodb wouldn't be needed.. but yeah, I'll take it out so it works.
Keep in mind that copy/paste version should only be used for mysql 4 .. and not 5. If you have mysql 5, use the my-huge.cnf or my-large.cnf, or my-medium.cnf... pending on how your system is setup.

John
 
You must log in or register to reply here.
Back
Top