MySql 8 se prăbușește în buclă fără erori specifice și cu suficientă memorie

Rulez Ubuntu 20.04.03 cu Mysql 8.0.27. Am reinstalat LAMP de la zero de mai multe ori și momentan am doar 3 site-uri WordPress dar am testat doar 1 și doar 2 site-uri. Am crescut RAM la 2 GB și 3 GB Swap.

Nimic nu pare să funcționeze, deoarece Mysql 8.0.27 continuă să se prăbușească, provocând o problemă de conexiune la baza de date în fiecare site în fiecare noapte, chiar și atunci când acestea sunt site-uri complet noi, fără trafic. Când editez o postare sau chiar răsfoiesc oricare dintre acele site-uri, MySql se blochează din nou. Uneori nici nu va începe cu systemctl reporniți mysql.

Jurnalul de erori Apache nu arată nimic important:

/usr/sbin/mysqld (mysqld 8.0.27-0ubuntu0.20.04.1) începând cu procesul 1524639

Inițializarea InnoDB a început.

Inițializarea InnoDB s-a încheiat.

Se pornește recuperarea în caz de accident XA... Recuperarea în caz de accident XA s-a încheiat.

O versiune TLS depreciată TLSv1 este activată pentru canalul mysql_main

O versiune TLS depreciată TLSv1.1 este activată pentru canalul mysql_main

Certificatul CA ca.pem este autosemnat.

Canalul mysql_main configurat să accepte TLS. Conexiunile criptate sunt acum acceptate pentru acest canal.

X Plugin gata pentru conexiuni. Adresă de legătură: port „127.0.0.1”: 33060, socket: /var/run/mysqld/mysqlx.sock

Am verificat deja că, de fapt, configurația încarcă toate versiunile TLS ca fiind acceptabile. Deci nicio eroare reală acolo.

journalctl -u mysql Ultimul jurnal de jurnal:

28 ianuarie 10:29:37 www.ignicion.org systemd[1]: mysql.service: Eșuat cu „semnal” rezultat.
28 ianuarie 10:29:37 www.ignicion.org systemd[1]: mysql.service: Lucrare de repornire programată, contorul de repornire este la 5.
28 ianuarie 10:29:37 www.ignicion.org systemd[1]: S-a oprit MySQL Community Server.
28 ianuarie 10:29:37 www.ignicion.org systemd[1]: Se pornește MySQL Community Server...
28 ianuarie 10:29:43 www.ignicion.org systemd[1]: mysql.service: Procesul principal a ieșit, code=killed, status=9/KILL
28 ianuarie 10:29:43 www.ignicion.org systemd[1]: mysql.service: Eșuat cu „semnalul” rezultat.
28 ianuarie 10:29:43 www.ignicion.org systemd[1]: Nu s-a pornit MySQL Community Server.
28 ianuarie 10:29:43 www.ignicion.org systemd[1]: mysql.service: Lucrare de repornire programată, contorul de repornire este la 6.
28 ianuarie 10:29:43 www.ignicion.org systemd[1]: S-a oprit MySQL Community Server.
28 ianuarie 10:29:43 www.ignicion.org systemd[1]: Se pornește MySQL Community Server...
28 ianuarie 10:29:50 www.ignicion.org systemd[1]: Am pornit MySQL Community Server.

Știu că este o problemă de memorie, dar de ce? Nu este ca și cum serverul face atât de mult. Am monitorizat procesul și Mysql este cel care consumă toată memoria. Aceeași baze de date noi funcționau bine pe ubuntu 18, așa că am rămas fără idei și nu găsesc nicio soluție la problemele conexe pe care le-am găsit pe forum. Unele soluții pe care le-am găsit vorbesc despre corupția bazelor de date/tabelelor, dar acestea sunt baze de date noi, iar defecțiunea hardware a fost eliminată de Digital Ocean Support.

Voi aprecia orice perspectivă

