Судя по:
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 прямо посередине критичного изменения файлов БД. Это можно найти в логах.
