polozad

Вы только клиент и сервер обновили. Посмотрите libmysqlclient или что-то в этом роде.

На каком интерфейсе мускуль слушает? Где бэкенд и как он к мускулю подключается?

2015-07-20 19:42:25 5672 [ERROR] InnoDB: space header page consists of zero bytes in data file F:\Server\web\apache\mysql\data\ibdata1
2015-07-20 19:42:25 5672 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!

Тут всё написано.
F:\Server\web\apache\mysql\data\ibdata1 битый.

Мускуль 5.6, GTID и можно строить какие угодно топологии.

Разве там нет скриптов с эволюциями баз данных при апгрейде версии форума? Ни за что не поверю.

Постгрес поддерживает SQL99 и SQL2008, чего мускулю здорово не хватает. Разговор стоит вести ещё и в разрезе движков, которых у мускуля вовсе не один.

Вероятно, у вас бэкенд написан настолько криво, что не использует pool соединений, открывая каждый раз новое и не закрывая по итогу. В mysql есть стандартная настройка устаревания соединений - через 8 часов коннекшн сбрасывается. Смотрите код бэкенда, пинайте программиста, читайте php.net/manual/ru/mysqlnd-ms.pooling.php
В самом mysql можно запросить show processlist и поглазеть на конкретные процессы.
А ещё вероятнее, у вас mod_php. В таком случае можно перейти на nginx+php-fpm.

mysql в лог что-то пишет?

log-slow-queries включить что-то мешает?

У mysql весеннее обострение нынче. Берёт и жрёт память как спятивший, без каких-то внешних причин типа выросшей базы, например, на innodb, которая активно грузится в память. Да?

А техподдержку уже погладили по голове за отсутствие бэкапов? Какой движок используется? Innodb? Тогда возможно восстановление на основе бинарных логов и redo-журнала, как тут уже сказали. И вообще, лог в студию, что там за ошибки-то.

Типичная проблема - большие логи, которые удалены, вернее, количество хардлинков у которых меньше единицы. С точки зрения системы файл удалён, на деле же он может быть открыт на запись/чтение и не удалён физически. lsof +L1 покажет список таких файлов. Ну и выход из такой ситуации - только перезапуск сервиса, который держит файл.