Server and ports are back up. Sorry about the outage.

There is something strange going on.

[url]http://noprimeleftbehind.net/tps/[/url] is up and running, but

[url]http://noprimeleftbehind.net:12000/all.html[/url] is down, and I can't get any work from port 12000.

The server machine continues to reboot itself. It may be a day before I can get it fixed.

Bad power supply in server machine. Replaced. Everything looks good now. :smile:

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.

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.

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:~$
[/code]

As you can see I cannot execute the commands because I cannot connect. Any suggestions?

I'm ignorant about MySQL.

Ah, mysqlcheck command is useless if mysqld service is not even run. Gary, what you see in the log files?

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...
[/code]

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=<root@jeepford.no-ip.org>, 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=<root@jeepford.no-ip.org>, ctladdr=<root@jeepford.no-ip.org> (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
[/code]

try this here:
[url]https://chepri.com/mysql-innodb-corruption-and-recovery/[/url]