[Koha] MySQL socket errors
Robert Meltz
RMeltz at insolnet.com
Tue Jun 8 01:46:27 NZST 2010
I looked at /var/log/syslog and found that my problem is worse than it seemed:
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Dump of the tablespace extent descriptor: len 40; hex 00000000000006e40000400008e60000400002f600000001ffffffffffffffffffffffffffffffff; asc @ @ ;
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Serious error! InnoDB is trying to free page 17131
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: though it is already marked as free in the tablespace!
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: The tablespace free space info is corrupt.
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: You may need to dump your InnoDB tables and recreate the whole
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: database!
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Please refer to
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: about forcing recovery.
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 100607 9:41:28InnoDB: Assertion failure in thread 2982538128 in file fsp0fsp.c line 2981
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: We intentionally generate a memory trap.
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: If you get repeated assertion failures or crashes, even
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: immediately after the mysqld startup, there may be
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: about forcing recovery.
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 100607 9:41:28 - mysqld got signal 11;
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: This could be because you hit a bug. It is also possible that this binary
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: or one of the libraries it was linked against is corrupt, improperly built,
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: or misconfigured. This error can also be caused by malfunctioning hardware.
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: We will try our best to scrape up some info that will hopefully help diagnose
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: the problem, but since we have already crashed, something is definitely wrong
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: and this may fail.
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]:
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: key_buffer_size=16777216
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: read_buffer_size=131072
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: max_used_connections=2
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: max_connections=100
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: threads_connected=1
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: It is possible that mysqld could use up to
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983 K
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: bytes of memory
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Hope that's ok; if not, decrease some variables in the equation.
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]:
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: thd=(nil)
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Attempting backtrace. You can use the following information to find out
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: where mysqld died. If you see no messages after this, something went
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: terribly wrong...
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Cannot determine thread, fp=0xb1c5cf48, backtrace may not be correct.
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Stack range sanity check OK, backtrace follows:
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x81cd88d
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x83cdf5c
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x83664c5
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x836676c
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x836c957
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x837660e
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x837865e
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x83466ce
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x8347ac7
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x832ab97
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x838a6e9
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x830df1c
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0xb76d84fb
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0xb74ecf5e
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: New value of fp=(nil) failed sanity check, terminating stack trace!
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: stack trace is much more helpful in diagnosing the problem, so please do
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: resolve it
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: information that should help you find out what is causing the crash.
Jun 7 09:41:28 lru-lnx-srv02 Koha Zebraqueue [31497]: failed to connect to DB: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)
Jun 7 09:41:28 lru-lnx-srv02 mysqld_safe[27083]: Number of processes running now: 0
Jun 7 09:41:28 lru-lnx-srv02 mysqld_safe[27085]: restarted
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Log scan progressed past the checkpoint lsn 1 1833585166
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 InnoDB: Database was not shut down normally!
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Starting crash recovery.
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Reading tablespace information from the .ibd files...
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Restoring possible half-written data pages from the doublewrite
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: buffer...
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Doing recovery: scanned up to log sequence number 1 1833662694
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 InnoDB: Starting an apply batch of log records to the database...
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Progress in percents: 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Apply batch completed
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 InnoDB: Started; log sequence number 1 1833662694
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 [Note] /usr/sbin/mysqld: ready for connections.
Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: Version: '5.0.51a-24+lenny1~bpo40+1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian)
Best regards,
Robert Meltz
Field Service Engineer
770.458.8658 x108
404.642.9093 cell
rmeltz at insolnet.com
www.insolnet.com
Follow us on Twitter: www.twitter.com/Insol_IT
At Insol: ownership and partnership know no bounds. IT's personal.
-----Original Message-----
From: koha-bounces at lists.katipo.co.nz [mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of Robert Meltz
Sent: Monday, June 07, 2010 8:56 AM
To: Reed Wade
Cc: koha at lists.katipo.co.nz
Subject: Re: [Koha] MySQL socket errors
Thanks Reed, could you please clarify a bit? Are you referring to the line in my.cnf that contains "bind-address" because if so, it is already set to 127.0.0.1.
Best regards,
Robert Meltz
Field Service Engineer
770.458.8658 x108
404.642.9093 cell
rmeltz at insolnet.com
www.insolnet.com
Follow us on Twitter: www.twitter.com/Insol_IT
At Insol: ownership and partnership know no bounds. IT's personal.
-----Original Message-----
From: reedwade at gmail.com [mailto:reedwade at gmail.com] On Behalf Of Reed Wade
Sent: Friday, June 04, 2010 10:48 PM
To: Robert Meltz
Cc: koha at lists.katipo.co.nz
Subject: Re: [Koha] MySQL socket errors
Consider using the IP address (127.0.0.1) instead of localhost for the
db connection. This will cause mysql to connect via TCP instead of
using a named socket and may help -- assuming your database is
responsive otherwise.
(
Mysql's decision to trap the localhost name and act differently with
it instead of making that a separate option is insane but in
character.
)
-reed
On Sat, Jun 5, 2010 at 12:35 AM, Robert Meltz <RMeltz at insolnet.com> wrote:
> Good Morning,
>
> I am having problems with Koha returning the following error:
>
> Koha error
> The following fatal error has occurred:
>
> Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /usr/share/perl/5.8/CGI/Carp.pm line 314.
> Compilation failed in require at /usr/share/koha/lib/C4/Auth.pm line 30.
> BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Auth.pm line 30.
> Compilation failed in require at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25.
> BEGIN failed--compilation aborted at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25.
>
>
> If I refresh the page it usually works, but this error appears more often than not since yesterday morning. I looked at some performance items suspecting that it may be related to slow response from the underlying system.
>
> top - 08:31:07 up 20:01, 1 user, load average: 0.21, 0.24, 0.25
>
> # for i in a b; do hdparm -tT /dev/sd"$i"; done
>
> /dev/sda:
> Timing cached reads: 2166 MB in 1.88 seconds = 1152.66 MB/sec
> Timing buffered disk reads: 22 MB in 3.28 seconds = 6.71 MB/sec
>
> /dev/sdb:
> Timing cached reads: 2530 MB in 1.87 seconds = 1355.50 MB/sec
> Timing buffered disk reads: 34 MB in 3.32 seconds = 10.24 MB/sec
>
> # mount
> /dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro)
> proc on /proc type proc (rw,noexec,nosuid,nodev)
> /sys on /sys type sysfs (rw,noexec,nosuid,nodev)
> varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
> varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
> udev on /dev type tmpfs (rw,mode=0755)
> devshm on /dev/shm type tmpfs (rw)
> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
> /dev/sdb1 on /var/lib type ext3 (rw,relatime,errors=remount-ro)
>
> It looks to me like the drives are slow. Not all that surprising considering that there are 6 virtual machines running off the same hyper-V host. What can I do to increase the performance under these conditions, or am I on the wrong track entirely?
>
> Best regards,
> Robert Meltz
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
_______________________________________________
Koha mailing list
Koha at lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
More information about the Koha
mailing list