[Building Sakai] sakai mysql db down

Tue Dec 17 16:55:28 PST 2013

I believe you will find much more relevant info about this topic if you
search the web for steps to take if your MySQL loses power.  InnoDB is a
transactional database engine. So losing power during operation could cause
database corruption.  Once back with power, you need to use MySQL tools to
ensure all tables are consistent and working properly.  If you cannot
repair all tables, you may need to resort to restoring a database or a
database table from a backup.  But in general, you will find much better
information on other sites or on other mailing lists dedicated to MySQL
support.

On Tue, Dec 17, 2013 at 7:18 PM, Sanghyun Jeon <euksa99 at gmail.com> wrote:

> We had a data center power issue (Emergency shut down due to overheating
> problem from building construction). I've heard that there was disk
> corruption but that should be resolved. Do you think reloading the database
> will relieve this problem because some of corruption may have occurred in
> the database files?
>
> S
>
>
> On Tue, Dec 17, 2013 at 3:19 PM, Sam Ottenhoff <ottenhoff at longsight.com>wrote:
>
>> Your problems have nothing to do with Sakai's Preferences tool. If you
>> continue to have issues, my first instinct would be disk corruption on the
>> MySQL server.
>>
>> --Sam
>>
>>
>>
>> On Tue, Dec 17, 2013 at 6:10 PM, Sanghyun Jeon <euksa99 at gmail.com> wrote:
>>
>>> Oh. We successfully recovered the table already. We are just wondering
>>> whether SAKAI_PREFERENCES table or Preference tool might have something
>>> causing this problem. We are currently having a lot of db related bug
>>> reports such as "caused by:
>>> com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications
>>> link failure" and mysql db problem is often followed by our sakai crashes.
>>> Last week we have had two major crashes (four app nodes shut down) after db
>>> shut down and one is related with SAKAI_PREFERENCES table corruption. This
>>> week we have system crashes twice already (not related with
>>> SAKAI_PREFERENCES table, though but one is clearly related with db shut
>>> down -- it says mysqld normal shutdown but nobody shut down mysql at that
>>> time) but we don't have a clear clue why.
>>>
>>> Any advice and suggestion will be greatly appreciated.
>>>
>>> Thanks.
>>>
>>> S
>>>
>>>
>>> On Tue, Dec 17, 2013 at 2:28 PM, John Bush <jbush at anisakai.com> wrote:
>>>
>>>> Doesn't sound like a Sakai specific issue, try googling around for how
>>>> to recover mysql.  For example,
>>>>
>>>> http://rivenlinux.info/how-to-recover-innodb-corruption-for-mysql/
>>>>
>>>> On Tue, Dec 17, 2013 at 2:47 PM, Sanghyun Jeon <euksa99 at gmail.com>
>>>> wrote:
>>>> > mysql log said so and please see the lines below highlighted on red.
>>>> >
>>>> > nnoDB: Page number (if stored to page already) 23,
>>>> >
>>>> > InnoDB: space id (if created with >= MySQL-4.1.1 and stored already)
>>>> 171
>>>> >
>>>> > InnoDB: Page may be an index page where index id is 0 492
>>>> >
>>>> > InnoDB: (index "SAKAI_PREFERENCES_INDEX" of table
>>>> > "sakai"."SAKAI_PREFERENCES")
>>>> >
>>>> > InnoDB: Database page corruption on disk or a failed
>>>> >
>>>> > InnoDB: file read of page 187.
>>>> >
>>>> > InnoDB: You may have to recover from a backup.
>>>> >
>>>> > InnoDB: It is also possible that your operating
>>>> >
>>>> > InnoDB: system has corrupted its own file cache
>>>> >
>>>> > InnoDB: and rebooting your computer removes the
>>>> >
>>>> > InnoDB: error.
>>>> >
>>>> > InnoDB: If the corrupt page is an index page
>>>> >
>>>> > InnoDB: you can also try to fix the corruption
>>>> >
>>>> > InnoDB: by dumping, dropping, and reimporting
>>>> >
>>>> > InnoDB: the corrupt table. You can use CHECK
>>>> >
>>>> > InnoDB: TABLE to scan your table for corruption.
>>>> >
>>>> > InnoDB: See also
>>>> > http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html
>>>> >
>>>> > InnoDB: about forcing recovery.
>>>> >
>>>> > InnoDB: Ending processing because of a corrupt database page.
>>>> >
>>>> > 131120 13:28:37 mysqld_safe Number of processes running now: 0
>>>> >
>>>> > 131120 13:28:37 mysqld_safe mysqld restarted
>>>> >
>>>> >
>>>> >
>>>> > On Mon, Dec 16, 2013 at 3:52 PM, Steve Swinsburg <
>>>> steve.swinsburg at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> Do you have any logs for what happened? When you say 'because of
>>>> >> sakai_preferences table corruption' - what do you mean?
>>>> >>
>>>> >> cheers,
>>>> >> Steve
>>>> >>
>>>> >>
>>>> >> On Tue, Dec 17, 2013 at 5:05 AM, Sanghyun Jeon <euksa99 at gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> Hello all,
>>>> >>>
>>>> >>> We have a system crash last week because of sakai_preferences table
>>>> >>> corruption and we recovered the table successfully but the sakai db
>>>> shut
>>>> >>> down again this morning without reason.
>>>> >>>
>>>> >>> Version: '5.1.69-log'  socket: '/var/lib/mysql/mysql.sock'  port:
>>>> 3306
>>>> >>> Source distribution
>>>> >>> 131216  8:42:56 [Note] /usr/libexec/mysqld: Normal shutdown
>>>> >>>
>>>> >>> 131216  8:42:56 [Note] Event Scheduler: Purging the queue. 0 events
>>>> >>> 131216  8:42:59  InnoDB: Starting shutdown...
>>>> >>> 131216  8:43:23  InnoDB: Shutdown completed; log sequence number 12
>>>> >>> 4183647936
>>>> >>> 131216  8:43:23 [Note] /usr/libexec/mysqld: Shutdown complete
>>>> >>>
>>>> >>> 131216 08:43:23 mysqld_safe mysqld from pid file
>>>> >>> /var/run/mysqld/mysqld.pid ended
>>>> >>> 131216 08:55:17 mysqld_safe Starting mysqld daemon with databases
>>>> from
>>>> >>> /opt/mysql
>>>> >>> 131216  8:55:17  InnoDB: Initializing buffer pool, size = 5.9G
>>>> >>> 131216  8:55:18  InnoDB: Completed initialization of buffer pool
>>>> >>> 131216  8:55:18  InnoDB: Started; log sequence number 12 4183647936
>>>> >>> InnoDB: !!! innodb_force_recovery is set to 4 !!!
>>>> >>>
>>>> >>>
>>>> >>> We are using Sakai 2.8.x and Tomcat 6 and mysql 5.1.69
>>>> >>> I am wondering whether any other school is having the similar
>>>> problem? I
>>>> >>> am also wondering anybody can shed some light on how I can prevent
>>>> this and
>>>> >>> we are currently at final exam period.  Any suggestion or advice
>>>> will be
>>>> >>> greatly appreciated.
>>>> >>>
>>>> >>> S
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> sakai-dev mailing list
>>>> >>> sakai-dev at collab.sakaiproject.org
>>>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>> >>>
>>>> >>> TO UNSUBSCRIBE: send email to
>>>> >>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>>> >>> "unsubscribe"
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > sakai-dev mailing list
>>>> > sakai-dev at collab.sakaiproject.org
>>>> > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>> >
>>>> > TO UNSUBSCRIBE: send email to
>>>> sakai-dev-unsubscribe at collab.sakaiproject.org
>>>> > with a subject of "unsubscribe"
>>>>
>>>>
>>>>
>>>> --
>>>> John Bush
>>>> 602-490-0470
>>>>
>>>> ** This message is neither private nor confidential in fact the US
>>>> government is storing it in a warehouse located in Utah for future
>>>> data mining use cases should they arise. **
>>>>
>>>
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>> "unsubscribe"
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20131217/58cc9230/attachment.html 