Вопрос: Как исправить ошибку: Lost connection to MySQL server during query?

Лучший ответ: Судя по:Error in `/usr/sbin/mysqld': malloc(): memory corruption: 0x00007fcbfc124080
1. сделать копию /var/lib/mysql на другой накопитель
2. Исследуем и решаем:
2.1. вариант1 - битая память - прогнать memtest, может перегрев системы? устраняем или, если обе проблемы не подтверждаются, то идем дальше. Хотя тут похоже сторонний виртуальный сервер. Но проблема может быть.
Если проблема с ОЗУ, то протестировать внутри ОС можно созданием сжатых архивов и проверкой их целостности, в случае проблем с ОЗУ рано или поздно появятся ошибки контрольных сумм.
2.2. вариант2 - либо испорчены файлы данных, и mysql становится плохо из-за кривого кода. файлы могут быть испорчены некорректным завершением работы сервера либо проблемами с блочным устройством:2018-08-20T05:10:47.359613Z 0 [ERROR] InnoDB: Could not find a valid tablespace file for `kubium/game`. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
2018-08-20T05:10:47.359626Z 0 [Warning] InnoDB: Ignoring tablespace `kubium/game` because it could not be opened.
- это может быть косвенным признаком проблем с файлами.
2.2.1. проверяем состояние блочных устройств smartctl -  наличие offline uncorrectable или relocated sectos - могут быть причиной порчи данных - замена накопителя. Для чужого хостинга это недоступно. Можно косвенно проверить чтением блочного устройства /dev/vda
2.2.2. проверяем fsck файловую систему, наличие ошибок в файловой системы может указывать на повреждение содержания файлов БД. чиним и молимся, что важнейшие файлы не были задеты.
2.2.3. проверяем структуру innodb/myisam файлов, для этого используем штатные средства диагностики или вспомогательные утилиты, например "Percona Data Recovery Tool for InnoDB can help recover corrupted or deleted InnoDB tables. https://launchpad.net/percona-data-recovery-tool-f..." если проблемы - пытаемся чинить. 
Простой старый способ решения некоторых проблем - это dump базы в sql файл , и импорт заново в базу. старую можно переименовать. 
2.2.4. проблема может быть вызвана повреждением файлов индексов, в этом случае пересоздание индексов может все решить. 
2.3. вариант3 - похожие проблемы могут наблюдаться при подсовывании двоичных файлов баз от более свежей версии mysql - проверяем эту версию.
Можно попробовать обновить версию mysql или сменить ее на mariadb, возможно некоторые проблемы уже решены. 
На машине немного памяти - 1Гб, при исчерпании свободного ОЗУ в системе запускается OOM Killer, который убивает процессы в системе, вполне мог убить процесс  mysql прямо посередине критичного изменения файлов БД. Это можно найти в логах.

Худший ответ: Видно что-то навернулось с файлами БД и также ошибка повреждения памяти.Добавлено
Судя по всему, произошёл серьезный сбой в QEMU либо вызван сбоем в хост-машине. В результате во время работы СУБД файлы БД, включая служебные файлы, были повреждены (как минимум, файлы в директории /var/lib/mysql ). Стоит проверить также целостность самой ОС.
Рекомендую объявить посетителям о проблеме, а тем временем обратиться к специалистам по восстановлению MySQL + InnoDB, поскольку хорошего бекапа не было.
Имеет смысл создать TAR архив со сжатием директории /var/lib/mysql с надеждой на последующее восстановление данных.