Nach dem Reboot eines mysql-Rechners (genauer: in einem Docker-Container – in einer ESXi-VM) ließ sich der mysql-Dämon nicht mehr zum Starten bewegen. Das Vertrackte dabei war, dass
- wirklich alles sauber runter- und wieder hoch-gefahren wurde und
- mysql keine nennenswert hilfreichen (Fehler-)Meldungen brachte – sondern nur das hier: (ich kann das nicht mehr 100% sicher sagen, weil das docker-logfile nicht mehr da ist, aber ich bin mir recht sicher, dass es etwa so ausgesehen haben muss)
mysql_1 | 2016-06-05T17:00:31.078345Z 0 [Note] mysqld (mysqld 5.7.12) starting as process 1 ...
mysql_1 | 2016-06-05T17:00:31.086907Z 0 [Note] InnoDB: PUNCH HOLE support available
mysql_1 | 2016-06-05T17:00:31.086936Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
mysql_1 | 2016-06-05T17:00:31.086942Z 0 [Note] InnoDB: Uses event mutexes
mysql_1 | 2016-06-05T17:00:31.086946Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
mysql_1 | 2016-06-05T17:00:31.086950Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.8
mysql_1 | 2016-06-05T17:00:31.086953Z 0 [Note] InnoDB: Using Linux native AIO
mysql_1 | 2016-06-05T17:00:31.087120Z 0 [Note] InnoDB: Number of pools: 1
mysql_1 | 2016-06-05T17:00:31.087219Z 0 [Note] InnoDB: Using CPU crc32 instructions
mysql_1 | 2016-06-05T17:00:31.095319Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
mysql_1 | 2016-06-05T17:00:31.106130Z 0 [Note] InnoDB: Completed initialization of buffer pool
mysql_1 | 2016-06-05T17:00:31.108964Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
Danach bliebt er einfach (ohne CPU-Last) stehen. Und das gleich bei mehreren mysql-Servern in verschiedenen Docker-Containern.
Die Lösung (oder der Workaround – ich habe nichts verstanden…) war dann das Löschen (bzw Umbenennen) des Files ibtmp1 im mysql-Datenverzeichnis (/var/lib/mysql im Container). Das kannte ich noch nicht. Dazu steht was in den mysql 5.7 Release-Notes. Vertrauen, das einfach mal zu probieren, hat mir der Satz „The new tablespace is always recreated on server startup“ geschenkt. Danach ist der mysqld einfach wieder hochgefahren – ebenfalls ohne nennenswert auffällige Meldungen.
Das hat mich Stunden Sucherei und 36h Downtime gekostet und gelernt habe ich quasi nichts. Vielleicht gibt es ja eine Erklärung für das Verhalten. Scheint ja was mit mysql 5.7 zu tun zu haben.