> -----Original Message----- > From: Gleb Paharenko [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 28, 2005 06:30 > To: mysql@lists.mysql.com > Subject: Re: Weird database files > > > Hello. > > > On the master we're still running 4.0.16, the slaves are > up to 4.1.13. > > If you can - upgrade the master server. >
It's in the plans but that is our main production server so it's not something we can just do at any time. I've upgraded the slaves first because generally you can replicate from an older version to a newer one but not the other way around. > Jeff McKeon wrote: > >>Jeff wrote: > >> > >>>Had problem with our database this weekend, apparently an > >> > >>app did an > >> > >>>insert query that was huge size wise and this totally boogered up > >>>replication downstream. Also I cant read past that point > in the=20 > >>>binlog using mysqlbinlog on the master server. It complains that: > >>>=20 > >>>ERROR: Error in Log_event::read_log_event(): 'Event too big', > >>>data_len: 1953458240, event_type: 119 > >>>ERROR: Could not read entry at offset 66113944 : Error in=20 > >> > >>log format > >> > >>>or read error > >>>=20 > >>>And then there are the weird table files that showed up in > the data > >>>directory for the database (all MyISAM): =20 > >>>-rw-rw---- 1 mysql mysql 14K Sep 12 11:50 > >>>#sql-7c1c_217c.frm > >>>-rw-rw---- 1 mysql mysql 1.8G Sep 12 11:54 > >>>#sql-7c1c_217c.MYD > >>>-rw-rw---- 1 mysql mysql 92M Sep 12 12:09 > >>>#sql-7c1c_217c.MYI > >>>=20 > >>>Anyone ever see something like this before? Are they files > >> > >>for a temp > >> > >>>table maybe? > >>>=20 > >>>Jeff > >>>=20 > >> > >>=20 > >>Hello. > >>=20 > >>Yes, these files are from some unterminated query. See: > >> http://dev.mysql.com/doc/mysql/en/temporary-files.html > >>=20 > >>You may want to use --start-position (--start-datetime) and > >>--stop-position (--stop-datetime) to skip the > problematic=20 statement > >>and perform necessary updates on the slave by hand.=20 What > versions > >>of=20 MySQL do you use? > >>=20 > > > > > > On the master we're still running 4.0.16, the slaves are up > to 4.1.13. > > =20 > > > > To repair the problem with replication I simply restarted > the master > > so it created another binlog and then took a snapshot and recreated > > the slaves. > > > > I found out just this morning however that one of the tables has a > > corrupted MYI file. When I try to run a query on it, I get... > > > > ERROR 1016: Can't open file: 'Mailbox_Old.MYI'. (errno: 144) > > > > Running perror I get: > > > > Error code 144: Unknown error 144 > > 144 =3D Table is crashed and last repair failed > > > > I'm running mysqlcheck on the offending table now. > > > > Thanks, > > > > Jeff > > > > > > > -- > > /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET > <___/ www.mysql.com > > > > > -- > > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: > http://lists.mysql.com/mysql?> [EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
