# MySQL Database Faulted **URL:** \ **Category:** General Discussion\ **Created:** [May 30, 2017, 12:40pm UTC](https://forum.inductiveautomation.com/t/mysql-database-faulted/14418 "2017-05-30T12:40:09Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![gglenn](https://avatars.discourse-cdn.com/v4/letter/g/b19c9b/32.png) [@gglenn](https://forum.inductiveautomation.com/u/gglenn)\ **Post date:** [May 30, 2017, 12:40pm UTC](https://forum.inductiveautomation.com/t/mysql-database-faulted/14418/1 "2017-05-30T12:40:09Z")
Just this past Friday the database connection was reported as faulted. Up till then my Ignition application has been working perfectly and there have been no recent changes or updates. Looking at the Gateway it indicated MySQL connection was lost. Opened MySQL diagnostics and found this report. I tried to restart MySQL but this report is regenerated each time. Any suggestions? 2017-05-30 06:10:49 - Starting server… 2017-05-30 06:11:02 - Server start done. FROM DPE-D-GYSNBZ1.err: 2017-05-30T11:10:59 0 Warning TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit\_defaults\_for\_timestamp server option (see documentation for more details). 2017-05-30T11:10:59 0 Warning ‘NO\_ZERO\_DATE’, ‘NO\_ZERO\_IN\_DATE’ and ‘ERROR\_FOR\_DIVISION\_BY\_ZERO’ sql modes should be used with strict mode. They will be merged with strict mode in a future release. 2017-05-30T11:10:59 0 Note C:\Program Files\MySQL\MySQL Server 5.7\bin\mysqld.exe (mysqld 5.7.13-log) starting as process 9172 … 2017-05-30T11:10:59 0 Note InnoDB: Mutexes and rw\_locks use Windows interlocked functions 2017-05-30T11:10:59 0 Note InnoDB: Uses event mutexes 2017-05-30T11:10:59 0 Note InnoDB: \_mm\_lfence() and \_mm\_sfence() are used for memory barrier 2017-05-30T11:10:59 0 Note InnoDB: Compressed tables use zlib 1.2.3 2017-05-30T11:10:59 0 Note InnoDB: Adjusting innodb\_buffer\_pool\_instances from 8 to 1 since innodb\_buffer\_pool\_size is less than 1024 MiB 2017-05-30T11:10:59 0 Note InnoDB: Number of pools: 1 2017-05-30T11:10:59 0 Note InnoDB: Not using CPU crc32 instructions 2017-05-30T11:10:59 0 Note InnoDB: Initializing buffer pool, total size = 8M, instances = 1, chunk size = 8M 2017-05-30T11:10:59 0 Note InnoDB: Completed initialization of buffer pool 2017-05-30T11:11:00 0 Note InnoDB: Highest supported file format is Barracuda. 2017-05-30T11:11:00 0 Note InnoDB: Log scan progressed past the checkpoint lsn 236924383454 2017-05-30T11:11:00 0 Note InnoDB: Doing recovery: scanned up to log sequence number 236927666988 2017-05-30T11:11:00 0 Note InnoDB: Database was not shutdown normally! 2017-05-30T11:11:00 0 Note InnoDB: Starting crash recovery. 2017-05-30T11:11:00 0 Note InnoDB: Starting an apply batch of log records to the database… InnoDB: Progress in percent: 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 2017-05-30T11:11:01.438619Z 0 [ERROR] I [truncated, 405 bytes total] 2017-05-30T11:11:01 0 Note InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex a422a4f20004f7780004f777000003bc0000003729cb610a45bf000000000000000000000057000503a9801500000000038400020011001300000000000000000000000000000000005d00000000000000000000000000000000000000000100020046696e66696d756d0008000b000073757072656d756d [truncated, 48.1 KB total] InnoDB: End of page dump 2017-05-30T11:11:01 0 Note InnoDB: Uncompressed page, stored checksum in field1 2753733874, calculated checksums for field1: crc32 2964787571/239699844, innodb 1527697333, none 3735928559, stored checksum in field2 922854125, calculated checksums for field2: crc32 2964787571/2396998 [truncated, 473 bytes total] InnoDB: Page may be an index page where index id is 93 2017-05-30T11:11:01 0 Note InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the co [truncated, 451 bytes total] 2017-05-30T11:11:01 0 ERROR] [FATAL InnoDB: Aborting because of a corrupt database page in the system tablespace. Or, there was a failure in tagging the tablespace as corrupt. 2017-05-30 06:11:01 0x2204 InnoDB: Assertion failure in thread 8708 in file ut0ut.cc line 920 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to [http://bugs.mysql.com](http://bugs.mysql.com). InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: [http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html](http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html) InnoDB: about forcing recovery. 11:11:01 UTC - mysqld got exception 0x80000003 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key\_buffer\_size=8388608 read\_buffer\_size=20480 max\_used\_connections=0 max\_threads=151 thread\_count=0 connection\_count=0 It is possible that mysqld could use up to key\_buffer\_size + (read\_buffer\_size + sort\_buffer\_size)\*max\_threads = 51702 K bytes of memory Hope that’s ok; if not, decrease some variables in the equation. Thread pointer: 0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong… 13f96ab42 mysqld.exe!my\_errno() 13fd0ef09 mysqld.exe!my\_wildcmp\_mb() 13fd0de00 mysqld.exe!my\_wildcmp\_mb() 13fa6bd88 mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX\_K@Z() 13fa6bfa1 mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX\_K@Z() 13fb7eb50 mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX\_K@Z() 13fa92c4f mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX\_K@Z() 13fa36574 mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX\_K@Z() 779459cd kernel32.dll!BaseThreadInitThunk() 77b7a561 ntdll.dll!RtlUserThreadStart() The manual page at [http://dev.mysql.com/doc/mysql/en/crashing.html](http://dev.mysql.com/doc/mysql/en/crashing.html) contains information that should help you find out what is causing the crash. 2017-05-30 06:11:03 - Checking server status… 2017-05-30 06:11:03 - Trying to connect to MySQL… 2017-05-30 06:11:03 - Can’t connect to MySQL server on ‘127.0.0.1’ (10061) (2003) 2017-05-30 06:11:03 - Assuming server is not running 2017-05-30 06:11:03 - Checking server status… 2017-05-30 06:11:03 - Trying to connect to MySQL… 2017-05-30 06:11:03 - Can’t connect to MySQL server on ‘127.0.0.1’ (10061) (2003) 2017-05-30 06:11:03 - Assuming server is not running ---
**Author:** ![robinsanshaw](https://avatars.discourse-cdn.com/v4/letter/r/7cd45c/32.png) [@robinsanshaw](https://forum.inductiveautomation.com/u/robinsanshaw)\ **Post date:** [September 18, 2017, 1:02pm UTC](https://forum.inductiveautomation.com/t/mysql-database-faulted/14418/2 "2017-09-18T13:02:40Z")
Hello gglenn, I see that you are struggling to establish a connection with your SQL server database. One of the several reasons to your problem can be that your database has been marked as SUSPECT. For more information about this and to solve your issue refer to the blog link given below. Hope it helps! [https://alessandroalpi.blog/2017/09/12/best-solutions-to-repair-suspect-database-in-ms-sql-server/](https://alessandroalpi.blog/2017/09/12/best-solutions-to-repair-suspect-database-in-ms-sql-server/)