I have done a fresh installation of RT 3.8.4, and have done no
modifications of any sort to the default installation…and was
preparing to do my database backup (using mysqldump),and noticed the
only table that has a MyISAM engine is the ‘Sessions’ Table (the rest
are all InnoDB as expected).
My understanding is that all of these tables were to have been of the
InnoDB engine type (RT’s transaction-based requirements/
recommendations).
- Is this by design, or due to an unresolved bug?
- If this is due to a bug, what is the remedy?
- If this is by design, what steps need to be taken when it comes to
MySQL backup, as I will have a combination of InnoDB and MyISAM based
tables. Note: Per MySQL documentations, InnoDB tables need to be
backed up with ‘–single-transaction’ flag of mysqldump, and MyISAM
tables need to be backed up with ‘lock-tables’…and the two
mentioned flags are mutually exclusive (http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html
).
My Environment:
RT 3.8.4
Mac OS X 10.5.8
MySQL 5.1.37
Apache/2.2.13 (Unix) mod_perl/2.0.4 Perl/v5.8.8 configured
Thanks,
Behzad
I have done a fresh installation of RT 3.8.4, and have done no
modifications of any sort to the default installation…and was
preparing to do my database backup (using mysqldump),and noticed the
only table that has a MyISAM engine is the ‘Sessions’ Table (the rest
are all InnoDB as expected).
My understanding is that all of these tables were to have been of the
InnoDB engine type (RT’s transaction-based requirements/
recommendations).
- Is this by design, or due to an unresolved bug?
Closer to the former than the latter.
- If this is due to a bug, what is the remedy?
You can use mysql’s standard recipe for converting it to an innodb
table.
- If this is by design, what steps need to be taken when it comes to
MySQL backup, as I will have a combination of InnoDB and MyISAM based
tables. Note: Per MySQL documentations, InnoDB tables need to be
backed up with ‘–single-transaction’ flag of mysqldump, and MyISAM
tables need to be backed up with ‘lock-tables’…and the two
mentioned flags are mutually exclusive
(http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html ).
Bascially, it’s unimportant to back up the sessions table. It’s just
user sessions. The worst case scenario is that your users will need to
log in again after restoring from backup.
I have done a fresh installation of RT 3.8.4, and have done no
modifications of any sort to the default installation…and was
preparing to do my database backup (using mysqldump),and noticed the
only table that has a MyISAM engine is the ‘Sessions’ Table (the rest
are all InnoDB as expected).
My understanding is that all of these tables were to have been of the
InnoDB engine type (RT’s transaction-based requirements/
recommendations).
- Is this by design, or due to an unresolved bug?
Closer to the former than the latter.
What are the benefits of the Sessions table being MyISAM now that InnoDB
read/write throughput is in most cases superior to MyISAM?
Micah
I have done a fresh installation of RT 3.8.4, and have done no
modifications of any sort to the default installation…and was
preparing to do my database backup (using mysqldump),and noticed the
only table that has a MyISAM engine is the ‘Sessions’ Table (the rest
are all InnoDB as expected).
My understanding is that all of these tables were to have been of the
InnoDB engine type (RT’s transaction-based requirements/
recommendations).
- Is this by design, or due to an unresolved bug?
Closer to the former than the latter.
What are the benefits of the Sessions table being MyISAM now that InnoDB
read/write throughput is in most cases superior to MyISAM?
No reason for a long time. Except converting needs upgrade script to
handle existing instances. Also, it’s not trivial to measure real RT
oriented performance impact to force development. Simulating spherical
horses in vacuum is not enough for motivation 
Micah
Best regards, Ruslan.
I have done a fresh installation of RT 3.8.4, and have done no
modifications of any sort to the default installation…and was
preparing to do my database backup (using mysqldump),and noticed the
only table that has a MyISAM engine is the ‘Sessions’ Table (the rest
are all InnoDB as expected).
My understanding is that all of these tables were to have been of the
InnoDB engine type (RT’s transaction-based requirements/
recommendations).
- Is this by design, or due to an unresolved bug?
Closer to the former than the latter.
What are the benefits of the Sessions table being MyISAM now that InnoDB
read/write throughput is in most cases superior to MyISAM?
No reason for a long time. Except converting needs upgrade script to
handle existing instances. Also, it’s not trivial to measure real RT
oriented performance impact to force development. Simulating spherical
horses in vacuum is not enough for motivation
So, it could break future upgrades then?
I have done a fresh installation of RT 3.8.4, and have done no
modifications of any sort to the default installation…and was
preparing to do my database backup (using mysqldump),and noticed the
only table that has a MyISAM engine is the ‘Sessions’ Table (the rest
are all InnoDB as expected).
My understanding is that all of these tables were to have been of the
InnoDB engine type (RT’s transaction-based requirements/
recommendations).
- Is this by design, or due to an unresolved bug?
Closer to the former than the latter.
What are the benefits of the Sessions table being MyISAM now that InnoDB
read/write throughput is in most cases superior to MyISAM?
No reason for a long time. Except converting needs upgrade script to
handle existing instances. Also, it’s not trivial to measure real RT
oriented performance impact to force development. Simulating spherical
horses in vacuum is not enough for motivation
So, it could break future upgrades then?
I do belive several companies use InnoDB for sessions. If we would
implement such change in the core RT then we try to make sure that
upgrade script doesn’t change anything when the table is already
InnoDB. Basicly - it’s ok to switch.
Best regards, Ruslan.