Fairly recent installation, no aircraft visible, checking and found MySQL is stopped

[ohange]

Installation: Pi3, Raspibian Stretch, separate Pi from FlightAware receiver (using PiAware 3.5.3)

When I went to the IP of FAM, it loads but shows 0 aircraft. I thought that was odd, so I started poking around. Rebooted. Noticed this repeating pattern in /var/log/daemon.log:

Starting MariaDB database server... mariadb.service: Main process exited, code=killed, status=6/ABRT

Looking in var/log/mysql, I see a 7GB error.log file where this thing has been wedged for a few days and is generating tons of error output.

It's probably easier to reinstall a blank database than recover, and the installation is new enough that the value of the historical info is not really significant.

What's the best approach to take to lay down a fresh db and get FAM up and running again?

[Ysurac]

I think it would be far better to find why MariaDB exit ;)

[ohange]

Agreed, but this seems rather generic of a db corruption, which could be a matter of a power interruption, and likely not application related. (I could be wrong though!)

Here is the head of error.log for mysql. (I figure the first error is likely most important).

2018-07-11 21:10:10 1564472128 [ERROR] InnoDB: Space id and page n:o stored in the page read in are 4294967295:4294967295, should be 40:683!
2018-07-11 21:10:10 5d3ff340 InnoDB: Error: page 4294967295 log sequence number 18446744073709551615
InnoDB: is in the future! Current system log sequence number 5237477110.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2018-07-11 21:10:10 1564472128 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace flightairmap/aircraft_owner page  [page id: space=40, page number=683]. You may have to recover from a backup.
2018-07-11 21:10:10 5d3ff340 InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

-- the ffffff just repeats as it's a page dump. then, following the page dump: ``` InnoDB: End of page dump 2018-07-14 14:21:25 76fa7000 InnoDB: uncompressed page, stored checksum in field1 4294967295, calculated checksums for field1: crc32 2794410118, innodb 1239623680, none 3735928559, stored checksum in field2 4294967295, calculated checksums for field2: crc32 2794410118, innodb 391864832, none 3735928559, page LSN 4294967295 4294967295, low 4 bytes of LSN at page end 4294967295, page number (if stored to page already) 4294967295, space id (if created with >= MySQL-4.1.1 and stored already) 4294967295 InnoDB: page type 65535 meaning PAGE TYPE CORRUPTED 2018-07-14 14:21:25 1996124160 [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 corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html for information about forcing recovery. InnoDB: Error: trying to access page number 4294962431 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 2018-07-14 14:21:25 76fa7000 InnoDB: Assertion failure in thread 1996124160 in file fil0fil.cc line 6380 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to 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.6/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 180714 14:21:25 [ERROR] mysqld got signal 6 ; 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. To report this bug, see https://mariadb.com/kb/en/reporting-bugs We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 10.1.23-MariaDB-9+deb9u1 key_buffer_size=16777216 read_buffer_size=131072 max_used_connections=0 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 351335 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... stack_bottom = 0x0 thread_stack 0x30000 The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. ```

[Ysurac]

True, this seems in really bad state... To install a new DB for FlightAirMap, you need to have a working MariaDB server (you may try to run mysqld_safe and remove the FAM DB, else if you only have FlightAirMap DB on your MariaDB, remove anything in /var/lib/mysql), then create FAM DB and user and run the install script again, if no table exists, they will be created.