MySql 8 аварийно завершает работу в цикле без конкретных ошибок и при достаточном количестве памяти.

Я использую Ubuntu 20.04.03 с Mysql 8.0.27. Я несколько раз переустанавливал LAMP с нуля, и на данный момент у меня только 3 сайта WordPress, но я протестировал только 1, а также 2 сайта. Увеличил оперативную память до 2 ГБ и 3 ГБ подкачки.

Ничто, похоже, не работает, потому что Mysql 8.0.27 продолжает вылетать, вызывая проблемы с подключением к базе данных на каждом сайте каждую ночь, даже когда это совершенно новые сайты без какого-либо трафика. Когда я редактирую запись или даже просматриваю любой из этих сайтов, MySQL снова вылетает. Иногда он даже не запускается с systemctl restart mysql.

Журнал ошибок Apache не показывает ничего важного:

/usr/sbin/mysqld (mysqld 8.0.27-0ubuntu0.20.04.1) запускается как процесс 1524639

Инициализация InnoDB начата.

Инициализация InnoDB завершена.

Начинаю восстановление XA после сбоя...
Восстановление XA завершено.

Устаревшая версия TLS TLSv1 включена для канала mysql_main

Устаревшая версия TLS TLSv1.1 включена для канала mysql_main

CA сертификат ca.pem самоподписан.

Канал mysql_main настроен для поддержки TLS. Зашифрованные соединения теперь поддерживаются для этого канала.

Плагин X готов к соединениям. Адрес привязки: '127.0.0.1' порт: 33060, сокет: /var/run/mysqld/mysqlx.sock

Я уже проверил, что конфигурация на самом деле загружает все версии TLS как допустимые. Так что реальной ошибки там нет.

journalctl -u mysql
Последний журнал:

28 янв 10:29:37 www.ignicion.org systemd[1]: mysql.service: Не удалось завершить с результатом 'signal'.
28 янв 10:29:37 www.ignicion.org systemd[1]: mysql.service: Запланирована работа по перезапуску, счетчик перезапусков: 5.
28 янв 10:29:37 www.ignicion.org systemd[1]: Остановлен MySQL Community Server.
28 янв 10:29:37 www.ignicion.org systemd[1]: Запуск MySQL Community Server...
28 янв 10:29:43 www.ignicion.org systemd[1]: mysql.service: Основной процесс завершился, код=killed, статус=9/KILL
28 янв 10:29:43 www.ignicion.org systemd[1]: mysql.service: Не удалось завершить с результатом 'signal'.
28 янв 10:29:43 www.ignicion.org systemd[1]: Не удалось запустить MySQL Community Server.
28 янв 10:29:43 www.ignicion.org systemd[1]: mysql.service: Запланирована работа по перезапуску, счетчик перезапусков: 6.
28 янв 10:29:43 www.ignicion.org systemd[1]: Остановлен MySQL Community Server.
28 янв 10:29:43 www.ignicion.org systemd[1]: Запуск MySQL Community Server...
28 янв 10:29:50 www.ignicion.org systemd[1]: MySQL Community Server запущен.

Я знаю, что это проблема с памятью, но почему? Не так уж и много делает сервер. Я отслеживал процессы, и MySQL – единственный, кто потребляет всю память. Эти же новые базы данных работали нормально на ubuntu 18, так что у меня действительно нет идей и я не могу найти никаких решений на связанные проблемы, которые нашел на форуме. Некоторые решения, которые я нашел, говорят о повреждении базы данных/таблицы, но это совершенно новые базы данных, и проблема с оборудованием была исключена поддержкой Digital Ocean.

Я буду признателен за любые идеи.

Обновление #1
Не создано резервное копирование и никаких других запланированных задач. Это просто новая установка и новые базы данных. Это мой конфигурационный файл в ubuntu 20: /etc/mysql/mysql.conf.d

[mysqld]
user            = mysql
bind-address            = 127.0.0.1
mysqlx-bind-address     = 127.0.0.1
key_buffer_size         = 16M
myisam-recover-options  = BACKUP
log_error = /var/log/mysql/error.log
max_binlog_size   = 100M
innodb_file_per_table = 1

И из моего журнала ядра (tail -100 /var/log/kern.log) кажется, что сигнал SIGKILL 9 Term Kill signal убивает mysql из-за слишком большого потребления памяти.

