(Apologies to the rare bottom-poster.)
This contains lots of tips on converting from MyISAM to InnoDB:
http://mysql.rjweb.org/doc.php/myisam2innodb
Generally, the conversion should go smoothly.
> -----Original Message-----
> From: Reindl Harald [mailto:h.reindl@stripped]
> Sent: Friday, September 21, 2012 7:11 AM
> To: mysql@stripped
> Subject: Re: Risks involved in MyISAM to Innodb
>
> do NOT top-post which makes threads unreadable
>
> Am 21.09.2012 15:55, schrieb Girish Talluru:
> > On Fri, Sep 21, 2012 at 6:44 AM, Reindl Harald
> <h.reindl@stripped <mailto:h.reindl@stripped>> wrote:
> > Am 21.09.2012 15:26, schrieb Girish Talluru:
> > > I have requirement to change my production database tables
> which are using
> > > myISAM and now bcoz of some changes we have to move to Innodb.
> > >
> > > Can anyone suggest how the plan should be and risks involve?
> >
> > no because this depends hardly on your data and what the
> application
> > does - many things may be faster, some like "select count(*)
> from"
> > are unacceptable slow if they are called often
> >
> > however, it is the wrong way to ask foreign people such questions
> >
> > * try the migration on a staging server
> > * test your application under load on the staging server
> >
> > if no staging server exists you have done something terrible
> wrong
>
> > I'm sorry if I ask wrong question here?
>
> you did not ask any question because without knowing what type of
> queries on what type of data the application makes no answer is
> possible
>
> > At this stage we have to migrate to innodb but as a new guy they
> > assigned me to get the risks document ready for migration
>
> and that is why i said "try the migration on a staging server"
>
> setup a virtual machine for testing and look with snapshots how it
> behaves - any "paper" before is useless
>
> since MyISAM has no foreign keys it should be easy to change the table
> types, the other direction would be more painful
>
>