MySQL Error Message – Troubleshooting Guide

You have an unsupported option specified, either in the my.cnf file, or in the startup script. Likely, this option was valid with the previous version of MySQL you were running, and this option was deprecated in a later release (which would likely have produced a [WARNING] during startup), and then later was made invalid in the release you are now trying to run.

Given that this error message is the last one before the "Aborting" message line, this may be the problem.

Excerpt from the startup messsages:

[ERROR] /usr/local/mysql/bin/mysqld: unknown option '--skip-locking'
[ERROR] Aborting

Likely, the existing my.cnf configuration file was retained; the upgrade didn't make any changes to this file.

The "fix" would be to locate that option in the my.cnf file, and remove it, replace it with whatever the newer replacement syntax is.

There's a sequence of directories where mysqld looks for the my.cnf file, depending on release and OS ( /etc/my.cnf, /etc/mysql/my.cnf, mysql installation directory, etc. (We run MySQL on Linux, not familiar with differences on OSX).

Note that options can also be specified on the command line that starts mysqld; it's much less likely, but it's possible that this option is being supplied from mysqld_safe script.)

The cause for the problem was most likely an HDD error, while MySQL was writing in table "xyz". Finally I was able to recover the system. Here is what I did:

1. Data Backup including MySQL datadir (table "xyz" and my "ibdata" could be read/copied, so no complete backup possible) Ran chkdsk —> found but didn’t repair bad sectors
2. ran HDD Regenerator v2011 —> found and repaired bad sectors
3. Completed Backup
4. Tested if MySQL would run after regeneration —> didn’t work
5. added innodb_force_recovery=1 … 6 to [mysqld] section in my config file (MySQL started only with max value "6")
6. used mysqlcheck db_name -u root -p to check which table(s) are corrupted
7. used mysqluc > mysqlfrm to obtain the table structure of the corrupted table (worked only with --diagnostic option)
8. used myisamchk -r -q table_name to fix the broken table (this table used the myisam engine)
9. see this: http://dev.mysql.com/doc/refman/5.7/en/myisam-repair.html
10. I had to use this trick to get it working: FOR %G IN (dir \b c:\mysql\data\mydb\*.myi) DO myisamchk -r -f %G (https://iandunn.name/myisamchk-error-22-on-windows/)
11. Originally the table had 55721190 rows, after myisamchk repair it had 55721166 rows (no problem for me, because i could identify and restore the lost rows)
12. Backup
13. mysqldump -u root -p my_schema > .../recovery_dump.sql
14. mysql drop all_databases, stopped server, moved ibdata1 and iblogs to tmp folder, deleted innodb_force_recovery=6 in config file, started server
15. mysql -u root -p my_schema < .../recovery_dump.sql

This "InnoDB Corruption Repair Guide" was a great help. (https://forums.cpanel.net/threads/innodb-corruption-repair-guide.418722/)