I definitely agree with Hassan. Moving the MySQL binaries over is definitely easy to do, but if the versions of MySQL don't match precisely you could be asking for trouble. The safe option is to just use mysqldump to create a backup and then import it on the new db.
On Nov 12, 10:00 am, "Hassan Schroeder" <[EMAIL PROTECTED]> wrote: > On Wed, Nov 12, 2008 at 8:36 AM, Jeff Pritchard > > <[EMAIL PROTECTED]> wrote: > > What is the easiest way to duplicate the production database on the new > > server? How careful do I need to be about major/minor version numbers > > on the mysql server software on both ends? > > It could be significant (4.x -> 5.x, for instance). You would probably > be well-advised to get the version numbers, read the change notes, > *and* ask on a MySQL-specific mailing list. > > Regardless, I would *never* move binary files between systems; the > mysqldump program works just fine, and insulates you from platform > differences. And gives you a backup file at the same time, just in case. > > The biggest gotcha I've personally run into moving from one instance > to another is encoding. Run > > mysql> show variables like '%char%'; > mysql> show variables like '%collation%'; > > on each instance and set appropriately. You probably also want to > compare the defaults for `old_passwords` and `storage_engine`, at > least. Compare the config file(s) as well. > > HTH, and good luck, > -- > Hassan Schroeder ------------------------ [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Deploying Rails" group. To post to this group, send email to rubyonrails-deployment@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment?hl=en -~----------~----~----~----~------~----~------~--~---