Actualizare #1 Nu există niciun backup sau orice altă sarcină programată. Este doar o instalare nouă și baze de date noi. Acesta este fișierul meu de configurare în ubuntu 20: /etc/mysql/mysql.conf.d

[mysqld]
utilizator = 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

Și din fișierul meu jurnal Kernel (tail -100 /var/log/kern.log) se pare că SIGKILL 9 Semnal de ucidere a termenului semnalul ucide mysql din cauza utilizării prea mari a memoriei

28 ianuarie 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 ianuarie 18:12:26 www kernel: [623011.971617] Memorie epuizată: proces ucis 166978 
5 (mysqld) total-vm:720836kB, anon-rss:292028kB, fișier-rss:804kB, shmem-rss:0kB, 
UID:113 pgtables:816kB oom_score_adj:0

28 ianuarie 18:12:26 www kernel: [623012.005506] oom_reaper: proces cules 1669785 (mysqld), acum anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Așa că citeam că ar trebui să verific configurația bufferelor Mysql și acolo sunt în acest moment.

ACTUALIZARE #2 cat /proc/meminfo

MemTotal: 2030808 kB
MemFree: 54016 kB
MemDisponibil: 3424 kB
Buffere: 240 kB
Memorate în cache: 285620 kB
Schimbat în cache: 44532 kB
Activ: 1188660 kB
Inactiv: 495868 kB
Activ(anon): 1187984 kB
Inactiv(anon): 495088 kB
Activ(fișier): 676 kB
Inactiv(fișier): 780 kB
Inevitabil: 19120 kB
Mlocked: 19120 kB
Schimb total: 3145724 kB
Schimb gratuit: 0 kB
Murdar: 0 kB
Scriere inversă: 0 kB
AnonPagini: 1383352 kB
Cartografiat: 284872 kB
Shmem: 276064 kB
KRecuperabil: 47968 kB
Placă: 171388 kB
SRecuperabil: 47968 kB
Reclamă SUN: 123420 kB
KernelStack: 7744 kB
PageTabele: 59832 kB
NFS_Instabil: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 4161128 kB
Committed_AS: 9186644 kB
VmallocTotal: 34359738367 kB
VmallocUtilizat: 16512 kB
VmallocChunk: 0 kB
Percpu: 1808 kB
Hardware corupt: 0 kB
AnonHugePagini: 0 kB
ShmemHugePagini: 0 kB
ShmemPmdMapped: 0 kB
FileHugePagini: 0 kB
FilePmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Dimensiune mare a paginii: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 1335276 kB
DirectMap2M: 761856 kB

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

PID UTILIZATOR %CPU %MEM VSZ RSS TTY STAT COMANDA TIME START
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

Și din moment ce am crezut că are legătură cu unele variabile mysql, am rulat MySql Tunner și aceasta a fost recomandarea:

Variabile de ajustat:
    innodb_buffer_pool_size (>= 391.3M) dacă este posibil.
    innodb_log_file_size ar trebui să fie (=16M) dacă este posibil, astfel încât dimensiunea totală a fișierelor jurnal InnoDB este egală cu 25% din dimensiunea pool-ului de buffer.

Așa că voi testa pentru a crește acest lucru și voi posta rezultatele.

ACTUALIZARE #3 Adăugat innodb_buffer_pool_size = 512M pentru a mea /etc/mysql/mysql.conf.d/mysqld.cnf fișier și încă se prăbușește. Jurnalele sunt în continuare la fel. :(

Este normal ca memoria mea Total Large alocată să fie zero când rulez Show Stare motor InnoDB;

-----------------------
PISCINA TAMPON ȘI MEMORIE
-----------------------
**Memorie mare totală alocată 0**
Memoria de dicționar alocată 1009720
Dimensiunea piscinei tampon 32765
Buffere gratuite 29298
Paginile bazei de date 3405
Paginile vechi ale bazei de date 1276
Paginile db modificate 0

Și ce zici când voi alerga la spectacol variabile precum „innodb_%”;

