mersenneforum.org  

Go Back   mersenneforum.org > Prime Search Projects > No Prime Left Behind

Reply
 
Thread Tools
Old 2019-04-15, 02:33   #529
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

237008 Posts
Default

Server and ports are back up. Sorry about the outage.
gd_barnes is online now   Reply With Quote
Old 2019-05-05, 22:58   #530
MooMoo2
 
MooMoo2's Avatar
 
Aug 2010

22×3×47 Posts
Default

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.
MooMoo2 is offline   Reply With Quote
Old 2019-05-06, 00:47   #531
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

100111110000002 Posts
Default

The server machine continues to reboot itself. It may be a day before I can get it fixed.
gd_barnes is online now   Reply With Quote
Old 2019-05-06, 20:25   #532
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

26×3×53 Posts
Default

Bad power supply in server machine. Replaced. Everything looks good now.
gd_barnes is online now   Reply With Quote
Old 2020-01-09, 23:53   #533
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

27C016 Posts
Default

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
gd_barnes is online now   Reply With Quote
Old 2020-01-10, 06:09   #534
unconnected
 
unconnected's Avatar
 
May 2009
Russia, Moscow

22×613 Posts
Default

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.
unconnected is offline   Reply With Quote
Old 2020-01-10, 08:09   #535
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

26·3·53 Posts
Default

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.
gd_barnes is online now   Reply With Quote
Old 2020-01-10, 08:18   #536
unconnected
 
unconnected's Avatar
 
May 2009
Russia, Moscow

22·613 Posts
Default

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
unconnected is offline   Reply With Quote
Old 2020-01-10, 08:39   #537
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

26×3×53 Posts
Default

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...
gd_barnes is online now   Reply With Quote
Old 2020-01-10, 08:45   #538
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

26×3×53 Posts
Default

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
gd_barnes is online now   Reply With Quote
Old 2020-01-10, 09:54   #539
rebirther
 
rebirther's Avatar
 
Sep 2011
Germany

2,423 Posts
Default

try this here:
https://chepri.com/mysql-innodb-corr...-and-recovery/
rebirther is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
What exactly is sent to the server? paul0 NFS@Home 2 2015-03-12 23:00
Server bug -- new? Christenson Information & Answers 5 2011-07-12 21:44
Server Down? Grant Information & Answers 13 2008-11-24 19:37
New ECM-server available andi314 Factoring 3 2003-08-31 11:22
New Server Hardware and price quotes, Funding the server 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

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.