OK,
the problem doesn't occur with --skip-locking. Still, I don't believe this to
be a lockd problem as the partition mysqld is working on is a local ext2 fs.
lockd isn't even running on the test system (no nfs). So, this leaves either
(in no particular sequence):
1. a mysql problem
2. a glibc 2.2
Hi,
first of all: the deadlock happened again today, this time with no slave
running so it isn't a replication issue. It seems we're getting closer as when
I did run 'show processlist', the pending query was (excerpt from output):
1666logreader 10.1.1.4syslog Query 114 Se
Andreas Steinmetz writes:
> Hi,
> the inserts did not change the state after the select finished. The network is
> running full duplex but the only problem I ever encountered with the cards was
> initalization on fast systems. I fixed this and posted it to the linux kernel
> mailing list (sea
Hi,
the inserts did not change the state after the select finished. The network is
running full duplex but the only problem I ever encountered with the cards was
initalization on fast systems. I fixed this and posted it to the linux kernel
mailing list (search for epic100).
If the problem continue
Andreas Steinmetz writes:
> Hi,
> well, the query is over a network. Single switch with two VLANs between the
> systems, network speed is *200MBit/s*. The php code structure executing was:
>
> ... prepare query ...
> mysql_connect();
> mysql_query();
> mysql_fetch_row();
> mysql_close();
Hi,
well, the query is over a network. Single switch with two VLANs between the
systems, network speed is *200MBit/s*. The php code structure executing was:
... prepare query ...
mysql_connect();
mysql_query();
mysql_fetch_row();
mysql_close();
... process and send data to browser ...
The table
Andreas Steinmetz writes:
> Hi,
> unfortunately I can't set up a scenario that easily reproduces the problem. The
> last lockups happened on saturday and today (monday). What I can confirm is:
>
> 1. It doesn't seem to be a slave related problem. During the last two lockups I
> checked the
Hello Sinisa,
Sunday, February 04, 2001, 3:15:21 PM, you wrote:
SM> Peter Zaitsev writes:
SM> > Hello Andreas,
SM> >
SM> > Thursday, February 01, 2001, 7:42:31 PM, you wrote:
SM> >
SM> >
SM> > I must confirm the problem with table locks. Mysql realy may deadlock
SM> > sometimes, and th
Hi,
unfortunately I can't set up a scenario that easily reproduces the problem. The
last lockups happened on saturday and today (monday). What I can confirm is:
1. It doesn't seem to be a slave related problem. During the last two lockups I
checked the master as well as the slave statuses, all we
Peter Zaitsev writes:
> Hello Andreas,
>
> Thursday, February 01, 2001, 7:42:31 PM, you wrote:
>
>
> I must confirm the problem with table locks. Mysql realy may deadlock
> sometimes, and the funny thing is the solution to this case is to kill
> the oldest locked thread waiting this con
Hello Andreas,
Thursday, February 01, 2001, 7:42:31 PM, you wrote:
I must confirm the problem with table locks. Mysql realy may deadlock
sometimes, and the funny thing is the solution to this case is to kill
the oldest locked thread waiting this condition - afterwards
everything resolves. So th
On 01-Feb-2001 Sinisa Milivojevic wrote:
>
> HI!
>
> Most probably processes are waiting for the slave to get updated.
>
> To circumvent the problem, you should :
>
> - use our binary (if possible)
>
> - avoid LOCK TABLES, which truly is necessary only in some rare cases
>
>
>
> Regards,
On 01-Feb-2001 Sinisa Milivojevic wrote:
>
> HI!
>
> Most probably processes are waiting for the slave to get updated.
>
> To circumvent the problem, you should :
>
> - use our binary (if possible)
>
> - avoid LOCK TABLES, which truly is necessary only in some rare cases
>
>
>
> Regards,
Andreas Steinmetz writes:
> It seems that MySQL 3.23.32 has an internal deadlock problem, causing the
> database to stop responding.
>
> Situation:
>
> 6 processes (each on a different system) connect to a mysql database and insert
> various system data into a set of MyISAM tables. Each p
It seems that MySQL 3.23.32 has an internal deadlock problem, causing the
database to stop responding.
Situation:
6 processes (each on a different system) connect to a mysql database and insert
various system data into a set of MyISAM tables. Each process uses the user
'logdaemon' which has inse
15 matches
Mail list logo