InnoDB Support (mandatory?)

RT Developers
1

Is it possible to disable the need for InnoDB support
in the 3.4.5 version of RT? If it is not what would be
the last version of RT that did not need it be?

Thanks
Winn Johnston

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

2

Is it possible to disable the need for InnoDB support
in the 3.4.5 version of RT? If it is not what would be
the last version of RT that did not need it be?

It would be a poor idea to run RT on MySQL without InnoDB. Why are you
looking to avoid it?

Jesse

3

Is it possible to disable the need for InnoDB
support
in the 3.4.5 version of RT? If it is not what
would be
the last version of RT that did not need it be?

It would be a poor idea to run RT on MySQL without
InnoDB. Why are you
looking to avoid it?

Jesse

Thanks
Winn Johnston

Devel Group,

My superviser has an issue with InnoDB, please take a
second and view his note…

<superviser’s note>
MyISAM remains MySQL’s default choice regardless of
InnoDB being available in it for years.
Oracle bought Innobase, the company that owns InnoDB,
calling in to question its long-term viability in
Oracle’s competitor MySQL.
We use multiple terrabytes of mysql databases and have
had better resiliance from MyISAM.

I’m not looking for unsubstantiated opinions about the
general technical merits of InnoDB versus MyISAM; the
subject has been beaten to death. I want to know what,
specifically, will malfunction or work suboptimally in
RT if MyISAM is chosen instead of InnoDB.

-Bill

</superviser note>

His specific question is “I want to know what,
specifically, will malfunction or work suboptimally in
RT if MyISAM is chosen instead of InnoDB?”

Thanks In Advance
Winn Johnston

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

4

Is it possible to disable the need for InnoDB
support
in the 3.4.5 version of RT? If it is not what
would be
the last version of RT that did not need it be?

It would be a poor idea to run RT on MySQL without
InnoDB. Why are you
looking to avoid it?

Jesse

Thanks
Winn Johnston

Devel Group,

My superviser has an issue with InnoDB, please take a
second and view his note…

<superviser’s note>
MyISAM remains MySQL’s default choice regardless of
InnoDB being available in it for years.
Oracle bought Innobase, the company that owns InnoDB,
calling in to question its long-term viability in
Oracle’s competitor MySQL.
We use multiple terrabytes of mysql databases and have
had better resiliance from MyISAM.

I’m not looking for unsubstantiated opinions about the
general technical merits of InnoDB versus MyISAM; the
subject has been beaten to death. I want to know what,
specifically, will malfunction or work suboptimally in
RT if MyISAM is chosen instead of InnoDB.

-Bill

</superviser note>

His specific question is “I want to know what,
specifically, will malfunction or work suboptimally in
RT if MyISAM is chosen instead of InnoDB?”
RT uses transactions, there is several critical sections in RT that
fail if you have no transactions support. InnoDB tables has support
for transactions. That’s all.

Thanks In Advance
Winn Johnston

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

List info: The rt-devel Archives

Best Practical is hiring! Come hack Perl for us: Careers — Best Practical Solutions

Best regards, Ruslan.

5

Winn Johnston wrote:

Devel Group,

My superviser has an issue with InnoDB, please take a
second and view his note…

<superviser’s note>
…

</superviser note>

His specific question is “I want to know what,
specifically, will malfunction or work suboptimally in
RT if MyISAM is chosen instead of InnoDB?”

I don’t know about that (I use Postgresql) , but unless Jesse protests,
I’d say: if you don’t trust InnoDB, use PostgreSQL.
I haven’t seen any issues, yet - but I only have 1100 tickets until now.
MySQL is a strange animal - but as BP seems to trust it, I would, too,
eventually (if I had to ).
Of course, I hope that PostgreSQL is equally well supported.

cheers,
Rainer

6

<superviser’s note>
MyISAM remains MySQL’s default choice regardless of
InnoDB being available in it for years.

. . .this suggests that the table types are functionally equivalent.
They’re not. MyISAM doesn’t support transactions, and never will.

Oracle bought Innobase, the company that owns InnoDB,
calling in to question its long-term viability in
Oracle’s competitor MySQL.

MySQL claims they’re going to build a table handler that is
functionally equivalent to InnoDB. I’ve also been hearing rumours
that Oracle is ready to license this to MySQL AB under the same old
terms, although I haven’t found proof of that. But if you’re using
MySQL under the GPL (which you oughta be able to do with RT), then in
principle you should be able to use InnoDB tables anyway, since
InnoDB is already released under the GPL. It’s only if you are
required to use the commercial license of MySQL that you get in
trouble. (The bizarre claims of MySQL AB about the reach of the GPL
is the reason I insisted we stop using MySQL when I had the
opportunity to decide this, though. We moved our RT to PostgreSQL,
and though it was a little rocky, it’s turned out well in the most
recent release. We were already big PostgreSQL users, though.)

We use multiple terrabytes of mysql databases and have
had better resiliance from MyISAM.

How can you tell? :wink:

I’m not looking for unsubstantiated opinions about the
general technical merits of InnoDB versus MyISAM; the
subject has been beaten to death. I want to know what,
specifically, will malfunction or work suboptimally in
RT if MyISAM is chosen instead of InnoDB.

BEGIN; do work; COMMIT. It doesn’t work under MyISAM. (That this
should be news to your supervisor is more than a little alarming; but
I’ll leave the ACID flamewar to others.)

A

Andrew Sullivan | ajs@crankycanuck.ca
Information security isn’t a technological problem. It’s an economics
problem.
–Bruce Schneier

7

<superviser’s note>
MyISAM remains MySQL’s default choice regardless of
InnoDB being available in it for years.
Oracle bought Innobase, the company that owns InnoDB,
calling in to question its long-term viability in
Oracle’s competitor MySQL.

MySQL has just extended the contract regarding innodb with Oracle:

http://www.theopenforce.com/2006/04/thank_you_ken_j.html

So, if that runs out, an alternative will be available. You can be
fairly sure MySQL is working on this.

Regards,
Harald

harald wagener
technischer leiter

fcb wilkens
an der alster 42
20099 hamburg
germany

t. +49 (0)40 2881-1252
f. +49 (0)40 2881-1217
m. +49 (0)172 4030-964
hwagener@hamburg.fcb.com
http://www.footeconebelding.de

8

Thank you all for your replies, they have been very
helpfull :slight_smile:

How do you recomend backing up and moving the
database. I have been using the mysqldump then scp it
to the new machine and invoking the mysql < backup.sql

However i am a little wearey about this process,
becuase of some strange occurences. The
CachedGroupMembers table is much longer on the old
machine. After i carried the db over, then upgraded
using make update, and finally ran the ACL, SCHEMA,
and INSERTs that were left in the /etc/upgrade/
directory.

Should i shut down the database before moving the
information? Should i copy it on the file level? How
is the CachedGroupMembers table built?

Thanks Again
Winn Johnston

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around