mersenneforum.org Server outrages
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

 2019-04-15, 02:33 #529 gd_barnes     May 2007 Kansas; USA 237008 Posts Server and ports are back up. Sorry about the outage.
 2019-05-05, 22:58 #530 MooMoo2     Aug 2010 22×3×47 Posts There is something strange going on. http://noprimeleftbehind.net/tps/ is up and running, but http://noprimeleftbehind.net:12000/all.html is down, and I can't get any work from port 12000.
 2019-05-06, 00:47 #531 gd_barnes     May 2007 Kansas; USA 100111110000002 Posts The server machine continues to reboot itself. It may be a day before I can get it fixed.
 2019-05-06, 20:25 #532 gd_barnes     May 2007 Kansas; USA 26×3×53 Posts Bad power supply in server machine. Replaced. Everything looks good now.
 2020-01-09, 23:53 #533 gd_barnes     May 2007 Kansas; USA 27C016 Posts The NPLB and CRUS PRPnet servers are down and have been for over 12 hours. It is not a computer issue. The NPLB and CRUS web pages are OK and I am able to update them. I am getting a MySQL error that I am unable to fix when I try to start a PRPnet server. It is: Connect to database failed: [MySQL][ODBC 3.51 Driver]Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2), native code=2002 It is an old Linux machine. I have tried stopping and restarting MySQL with: sudo service mysql stop sudo service mysql start The stop works fine. When it tries to start it fails with: * Starting MySQL database server mysqld [ OK ] * Checking for corrupt, not cleanly closed and upgrade needing tables. gary@jeepford:~$ERROR 2013 (HY000) at line 2: Lost connection to MySQL server during query I have shut down the machine and restarted several times. A few times the PRPnet servers would run for awhile and then shut down. Other times they would not run at all. I would appreciate any help. Last fiddled with by gd_barnes on 2020-01-09 at 23:55  2020-01-10, 06:09 #534 unconnected May 2009 Russia, Moscow 22×613 Posts Gary, check mysqld log for errors, usually it is located at /var/log/mysqld.log. Also it make sense to check *.err files in the mysql data directory (/var/lib/mysql usually). Check that you have enough disk space and free ram. If there are errors about db/tables corruption in logs, run the next command to check: 'mysqlcheck --all-databases --check --verbose'. This command only checks db structure/integrity, for fix use with --repair option (it is good idea to backup data directory first). Hope this helps.  2020-01-10, 08:09 #535 gd_barnes May 2007 Kansas; USA 26·3·53 Posts Dmitry, Here is a screen shot of my recent attempt to do what you suggested: Code: gary@jeepford:~$ sudo service mysql status [sudo] password for gary: * MySQL is stopped. gary@jeepford:~$sudo service mysql start * Starting MySQL database server mysqld [ OK ] * Checking for corrupt, not cleanly closed and upgrade needing tables. gary@jeepford:~$ ERROR 2013 (HY000) at line 2: Lost connection to MySQL server during query gary@jeepford:~$mysqlcheck --all-databases mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connect gary@jeepford:~$ mysqlcheck --all-databases --repair mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connect gary@jeepford:~\$ As you can see I cannot execute the commands because I cannot connect. Any suggestions? I'm ignorant about MySQL.
 2020-01-10, 08:18 #536 unconnected     May 2009 Russia, Moscow 22·613 Posts Ah, mysqlcheck command is useless if mysqld service is not even run. Gary, what you see in the log files? Last fiddled with by unconnected on 2020-01-10 at 08:18
 2020-01-10, 08:39 #537 gd_barnes     May 2007 Kansas; USA 26×3×53 Posts Here are the last few pages. I hope this is enough. Code: Jan 10 02:34:22 jeepford mysqld[8351]: This could be because you hit a bug. It is also possible that this binary Jan 10 02:34:22 jeepford mysqld[8351]: or one of the libraries it was linked against is corrupt, improperly built, Jan 10 02:34:22 jeepford mysqld[8351]: or misconfigured. This error can also be caused by malfunctioning hardware. Jan 10 02:34:22 jeepford mysqld[8351]: We will try our best to scrape up some info that will hopefully help diagnose Jan 10 02:34:22 jeepford mysqld[8351]: the problem, but since we have already crashed, something is definitely wrong Jan 10 02:34:22 jeepford mysqld[8351]: and this may fail. Jan 10 02:34:22 jeepford mysqld[8351]: Jan 10 02:34:22 jeepford mysqld[8351]: key_buffer_size=134217728 Jan 10 02:34:22 jeepford mysqld[8351]: read_buffer_size=6291456 Jan 10 02:34:22 jeepford mysqld[8351]: max_used_connections=0 Jan 10 02:34:22 jeepford mysqld[8351]: max_connections=200 Jan 10 02:34:22 jeepford mysqld[8351]: threads_connected=0 Jan 10 02:34:22 jeepford mysqld[8351]: It is possible that mysqld could use up to Jan 10 02:34:22 jeepford mysqld[8351]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2588672 K Jan 10 02:34:22 jeepford mysqld[8351]: bytes of memory Jan 10 02:34:22 jeepford mysqld[8351]: Hope that's ok; if not, decrease some variables in the equation. Jan 10 02:34:22 jeepford mysqld[8351]: Jan 10 02:34:22 jeepford mysqld[8351]: thd=(nil) Jan 10 02:34:22 jeepford mysqld[8351]: Attempting backtrace. You can use the following information to find out Jan 10 02:34:22 jeepford mysqld[8351]: where mysqld died. If you see no messages after this, something went Jan 10 02:34:22 jeepford mysqld[8351]: terribly wrong... Jan 10 02:34:22 jeepford mysqld[8351]: frame pointer is NULL, did you compile with Jan 10 02:34:22 jeepford mysqld[8351]: -fomit-frame-pointer? Aborting backtrace! Jan 10 02:34:22 jeepford mysqld[8351]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains Jan 10 02:34:22 jeepford mysqld[8351]: information that should help you find out what is causing the crash. Jan 10 02:34:22 jeepford mysqld_safe[8368]: Number of processes running now: 0 Jan 10 02:34:22 jeepford mysqld_safe[8370]: restarted Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Log scan progressed past the checkpoint lsn 65 3180302167 Jan 10 02:34:22 jeepford mysqld[8373]: 200110 2:34:22 InnoDB: Database was not shut down normally! Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Starting crash recovery. Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Reading tablespace information from the .ibd files... Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Restoring possible half-written data pages from the doublewrite Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: buffer... Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Doing recovery: scanned up to log sequence number 65 3185544704 Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Doing recovery: scanned up to log sequence number 65 3186966404 Jan 10 02:34:22 jeepford mysqld[8373]: 200110 2:34:22 InnoDB: Starting an apply batch of log records to the database... Jan 10 02:34:46 jeepford mysqld[8373]: InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 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 Jan 10 02:34:46 jeepford mysqld[8373]: InnoDB: Apply batch completed Jan 10 02:34:46 jeepford mysqld[8373]: 200110 2:34:46 InnoDB: Started; log sequence number 65 3186966404 Jan 10 02:34:46 jeepford mysqld[8373]: 200110 2:34:46 [Note] /usr/sbin/mysqld: ready for connections. Jan 10 02:34:46 jeepford mysqld[8373]: Version: '5.0.75-0ubuntu10.5' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: Error: trying to access page number 1768430057 in space 0, Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: space name ./ibdata1, Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: which is outside the tablespace bounds. Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: Byte offset 0, len 16384, i/o type 10. Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: If you get this error at mysqld startup, please check that Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: your my.cnf matches the ibdata files that you have in the Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: MySQL server. Jan 10 02:34:47 jeepford mysqld[8373]: 200110 2:34:47InnoDB: Assertion failure in thread 140683719387472 in file fil0fil.c line 3959 Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: We intentionally generate a memory trap. Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com. Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: If you get repeated assertion failures or crashes, even Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: immediately after the mysqld startup, there may be Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: corruption in the InnoDB tablespace. Please refer to Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: about forcing recovery. Jan 10 02:34:47 jeepford mysqld[8373]: 200110 2:34:47 - mysqld got signal 11 ; Jan 10 02:34:47 jeepford mysqld[8373]: This could be because you hit a bug. It is also possible that this binary Jan 10 02:34:47 jeepford mysqld[8373]: or one of the libraries it was linked against is corrupt, improperly built, Jan 10 02:34:47 jeepford mysqld[8373]: or misconfigured. This error can also be caused by malfunctioning hardware. Jan 10 02:34:47 jeepford mysqld[8373]: We will try our best to scrape up some info that will hopefully help diagnose Jan 10 02:34:47 jeepford mysqld[8373]: the problem, but since we have already crashed, something is definitely wrong Jan 10 02:34:47 jeepford mysqld[8373]: and this may fail. Jan 10 02:34:47 jeepford mysqld[8373]: Jan 10 02:34:47 jeepford mysqld[8373]: key_buffer_size=134217728 Jan 10 02:34:47 jeepford mysqld[8373]: read_buffer_size=6291456 Jan 10 02:34:47 jeepford mysqld[8373]: max_used_connections=0 Jan 10 02:34:47 jeepford mysqld[8373]: max_connections=200 Jan 10 02:34:47 jeepford mysqld[8373]: threads_connected=0 Jan 10 02:34:47 jeepford mysqld[8373]: It is possible that mysqld could use up to Jan 10 02:34:47 jeepford mysqld[8373]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2588672 K Jan 10 02:34:47 jeepford mysqld[8373]: bytes of memory Jan 10 02:34:47 jeepford mysqld[8373]: Hope that's ok; if not, decrease some variables in the equation. Jan 10 02:34:47 jeepford mysqld[8373]: Jan 10 02:34:47 jeepford mysqld[8373]: thd=(nil) Jan 10 02:34:47 jeepford mysqld[8373]: Attempting backtrace. You can use the following information to find out Jan 10 02:34:47 jeepford mysqld[8373]: where mysqld died. If you see no messages after this, something went Jan 10 02:34:47 jeepford mysqld[8373]: terribly wrong... Jan 10 02:34:47 jeepford mysqld[8373]: frame pointer is NULL, did you compile with Jan 10 02:34:47 jeepford mysqld[8373]: -fomit-frame-pointer? Aborting backtrace! Jan 10 02:34:47 jeepford mysqld[8373]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains Jan 10 02:34:47 jeepford mysqld[8373]: information that should help you find out what is causing the crash. Jan 10 02:34:48 jeepford mysqld_safe[8395]: Number of processes running now: 0 Jan 10 02:34:48 jeepford mysqld_safe[8397]: restarted Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Log scan progressed past the checkpoint lsn 65 3180302167 Jan 10 02:34:48 jeepford mysqld[8400]: 200110 2:34:48 InnoDB: Database was not shut down normally! Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Starting crash recovery. Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Reading tablespace information from the .ibd files... Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Restoring possible half-written data pages from the doublewrite Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: buffer... Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Doing recovery: scanned up to log sequence number 65 3185544704 Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Doing recovery: scanned up to log sequence number 65 3186966404 Jan 10 02:34:48 jeepford mysqld[8400]: 200110 2:34:48 InnoDB: Starting an apply batch of log records to the database... Jan 10 02:35:13 jeepford mysqld[8400]: InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 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 Jan 10 02:35:13 jeepford mysqld[8400]: InnoDB: Apply batch completed Jan 10 02:35:13 jeepford mysqld[8400]: 200110 2:35:13 InnoDB: Started; log sequence number 65 3186966404 Jan 10 02:35:13 jeepford mysqld[8400]: 200110 2:35:13 [Note] /usr/sbin/mysqld: ready for connections. Jan 10 02:35:13 jeepford mysqld[8400]: Version: '5.0.75-0ubuntu10.5' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: Error: trying to access page number 1768430057 in space 0, Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: space name ./ibdata1, Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: which is outside the tablespace bounds. Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: Byte offset 0, len 16384, i/o type 10. Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: If you get this error at mysqld startup, please check that Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: your my.cnf matches the ibdata files that you have in the Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: MySQL server. Jan 10 02:35:14 jeepford mysqld[8400]: 200110 2:35:14InnoDB: Assertion failure in thread 140060547017040 in file fil0fil.c line 3959 Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: We intentionally generate a memory trap. Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com. Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: If you get repeated assertion failures or crashes, even Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: immediately after the mysqld startup, there may be Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: corruption in the InnoDB tablespace. Please refer to Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: about forcing recovery. Jan 10 02:35:14 jeepford mysqld[8400]: 200110 2:35:14 - mysqld got signal 11 ; Jan 10 02:35:14 jeepford mysqld[8400]: This could be because you hit a bug. It is also possible that this binary Jan 10 02:35:14 jeepford mysqld[8400]: or one of the libraries it was linked against is corrupt, improperly built, Jan 10 02:35:14 jeepford mysqld[8400]: or misconfigured. This error can also be caused by malfunctioning hardware. Jan 10 02:35:14 jeepford mysqld[8400]: We will try our best to scrape up some info that will hopefully help diagnose Jan 10 02:35:14 jeepford mysqld[8400]: the problem, but since we have already crashed, something is definitely wrong Jan 10 02:35:14 jeepford mysqld[8400]: and this may fail. Jan 10 02:35:14 jeepford mysqld[8400]: Jan 10 02:35:14 jeepford mysqld[8400]: key_buffer_size=134217728 Jan 10 02:35:14 jeepford mysqld[8400]: read_buffer_size=6291456 Jan 10 02:35:14 jeepford mysqld[8400]: max_used_connections=0 Jan 10 02:35:14 jeepford mysqld[8400]: max_connections=200 Jan 10 02:35:14 jeepford mysqld[8400]: threads_connected=0 Jan 10 02:35:14 jeepford mysqld[8400]: It is possible that mysqld could use up to Jan 10 02:35:14 jeepford mysqld[8400]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2588672 K Jan 10 02:35:14 jeepford mysqld[8400]: bytes of memory Jan 10 02:35:14 jeepford mysqld[8400]: Hope that's ok; if not, decrease some variables in the equation. Jan 10 02:35:14 jeepford mysqld[8400]: Jan 10 02:35:14 jeepford mysqld[8400]: thd=(nil) Jan 10 02:35:14 jeepford mysqld[8400]: Attempting backtrace. You can use the following information to find out Jan 10 02:35:14 jeepford mysqld[8400]: where mysqld died. If you see no messages after this, something went Jan 10 02:35:14 jeepford mysqld[8400]: terribly wrong... Jan 10 02:35:14 jeepford mysqld[8400]: frame pointer is NULL, did you compile with Jan 10 02:35:14 jeepford mysqld[8400]: -fomit-frame-pointer? Aborting backtrace! Jan 10 02:35:14 jeepford mysqld[8400]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains Jan 10 02:35:14 jeepford mysqld[8400]: information that should help you find out what is causing the crash. Jan 10 02:35:14 jeepford mysqld_safe[8436]: Number of processes running now: 0 Jan 10 02:35:14 jeepford mysqld_safe[8438]: restarted Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: Log scan progressed past the checkpoint lsn 65 3180302167 Jan 10 02:35:14 jeepford mysqld[8441]: 200110 2:35:14 InnoDB: Database was not shut down normally! Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: Starting crash recovery. Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: Reading tablespace information from the .ibd files... Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: Restoring possible half-written data pages from the doublewrite Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: buffer... Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: Doing recovery: scanned up to log sequence number 65 3185544704 Jan 10 02:35:15 jeepford mysqld[8441]: InnoDB: Doing recovery: scanned up to log sequence number 65 3186966404 Jan 10 02:35:15 jeepford mysqld[8441]: 200110 2:35:15 InnoDB: Starting an apply batch of log records to the database...
 2020-01-10, 08:45 #538 gd_barnes     May 2007 Kansas; USA 26×3×53 Posts Here are the first few pages after shutting machine down and turning it back on: Code: Jan 10 02:06:07 jeepford syslogd 1.5.0#5ubuntu3: restart. Jan 10 02:06:07 jeepford anacron[3197]: Job cron.daily' terminated (exit status: 1) (mailing output) Jan 10 02:06:07 jeepford sendmail[4500]: 00A867GF004500: from=root, size=294, class=0, nrcpts=1, msgid=<202001100806.00A867GF004500@jeepford.no-ip.org>, relay=root@localhost Jan 10 02:06:07 jeepford sm-mta[4501]: 00A867BR004501: from=, size=570, class=0, nrcpts=1, msgid=<202001100806.00A867GF004500@jeepford.no-ip.org>, proto=ESMTP, daemon=MTA-v4, relay=jeepford.no-ip.org [127.0.0.1] Jan 10 02:06:07 jeepford sendmail[4500]: 00A867GF004500: to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30294, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (00A867BR004501 Message accepted for delivery) Jan 10 02:06:07 jeepford anacron[3197]: Normal exit (1 job run) Jan 10 02:06:07 jeepford sm-mta[4502]: 00A867BR004501: to=, ctladdr= (0/0), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30804, dsn=2.0.0, stat=Sent Jan 10 02:06:08 jeepford avahi-daemon[3078]: Invalid query packet. Jan 10 02:06:17 jeepford avahi-daemon[3078]: Invalid query packet. Jan 10 02:06:19 jeepford mysqld[4344]: InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 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 Jan 10 02:06:19 jeepford mysqld[4344]: InnoDB: Apply batch completed Jan 10 02:06:19 jeepford mysqld[4344]: 200110 2:06:19 InnoDB: Started; log sequence number 65 3186966404 Jan 10 02:06:19 jeepford mysqld[4344]: 200110 2:06:19 [Note] /usr/sbin/mysqld: ready for connections. Jan 10 02:06:19 jeepford mysqld[4344]: Version: '5.0.75-0ubuntu10.5' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: Error: trying to access page number 1768430057 in space 0, Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: space name ./ibdata1, Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: which is outside the tablespace bounds. Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: Byte offset 0, len 16384, i/o type 10. Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: If you get this error at mysqld startup, please check that Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: your my.cnf matches the ibdata files that you have in the Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: MySQL server. Jan 10 02:06:20 jeepford mysqld[4344]: 200110 2:06:20InnoDB: Assertion failure in thread 140681679481168 in file fil0fil.c line 3959 Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: We intentionally generate a memory trap. Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com. Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: If you get repeated assertion failures or crashes, even Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: immediately after the mysqld startup, there may be Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: corruption in the InnoDB tablespace. Please refer to Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: about forcing recovery. Jan 10 02:06:20 jeepford mysqld[4344]: 200110 2:06:20 - mysqld got signal 11 ; Jan 10 02:06:20 jeepford mysqld[4344]: This could be because you hit a bug. It is also possible that this binary Jan 10 02:06:20 jeepford mysqld[4344]: or one of the libraries it was linked against is corrupt, improperly built, Jan 10 02:06:20 jeepford mysqld[4344]: or misconfigured. This error can also be caused by malfunctioning hardware. Jan 10 02:06:20 jeepford mysqld[4344]: We will try our best to scrape up some info that will hopefully help diagnose Jan 10 02:06:20 jeepford mysqld[4344]: the problem, but since we have already crashed, something is definitely wrong Jan 10 02:06:20 jeepford mysqld[4344]: and this may fail. Jan 10 02:06:20 jeepford mysqld[4344]: Jan 10 02:06:20 jeepford mysqld[4344]: key_buffer_size=134217728 Jan 10 02:06:20 jeepford mysqld[4344]: read_buffer_size=6291456 Jan 10 02:06:20 jeepford mysqld[4344]: max_used_connections=0 Jan 10 02:06:20 jeepford mysqld[4344]: max_connections=200 Jan 10 02:06:20 jeepford mysqld[4344]: threads_connected=0 Jan 10 02:06:20 jeepford mysqld[4344]: It is possible that mysqld could use up to Jan 10 02:06:20 jeepford mysqld[4344]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2588672 K Jan 10 02:06:20 jeepford mysqld[4344]: bytes of memory Jan 10 02:06:20 jeepford mysqld[4344]: Hope that's ok; if not, decrease some variables in the equation. Jan 10 02:06:20 jeepford mysqld[4344]: Jan 10 02:06:20 jeepford mysqld[4344]: thd=(nil) Jan 10 02:06:20 jeepford mysqld[4344]: Attempting backtrace. You can use the following information to find out Jan 10 02:06:20 jeepford mysqld[4344]: where mysqld died. If you see no messages after this, something went Jan 10 02:06:20 jeepford mysqld[4344]: terribly wrong... Jan 10 02:06:20 jeepford mysqld[4344]: frame pointer is NULL, did you compile with Jan 10 02:06:20 jeepford mysqld[4344]: -fomit-frame-pointer? Aborting backtrace! Jan 10 02:06:20 jeepford mysqld[4344]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains Jan 10 02:06:20 jeepford mysqld[4344]: information that should help you find out what is causing the crash. Jan 10 02:06:20 jeepford mysqld_safe[4515]: Number of processes running now: 0 Jan 10 02:06:20 jeepford mysqld_safe[4517]: restarted Jan 10 02:06:20 jeepford mysqld[4520]: InnoDB: Log scan progressed past the checkpoint lsn 65 3180302167 Jan 10 02:06:20 jeepford mysqld[4520]: 200110 2:06:20 InnoDB: Database was not shut down normally! Jan 10 02:06:20 jeepford mysqld[4520]: InnoDB: Starting crash recovery. Jan 10 02:06:20 jeepford mysqld[4520]: InnoDB: Reading tablespace information from the .ibd files... Jan 10 02:06:20 jeepford mysqld[4520]: InnoDB: Restoring possible half-written data pages from the doublewrite Jan 10 02:06:20 jeepford mysqld[4520]: InnoDB: buffer... Jan 10 02:06:21 jeepford mysqld[4520]: InnoDB: Doing recovery: scanned up to log sequence number 65 3185544704 Jan 10 02:06:21 jeepford mysqld[4520]: InnoDB: Doing recovery: scanned up to log sequence number 65 3186966404 Jan 10 02:06:21 jeepford mysqld[4520]: 200110 2:06:21 InnoDB: Starting an apply batch of log records to the database... Jan 10 02:06:45 jeepford mysqld[4520]: InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 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 Jan 10 02:06:45 jeepford mysqld[4520]: InnoDB: Apply batch completed Jan 10 02:06:45 jeepford mysqld[4520]: 200110 2:06:45 InnoDB: Started; log sequence number 65 3186966404 Jan 10 02:06:45 jeepford mysqld[4520]: 200110 2:06:45 [Note] /usr/sbin/mysqld: ready for connections. Jan 10 02:06:45 jeepford mysqld[4520]: Version: '5.0.75-0ubuntu10.5' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: Error: trying to access page number 1768430057 in space 0, Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: space name ./ibdata1, Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: which is outside the tablespace bounds. Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: Byte offset 0, len 16384, i/o type 10. Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: If you get this error at mysqld startup, please check that Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: your my.cnf matches the ibdata files that you have in the Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: MySQL server. Jan 10 02:06:46 jeepford mysqld[4520]: 200110 2:06:46InnoDB: Assertion failure in thread 139678118078800 in file fil0fil.c line 3959 Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: We intentionally generate a memory trap. Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com. Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: If you get repeated assertion failures or crashes, even Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: immediately after the mysqld startup, there may be Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: corruption in the InnoDB tablespace. Please refer to Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: about forcing recovery. Jan 10 02:06:46 jeepford mysqld[4520]: 200110 2:06:46 - mysqld got signal 11 ; Jan 10 02:06:46 jeepford mysqld[4520]: This could be because you hit a bug. It is also possible that this binary Jan 10 02:06:46 jeepford mysqld[4520]: or one of the libraries it was linked against is corrupt, improperly built, Jan 10 02:06:46 jeepford mysqld[4520]: or misconfigured. This error can also be caused by malfunctioning hardware. Jan 10 02:06:46 jeepford mysqld[4520]: We will try our best to scrape up some info that will hopefully help diagnose Jan 10 02:06:46 jeepford mysqld[4520]: the problem, but since we have already crashed, something is definitely wrong Jan 10 02:06:46 jeepford mysqld[4520]: and this may fail. Jan 10 02:06:46 jeepford mysqld[4520]: Jan 10 02:06:46 jeepford mysqld[4520]: key_buffer_size=134217728 Jan 10 02:06:46 jeepford mysqld[4520]: read_buffer_size=6291456 Jan 10 02:06:46 jeepford mysqld[4520]: max_used_connections=0`
 2020-01-10, 09:54 #539 rebirther     Sep 2011 Germany 2,423 Posts try this here: https://chepri.com/mysql-innodb-corr...-and-recovery/

 Similar Threads Thread Thread Starter Forum Replies Last Post paul0 NFS@Home 2 2015-03-12 23:00 Christenson Information & Answers 5 2011-07-12 21:44 Grant Information & Answers 13 2008-11-24 19:37 andi314 Factoring 3 2003-08-31 11:22 Angular PrimeNet 32 2002-12-09 01:12

All times are UTC. The time now is 07:44.

Tue Aug 11 07:44:56 UTC 2020 up 25 days, 3:31, 1 user, load averages: 1.44, 1.72, 1.79