hx510b

Попробуйте добавить в конфиг файл mysql, например так:

[mysqld]
init_connect='SET collation_connection = utf8mb4_unicode_ci'
collation-server=utf8mb4_unicode_ci

Чтобы прокинуть конфиг во внутрь docker образа используйте опцию -v

-v /local/path/to/hosts/config/collation.conf:/etc/my.cnf.d/collation.conf

find /pathto [ options ] -delete
удаляет то, что задано и быстрее всех
причем без ключа -delete можно проверить, что список тот который хотелось.

На мой взгляд надо заставить веб-клиента делать какую-то работу, например, ставить куку и смотреть, что он ее предъявил, с помощью javascript на стороне клиента проводить простые вычисления, но не предсказуемые вычисления, которые он должен предъявить.
Брутфорс наверняка идет в отношении конкретного аккаунта, можно на каждую неудачную попытку увеличивать время ответа, чтобы разительно снижать темп перебора.
Можно начать показывать CAPTCHA в случае детектирования таких проблем.
Можно сделать блокировку учетной записи в случае N неудачных попыток за период времени.
Возьмите за образец логику PIN кодов банковский карт - 3 неудачных попытки - блокировка карты. Поэтому даже весьма простой 4-х численный PIN код становится не подбираемым брутфорсом.
Существуют различные практики приблизительной деанонимизации веб-клиента, которые позволят установить, что с разных адресов идет один и тот же веб-клиент.

Сложное объяснение, но видимо методически правильное есть в статье https://habr.com/company/mailru/blog/335326/
Как показывает практика - LA связан не только с вычислительной нагрузкой на CPU, но зависит и от ввода вывода и других факторов состояния системы.
При определенных обстоятельствах вполне можно наблюдать LA в несколько тысяч, при фактически не загруженных процессорах и обычном количестве и состоянии процессов.

Я для себя LA интерпретирую как комплексный показатель нагрузки на систему.
Упрощенно можно воспринимать как некий эфемерный показатель длины очереди процессов на исполнение - это условное заведомо неверное толкование, но вполне применимое в реальной работе.
Интерпретация значений LA:
Где значения от 0 до 1 указывают на не нагруженную систему близкую к простою.
Значения от 1 до 10 - как умеренно нагруженную систему. Все нормально.
Значения от 10 до 30 - как высоконагруженную систему. Не следует добавлять нагрузку. Можно подумать о поиске оптимизации нагрузки. Оптимизация рекомендуется.
Значения от 30 до 100 - как чрезмерно нагруженную систему, например, причиной может быть большая доля iowait из-за перегрузки - большое количество потоков ввода вывода на одно блочное устройство, аномально медленная работа блочного устройства из-за неисправности, другие подобные причины, связанные с возникновением "бутылочного горлышка" в системе, которое надо расшивать - при таких значениях LA - производительность неэффективная. Оптимизация необходима.
Значения выше 100 - следует воспринимать как аварийное состоянии системы с точки зрения производительности. Нужно принимать меры безотлагательно.
Значения выше 1000 - и дальнейший рост LA ведут к падению ядра, как правило, падение системы происходит в течении ближайших нескольких часов. Требуется экстренная реакция для избежания отказа систем и потери данных.
Границы указаны примерные на основе своего опыта.

Судя по:

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

Вариант №1 - создание отказоустойчивого кластера - два физических сервера работают в паре, при этом один сервер выполняет работу, а второй сервер работает в резерве, при этом получает актуальные копию данных с первого сервера, делается разными инструментами. В случае гибели первого сервера, второй берет нагрузку на себя.
Вариант №2 - применим для веб-сайтов - пользовательские запросы направляются на сервера по определенным правилам на несколько серверов, в случае выход из строя одного из серверов - нагрузка вырастает на оставшиеся.
Вариант №3 - географически разнесенные дубликаты сервисов - самый надежный вариант, но кластер на длинных расстояниях сделать очень сложно - возникают проблемы с пропускной способностью, задержкой передачи и временными перерывами связи - не все протоколы, работающие в локальной сети способны справиться с этой проблемой.
В целом задача решается с применением известных решений с учетом специфики решаемой задачи и существующей архитектуры сервиса.
Простого решения - панацеи от всех проблем нет.

Под такие задачи вполне хватит EXT4
Не надо хранить на одном большом томе миллионы файлов - этим потом управлять сложно - долго копировать и даже долго удалять.
Храните в файлах архивов или образах дисков виртуальных (loop devices) за счет sparse можно получить такую же плотность размещения.