tablecrash on MySQL-Max-4.0.16
tablecrash on MySQL-Max-4.0.16
am 10.12.2003 15:06:34 von Vidar
Hi
system : rh9
mysql :
MySQL-devel-4.0.16-0
MySQL-shared-4.0.16-0
MySQL-Max-4.0.16-0
MySQL-client-4.0.16-0
MySQL-server-4.0.16-0
We have a table
> desc ezsession;
+-----------------+------------------+------+-----+--------- +-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+------------------+------+-----+--------- +-------+
| session_key | varchar(32) | | PRI | | |
| expiration_time | int(11) unsigned | | MUL | 0 | |
| data | text | | | | |
| cache_mask_1 | int(11) | | | 0 | |
+-----------------+------------------+------+-----+--------- +-------+
This table is very often read/written to (only plain select, insert and update
queries, no joins). But sometimes it crashes. I have uploaded
tablecrash_max4016_full_processlist.tar.gz to your ftp account
The table locks, so a restart of mysql and a "repair table ezsession;" is
needed in order to make the table work again.
The table have typically 10000-20000 records
> select avg(length(data)) from ezsession;
+-------------------+
| avg(length(data)) |
+-------------------+
| 667.3505 |
+-------------------+
1 row in set (0.09 sec)
mysql> select max(length(data)) from ezsession;
+-------------------+
| max(length(data)) |
+-------------------+
| 4214 |
+-------------------+
1 row in set (0.08 sec)
I realize this is not much for you to go on, put any hint which could help me
create a repeatable testcase is appreciated. Maybe you allready are aware of
similar problems?
Also, it seems that the size of "data" might be related. Some codechange in
our application to reduce the size in this field seemed to help, (less
frequently crashes)
The server is not installed with your precompiled binaries either so this
might be a place to start ?
PS
This is definitively NOT a "disk full" problem
--
Vidar Langseid
--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org
Re: tablecrash on MySQL-Max-4.0.16
am 10.12.2003 16:54:07 von Sinisa Milivojevic
Vidar writes:
>
> Hi
>
> system : rh9
> mysql :
> MySQL-devel-4.0.16-0
> MySQL-shared-4.0.16-0
> MySQL-Max-4.0.16-0
> MySQL-client-4.0.16-0
> MySQL-server-4.0.16-0
>
> We have a table
> > desc ezsession;
> +-----------------+------------------+------+-----+--------- +-------+
> | Field | Type | Null | Key | Default | Extra |
> +-----------------+------------------+------+-----+--------- +-------+
> | session_key | varchar(32) | | PRI | | |
> | expiration_time | int(11) unsigned | | MUL | 0 | |
> | data | text | | | | |
> | cache_mask_1 | int(11) | | | 0 | |
> +-----------------+------------------+------+-----+--------- +-------+
>
> This table is very often read/written to (only plain select, insert and update
> queries, no joins). But sometimes it crashes. I have uploaded
> tablecrash_max4016_full_processlist.tar.gz to your ftp account
>
> The table locks, so a restart of mysql and a "repair table ezsession;" is
> needed in order to make the table work again.
[skip]
> PS
> This is definitively NOT a "disk full" problem
>
> --
> Vidar Langseid
>
HI!
Where exactly on our ftp site did you upload the above process list ??
Can you just send the relevant snippet form it ??
We can not deduce based on the above where to look at all in order to
find a cause of the problem.
Also, what does it mean "table locks" ?? All MyISAM tables are locked
with our queries.
Also, with 4.0.15 and up, all corruption reports so far, were traced
back to hardware problems or to bad built binary.
It is also unclear from your report whether you use our binary or not.
This does not mean that the above is not a bug,
Only that this is not a fully repeatable test case which will enable
us to corrupt table in each of it's runs.
--
Sincerely,
--
For technical support contracts, go to https://order.mysql.com/?ref=msmi
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB
/_/ /_/\_, /___/\___\_\___/ Fulltime Developer and Support Coordinator
<___/ www.mysql.com Larnaca, Cyprus
--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org
Re: tablecrash on MySQL-Max-4.0.16
am 10.12.2003 18:35:05 von Vidar
Hi
Thank you for your reply
> Where exactly on our ftp site did you upload the above process list ??
support.mysql.com/pub/mysql/secret/
> Can you just send the relevant snippet form it ??
96325 db32vl localhost db32vl Query 34 Locked UPDATE
ezsession\n SET expiration_time='1071019479',
data='[SNIP]'\n WHERE session_key='[SNIP]'
> We can not deduce based on the above where to look at all in order to
> find a cause of the problem.
> Also, what does it mean "table locks" ?? All MyISAM tables are locked
> with our queries.
All queries have status "Locked". And only queries concerning ezsession is
running on the server when I do a "show full processlist;"
> Also, with 4.0.15 and up, all corruption reports so far, were traced
> back to hardware problems or to bad built binary.
> It is also unclear from your report whether you use our binary or not.
I said "The server is not installed with your precompiled binaries". What I
was trying to say was that we do NOT use your binary.
> This does not mean that the above is not a bug,
Well, I cannot think of any valid reason why mysql would lock all queries on
this table, do you ? If you don't either, I will try you binaries instead.
>Only that this is not a fully repeatable test case which will enable
>us to corrupt table in each of it's runs.
I have no problem with understanding that you are unable to reproduce this.
But I don't think a bug in my application could cause this mysql behaviour?
So it is either a mysql bug or (more probably) a bad build binary ?
Again, thank you for your time.
Best regards,
Vidar
On Wednesday 10 December 2003 16:54, you wrote:
> Vidar writes:
> > Hi
> >
> > system : rh9
> > mysql :
> > MySQL-devel-4.0.16-0
> > MySQL-shared-4.0.16-0
> > MySQL-Max-4.0.16-0
> > MySQL-client-4.0.16-0
> > MySQL-server-4.0.16-0
> >
> > We have a table
> >
> > > desc ezsession;
> >
> > +-----------------+------------------+------+-----+--------- +-------+
> >
> > | Field | Type | Null | Key | Default | Extra |
> >
> > +-----------------+------------------+------+-----+--------- +-------+
> >
> > | session_key | varchar(32) | | PRI | | |
> > | expiration_time | int(11) unsigned | | MUL | 0 | |
> > | data | text | | | | |
> > | cache_mask_1 | int(11) | | | 0 | |
> >
> > +-----------------+------------------+------+-----+--------- +-------+
> >
> > This table is very often read/written to (only plain select, insert and
> > update queries, no joins). But sometimes it crashes. I have uploaded
> > tablecrash_max4016_full_processlist.tar.gz to your ftp account
> >
> > The table locks, so a restart of mysql and a "repair table ezsession;" is
> > needed in order to make the table work again.
>
> [skip]
>
> > PS
> > This is definitively NOT a "disk full" problem
> >
> > --
> > Vidar Langseid
>
> HI!
>
> Where exactly on our ftp site did you upload the above process list ??
>
> Can you just send the relevant snippet form it ??
>
> We can not deduce based on the above where to look at all in order to
> find a cause of the problem.
>
> Also, what does it mean "table locks" ?? All MyISAM tables are locked
> with our queries.
>
> Also, with 4.0.15 and up, all corruption reports so far, were traced
> back to hardware problems or to bad built binary.
>
> It is also unclear from your report whether you use our binary or not.
>
> This does not mean that the above is not a bug,
>
> Only that this is not a fully repeatable test case which will enable
> us to corrupt table in each of it's runs.
>
> --
>
> Sincerely,
--
vidar
--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org
Re: tablecrash on MySQL-Max-4.0.16
am 10.12.2003 19:18:08 von Sinisa Milivojevic
Vidar writes:
>
> Hi
>
> Thank you for your reply
>
> > Where exactly on our ftp site did you upload the above process list ??
> support.mysql.com/pub/mysql/secret/
>
> > Can you just send the relevant snippet form it ??
> 96325 db32vl localhost db32vl Query 34 Locked UPDATE
> ezsession\n SET expiration_time='1071019479',
> data='[SNIP]'\n WHERE session_key='[SNIP]'
>
> All queries have status "Locked". And only queries concerning ezsession is
> running on the server when I do a "show full processlist;"
If a table were corrupted, a query would not run.
UPDATE would simply and immediately return the error to the client.
The aboev could be simply long running command or some problem with
file system or external locking is used. Or binary has problems.
--
Sincerely,
--
For technical support contracts, go to https://order.mysql.com/?ref=msmi
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB
/_/ /_/\_, /___/\___\_\___/ Fulltime Developer and Support Coordinator
<___/ www.mysql.com Larnaca, Cyprus
--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org
Re: tablecrash on MySQL-Max-4.0.16
am 16.12.2003 11:03:35 von Vidar
Hi
> If a table were corrupted, a query would not run.
> UPDATE would simply and immediately return the error to the client.
That didn't happend. The update did not return immediately but was only
stalling.
Anyway, we replaced the mysqlserver with your binary rpm's. That fixed our
problem. We have now tested for several days and we have not experienced even
a single crash after the upgrade.
The conclusion then is that recompiling your SRPMs on a rh90 box will NOT
build stable mysql binaries.
Thanks for you insights
Best regards,
Vidar
On Wednesday 10 December 2003 19:18, Sinisa Milivojevic wrote:
> Vidar writes:
> > Hi
> >
> > Thank you for your reply
> >
> > > Where exactly on our ftp site did you upload the above process list ??
> >
> > support.mysql.com/pub/mysql/secret/
> >
> > > Can you just send the relevant snippet form it ??
> >
> > 96325 db32vl localhost db32vl Query 34 Locked
> > UPDATE ezsession\n SET expiration_time='1071019479',
> > data='[SNIP]'\n WHERE session_key='[SNIP]'
> >
> > All queries have status "Locked". And only queries concerning ezsession
> > is running on the server when I do a "show full processlist;"
>
> If a table were corrupted, a query would not run.
>
> UPDATE would simply and immediately return the error to the client.
>
> The aboev could be simply long running command or some problem with
> file system or external locking is used. Or binary has problems.
>
>
> --
>
> Sincerely,
--
vidar
--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org
Re: tablecrash on MySQL-Max-4.0.16
am 16.12.2003 13:42:52 von Sinisa Milivojevic
Vidar writes:
>
> Hi
>
> Anyway, we replaced the mysqlserver with your binary rpm's. That fixed our
> problem. We have now tested for several days and we have not experienced even
> a single crash after the upgrade.
>
> The conclusion then is that recompiling your SRPMs on a rh90 box will NOT
> build stable mysql binaries.
>
> Thanks for you insights
>
> Best regards,
> Vidar
>
I am happy that I was of the assistance.
--
Sincerely,
--
For technical support contracts, go to https://order.mysql.com/?ref=msmi
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB
/_/ /_/\_, /___/\___\_\___/ Fulltime Developer and Support Coordinator
<___/ www.mysql.com Larnaca, Cyprus
--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org