28 янв 18:12:26 www kernel: [623011.971582] oom-kill:constraint=CONSTRAINT_NONE, 
nodemask= (null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mysql.service,task=mysqld,pid=1669785,uid=113

28 янв 18:12:26 www kernel: [623011.971617] Не хватает памяти: Уб Process 166978 
5 (mysqld) total-vm:720836kB, anon-rss:292028kB, file-rss:804kB, shmem-rss:0kB, 
UID:113 pgtables:816kB oom_score_adj:0

28 янв 18:12:26 www kernel: [623012.005506] oom_reaper: собран процесс 1669785 (mysqld), теперь anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Я читал, что мне нужно проверить конфигурацию буферов MySQL, и именно на этом этапе я нахожусь сейчас.

UPDATE #2
cat /proc/meminfo

MemTotal:        2030808 kB
MemFree:           54016 kB
MemAvailable:       3424 kB
Buffers:             240 kB
Cached:           285620 kB
SwapCached:        44532 kB
Active:          1188660 kB
Inactive:         495868 kB
Active(anon):    1187984 kB
Inactive(anon):   495088 kB
Active(file):        676 kB
Inactive(file):      780 kB
Unevictable:       19120 kB
Mlocked:           19120 kB
SwapTotal:       3145724 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:       1383352 kB
Mapped:           284872 kB
Shmem:            276064 kB
KReclaimable:      47968 kB
Slab:             171388 kB
SReclaimable:      47968 kB
SUnreclaim:       123420 kB
KernelStack:        7744 kB
PageTables:        59832 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4161128 kB
Committed_AS:    9186644 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       16512 kB
VmallocChunk:          0 kB
Percpu:             1808 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:     1335276 kB
DirectMap2M:      761856 kB

ps  -aux --sort -rss|head -5

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql    1715614  6.7 18.8 1763392 383344 ?      Ssl  22:21   0:01 /usr/sbin/mysqld
aceitep+ 1686006  0.0  2.0 342620 41076 ?        S    19:44   0:02 /bin/php-cgi7.4
aceitep+ 1686009  0.0  1.9 265576 39268 ?        S    19:44   0:02 /bin/php-cgi7.4
aceitep+ 1686001  0.0  1.8 342152 38348 ?        S    19:44   0:04 /bin/php-cgi7.4

И так как я думал, что это связано с некоторыми переменными MySQL, я запустил MySQL Tuner, и вот его рекомендации:

Переменные для настройки:
    innodb_buffer_pool_size (>= 391.3M) если возможно.
    innodb_log_file_size должно быть (=16M) если возможно, чтобы общий размер файлов журнала InnoDB составлял 25% от размера пула буферов.

Итак, я протестирую увеличение этого значения и опубликую результаты.

UPDATE #3
Добавил innodb_buffer_pool_size = 512M
в мой /etc/mysql/mysql.conf.d/mysqld.cnf файл и всё равно вылетает. Журналы по-прежнему те же. 🙁

Нормально ли, что мое Общее большое выделение памяти равно нулю, когда я выполняю Show Engine InnoDB status;

----------------------
БУФЕРНЫЙ ПУЛ И ПАМЯТЬ
----------------------
**Общее большое выделенное количество памяти 0**
Выделенная память словаря 1009720
Размер пула буферов   32765
Свободные буферы       29298
Страницы базы данных     3405
Старые страницы базы данных 1276
Измененные страницы БД  0

А что насчет, когда я запускаю show variables like 'innodb_%';

innodb_buffer_pool_size           | 536870912
innodb_change_buffer_max_size    | 25

Почему размер пула буферов не совпадает и что означает этот innodb_change_buffer_max_size? Какие другие переменные мне следует проверить? Спасибо еще раз, ребята.

Хорошо. Теперь решено. Нет конкретного решения для такого поведения, так как ядро убивает mysql из-за слишком большого использования оперативной памяти, и когда вы пытаетесь выяснить почему, нет конкретных причин. Поэтому единственное, что вы можете сделать, – это попробовать поиграть с переменными и много тестировать.
Что я узнал:

• В своем кратком опыте я не знал, что конфигурационный файл Myslq (/etc/mysql/mysql.conf.d/mysqlconf.d на Ubuntu 20.04) не показывает много переменных, так как эти переменные установлены по умолчанию, поэтому, если мы хотим установить другое значение, нам нужно вручную добавить каждую переменную в конфигурационный файл.

• Установите и запустите mysql tuner (поиск в Google), чтобы он мог указать, с чего начать для ваших конкретных настроек. В моем случае он предложил увеличить innodb_buffer_pool_size. И что innodb_log_file_size должен быть равен 25% от значения innodb_buffer_pool_size для оптимальной производительности, например, innodb_buffer_pool_size = 1 ГБ, innodb_log_file_size = 0,25 ГБ.

• Я установил innodb_buffer_pool_size = 512M, так как у меня 2 ГБ ОЗУ. Это просто заставило сервер продержаться чуть дольше, прежде чем снова вылететь. Так что с этого места вам нужно начать учиться больше о каждой переменной MySQL и делать расчеты в зависимости от размера ваших баз данных.

Вот мой окончательный конфигурационный файл Mysql, так что вы можете попробовать эту конфигурацию. Просто знайте, что размер моих баз данных на данный момент составляет 394 МБ:

[mysqld]
skip-log-bin
user            = mysql
bind-address            = 127.0.0.1
mysqlx-bind-address     = 127.0.0.1
myisam-recover-options  = BACKUP
log_error = /var/log/mysql/error.log
general_log = on
general_log_file=/var/log/mysql/general.log

key_buffer_size                 = 1M
max_allowed_packet              = 1M
thread_stack                    = 200K
thread_cache_size               = 8
max_connect_errors              = 100
max_connections                 = 100
#table_cache                    = 64
#thread_concurrency             = 30
binlog_cache_size               = 1M
net_buffer_length               = 1M

default_storage_engine          = InnoDB
innodb_buffer_pool_instances    = 1 # Использовать 1 экземпляр на 1 ГБ размера пула InnoDB
innodb_buffer_pool_size         = 400M   # Использовать до 70-80% ОЗУ
innodb_file_per_table           = 1
innodb_flush_log_at_trx_commit  = 0
innodb_flush_method             = O_DIRECT
innodb_log_buffer_size          = 16M
innodb_log_file_size            = 16M
innodb_stats_on_metadata        = 0
#innodb_thread_concurrency      = 0
innodb_read_io_threads          = 40
innodb_write_io_threads         = 40
innodb_buffer_pool_chunk_size   = 10
innodb_lock_wait_timeout        = 600
innodb_flush_log_at_trx_commit  = 1
innodb_io_capacity              = 3000
innodb_io_capacity_max          = 4000
innodb_buffer_pool_dump_pct     = 80
innodb_flush_neighbors          = 0
innodb_doublewrite              = 0
innodb_change_buffer_max_size   = 10
innodb_old_blocks_pct           = 70
innodb_old_blocks_time          = 5000
innodb_use_native_aio           = ON

# Количество секунд, в течение которых сервер ждет активности по интерактивному соединению перед его закрытием.
interactive_timeout             = 600

# Количество секунд, в течение которых сервер ждет активности по неинтерактивному соединению перед его закрытием.
wait_timeout                    = 600
net_read_timeout                = 300
net_write_timeout               = 300
connect_timeout                 = 1800

# Настройки таблиц
table_definition_cache          = 1K
table_open_cache                = 2K
table_open_cache                = 2K
open_files_limit                = 4000

max_heap_table_size             = 100M
tmp_table_size                  = 100M

#
# * Настройки кеша запросов
#
#query_cache_limit               = 1M
#query_cache_size                = 100M
#query_cache_size                = 0
#query_cache_type                = 0

# Настройки буферов
join_buffer_size                = 256K
read_buffer_size                = 256K
read_rnd_buffer_size            = 256K
sort_buffer_size                = 128K
performance_schema              = ON

Если размер моих баз данных увеличится со временем (что вполне вероятно), мне придется увеличить эти значения:

key_buffer_size = 1M
max_connections = 100
innodb_buffer_pool_size = 400M
join_buffer_size = 256K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
sort_buffer_size = 128K

Я мог бы увеличить innodb_buffer_pool_size до 1 ГБ, но это будет означать, что мне придется уменьшить другие переменные и снова протестировать, чтобы найти оптимальные настройки производительности. (как я уже сказал, если вы не знаете, потребуется много исследований по этим переменным) С другой стороны, я мог бы просто оставить эти же значения, даже если размер моих баз данных увеличится со временем, но MySQL начнет занимать больше памяти подкачки, так что запросы будут немного медленнее с течением времени.

И еще раз, вы можете просто увеличить ОЗУ на своем сервере, если можете себе это позволить.

Надеюсь, это поможет кому-то. Я не опытный, поэтому публикую эти ответы для своих будущих ссылок 🙂