innodb_buffer_pool_size | 536870912
innodb_change_buffer_max_size | 25

De ce dimensiunea pool-ului de buffer nu se potrivește și ce aceasta innodb_change_buffer_max_size înseamnă? Ce alte variabile ar trebui să verific? Multumesc din nou baieti

Bine. Rezolvat acum. Nu există o soluție specifică pentru acest tip de comportament, deoarece nucleul ucide mysql din cauza utilizării prea multă RAM și când încercați să aflați de ce, nu există motive specifice. Deci singurul lucru pe care îl puteți face este să încercați să vă jucați cu variabilele și să testați multe. Ce am invatat:

• Din scurta mea experiență, nu știam că fișierul de configurare Myslq (/etc/mysql/mysql.conf.d/mysqlconf.d pe Ubuntu 20.04) nu afișează multe variabile pe el, deoarece aceste variabile sunt setate implicit, așa că dacă am Dorim să setăm o valoare diferită, trebuie să adăugăm manual fiecare variabilă în fișierul de configurare.

• Instalați și rulați mysql tuner (google it), astfel încât să poată indica de unde să începeți pentru setările dvs. specifice. În cazul meu, a sugerat creșterea innodb_buffer_pool_size. Și că innodb_log_file_size ar trebui să fie egal cu 25% din valoarea innodb_buffer_pool_size pentru o performanță optimă. de exemplu, innodb_buffer_pool_size = 1 Gb innodb_log_file_size = 0,25 Gb

• Am setat innodb_buffer_pool_size = 512M deoarece am 2 GB RAM. Acest lucru a făcut ca serverul să dureze puțin mai mult înainte de a se prăbuși din nou. Deci, de aici trebuie să începeți să aflați mai multe despre fiecare variabilă Mysql și să faceți calcule în funcție de dimensiunea bazei de date.

Iată ultimul meu fișier de configurare Mysql, așa că sunteți liber să încercați această configurație. Doar să știți că dimensiunea bazelor mele de date este de 394 MB în acest moment:

[mysqld]
skip-log-bin
utilizator = 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 = activat
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 # Utilizați 1 instanță per 1 GB de dimensiune a pool-ului InnoDB
innodb_buffer_pool_size = 400M # Utilizați până la 70-80% din RAM
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

# Numărul de secunde în care serverul așteaptă activitatea pe o conexiune interactivă înainte de a o închide.
interactive_timeout = 600

# Numărul de secunde în care serverul așteaptă activitatea pe o conexiune neinteractivă înainte de a o închide.
wait_timeout = 600
net_read_timeout = 300
net_write_timeout = 300
connect_timeout = 1800

# Setări de masă
table_definition_cache = 1K
table_open_cache = 2K
table_open_cache = 2K
limita_fișiere_deschise = 4000

max_heap_table_size = 100M
tmp_table_size = 100M

#
# * Configurare cache de interogări
#
#query_cache_limit = 1M
#query_cache_size = 100M
#query_cache_size = 0
#query_cache_type = 0



# Setări tampon
join_buffer_size = 256K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
sort_buffer_size = 128K
performance_schema = ON

Dacă dimensiunea bazelor mele de date crește cu timpul (cu siguranță o vor face) va trebui să măresc aceste valori:

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

Aș putea crește innodb_buffer_pool_size la 1Gb, dar asta va însemna că va trebui să reduc alte variabile și să testez din nou pentru a testa cele mai bune setări de performanță. (cum am spus, dacă nu știți, este nevoie de multă cercetare despre aceste variabile) Pe de altă parte, aș putea lăsa aceleași valori chiar dacă bazele mele de date cresc cu timpul, dar Mysql va începe să ia mai multă memorie Swamp, astfel încât interogările vor fi puțin mai lente cu timpul.

Și apoi din nou, ați putea doar să creșteți memoria RAM de pe server dacă vă puteți permite.

Sper că asta ajută pe cineva.Nu am experiență, așa că postez aceste răspunsuri și pentru referința mea viitoare :)