Home > Archive > MySQL ODBC Connector > September 2005 > Weird database files









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Weird database files
Jeff

2005-09-25, 11:23 am

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 binlog
using mysqlbinlog on the master server. It complains that:

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 log format or
read error

And then there are the weird table files that showed up in the data
directory for the database (all MyISAM):

-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

Anyone ever see something like this before? Are they files for a temp
table maybe?

Jeff



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql? unsub...sie.nctu.edu.tw

Gleb Paharenko

2005-09-27, 7:23 am

Hello.

Yes, these files are from some unterminated query. See:
http://dev.mysql.com/doc/mysql/en/temporary-files.html

You may want to use --start-position (--start-datetime) and
--stop-position (--stop-datetime) to skip the problematic statement
and perform necessary updates on the slave by hand. What versions of
MySQL do you use?


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 binlog
> using mysqlbinlog on the master server. It complains that:
>
> 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 log format or
> read error
>
> And then there are the weird table files that showed up in the data
> directory for the database (all MyISAM):
>
> -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
>
> Anyone ever see something like this before? Are they files for a temp
> table maybe?
>
> Jeff
>
>
>



--
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.NET http://www.ensita.net/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Gleb Paharenko
/ /|_/ / // /\ \/ /_/ / /__ Gleb.Paharenko@ensita.net
/_/ /_/\_, /___/\___\_\___/ 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? unsub...sie.nctu.edu.tw

Jeff

2005-09-27, 9:23 am

> Jeff wrote:
> app did an
> log format
> for a temp
>
> Hello.
>
> Yes, these files are from some unterminated query. See:
> http://dev.mysql.com/doc/mysql/en/temporary-files.html
>
> You may want to use --start-position (--start-datetime) and
> --stop-position (--stop-datetime) to skip the problematic
> statement and perform necessary updates on the slave by hand.
> What versions of
> MySQL do you use?
>


On the master we're still running 4.0.16, the slaves are up to 4.1.13.

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:



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql? unsub...sie.nctu.edu.tw

Jeff McKeon

2005-09-27, 9:23 am

> Jeff wrote:
> app did an
> log format
> for a temp
>=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 General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql? unsub...sie.nctu.edu.tw

Gleb Paharenko

2005-09-28, 7:23 am

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.

Jeff McKeon wrote:
>
>
> 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
>
>



--
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.NET http://www.ensita.net/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Gleb Paharenko
/ /|_/ / // /\ \/ /_/ / /__ Gleb.Paharenko@ensita.net
/_/ /_/\_, /___/\___\_\___/ 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? unsub...sie.nctu.edu.tw

Jeff McKeon

2005-09-28, 9:23 am

> -----Original Message-----
> From: Gleb Paharenko [mailto:gleb.paharenko@ensita.net]=20
> Sent: Wednesday, September 28, 2005 06:30
> To: mysql@lists.mysql.com
> Subject: Re: Weird database files
>=20
>=20
> Hello.
>=20
> up to 4.1.13.
>=20
> If you can - upgrade the master server.
>=20


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:
> in the=3D20=20
> the data=20
> problematic=3D20 statement=20
> versions=20
> to 4.1.13.=20
> the master=20
>=20
>=20
> --=20
>=20
> /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET
> <___/ www.mysql.com
>=20
>=20
>=20
>=20
> --=20
>=20
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: =20
> http://lists.mysql.com/mysql?> unsub=3Djmckeon@tela
urus.com
>=20
>=20



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql? unsub...sie.nctu.edu.tw

Sponsored Links





Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive | Programming forum archive

Copyright 2008 droptable.com