Re: migration of mysql to new server: wired errors

From: Julianony M <juliani.moon_at_gmail.com>
Date: Tue, 30 Jan 2018 16:08:02 -0800 (PST)
Message-ID: <01e5e5f9-0e13-4653-a680-d2d54d1e5a9e_at_googlegroups.com>


On Tuesday, January 30, 2018 at 6:04:51 PM UTC-6, Julianony M wrote:
> On Tuesday, January 30, 2018 at 4:21:57 PM UTC-6, The Natural Philosopher wrote:
> > On 30/01/18 21:55, Julianony M wrote:
> > > I have recently migrated several databases from MySQL-5.0.95 on a RedHat-6 server to MySQL-5.6.39 on a RedHat-7 server, along with their perl applications.
> > >
> > > While everything works just fine on the old server, it encounters problems on the new server when I perform the same database load:
> > >
> > > ERROR 1071 (42000) at line 383:
> > > Specified key was too long; max key length is 767 bytes
> > >
> > > although the same data, same scripts works just fine on the old server.
> > >
> > > Could anyone suggest possible causes or spots to look at for a fix? A simple comparisons of /etc/my.ini from the two servers didn't give me much clue.
> > >
> >
> > Is this relevant?
> >
> > https://stackoverflow.com/questions/40660396/sql-error-1071-specified-key-was-too-long-max-key-length-is-767-bytes
> >
> > Richard Lindzen
> [Quoted]
> Yes I read this and other similar posts by Google searches. I am afraid my situation is more systematic rather than specific field problems. In addition the database loader is a set of object oriented third party scripts and it's hard to dig down which table/field was the trouble maker.
>
> It seems more related with how index are coded on the "new" server. I wonder is there a way to change the default CHARACTER SET, like not to use utf8?
>
> j

I took a look at the database dump/load script, it's CHARSET=latin1 thus not likely the case.

j Received on Wed Jan 31 2018 - 01:08:02 CET

Original text of this message