Tutorial: Cum să folosești MariaDB 11.4 într-un mediu DirectAdmin legacy bazat pe Debian, ca un sysadmin

Dacă serverul tău DirectAdmin nu poate trece curat la MariaDB 11.4 prin CustomBuild, dar ai nevoie totuși de MariaDB 11.4 pe acel host, modelul manual sigur este destul de simplu: lași Debian să administreze MariaDB 11.4, lași DirectAdmin să se comporte strict ca un client prin da_admin și elimini fișierele de serviciu, binarele și presupunerile despre socket-uri rămase din epoca veche, care intră în conflict cu noul server.

Nu acesta este traseul preferat pe un DirectAdmin modern. Dacă serverul tău poate folosi normal CustomBuild-ul actual, mergi pe acea variantă. Ghidul acesta este pentru cazul-limită în care stratul de panou este mai vechi, fixat într-o anumită stare, migrat doar pe jumătate sau pur și simplu constrâns, în timp ce sistemul de operare și baza de date trebuie totuși duse mai departe în mod curat.

Partea bună este că MariaDB, ca produs, are o logică de upgrade bine documentată și previzibilă. Partea dificilă nu este MariaDB 11.4 în sine. Partea dificilă este integrarea unui set modern de pachete MariaDB într-un mediu DirectAdmin legacy, fără să permiți unor definiții vechi de servicii, unor wrapper-e rămase prin sistem sau unor presupuneri expirate despre socket-uri să preia controlul.

Modelul de lucru este simplu: Debian deține MariaDB, DirectAdmin se conectează prin da_admin, iar reziduurile vechi nu mai au voie să controleze nimic.

Dacă administrezi des servere de panou mai vechi, acest tutorial se leagă firesc de Licența DirectAdmin Legacy se încheie în iulie 2026: ce se schimbă, capcana EOL pentru MariaDB 10.6 și opțiunile de migrare și de MariaDB vs. MySQL 8.0: Performance Benchmarks & Configuration Guide for VPS. Dacă ai nevoie de un host curat pentru astfel de operațiuni, pornește de la Serverele Virtuale ServerSpan. Dacă preferi ca stratul de Linux și baze de date să fie ținut în ordine de altcineva, aici Administrarea Linux ServerSpan devine alegerea logică.

Când are sens, de fapt, acest ghid

Folosește ghidul acesta atunci când toate condițiile de mai jos sunt adevărate:

• ești pe Debian sau Ubuntu, ori pe un alt host DirectAdmin din aceeași familie operațională
• ai nevoie acum de MariaDB 11.4 pe sistem
• nu folosești traseul obișnuit prin CustomBuild pentru stratul de bază de date
• DirectAdmin încă trebuie să poată crea utilizatori, baze de date și granturi prin da_admin
• ești dispus să validezi migrarea ca un sysadmin, nu ca cineva care speră că panoul îl va salva

Nu folosi acest ghid pe un deployment DirectAdmin nou care suportă deja MariaDB 11.4 prin calea standard. Și nu îl folosi pe un server pe care nu ești pregătit să faci și să verifici backupuri reale înainte de orice. Un downgrade major de MariaDB nu este ceva ce trebuie tratat ca simplu sau de rutină.

Înainte să atingi ceva: înțelege modelul

Tiparul obișnuit de eșec în stack-urile de baze de date DirectAdmin mai vechi nu este că MariaDB 11.4 ar fi instabilă. În majoritatea situațiilor, stratul MariaDB se comportă exact cum este documentat. Fricțiunea vine din amestec de pachete și din presupuneri rămase din epoca mai veche a DirectAdmin.

• pachetele noi MariaDB 11.4 sunt instalate din MariaDB APT repository
• binare vechi MySQL sau MariaDB încă există sub /usr/local/
• un mysqld.service custom și vechi încă trăiește sub /etc/systemd/system/
• vechile căi de socket încă sunt hardcodate în scripturi sau în setări locale de client
• DirectAdmin continuă să vorbească fie cu binarul greșit, fie cu socket-ul greșit, fie cu contul greșit

Remedierea nu este sofisticată. Este disciplinată. Îngheți monitorizarea DirectAdmin, faci backup la datadir, oprești orice proces care mai poate atinge fișierele bazei de date, elimini coliziunile de servicii și PATH, instalezi un set curat de pachete MariaDB 11.4, rulezi utilitarul real de upgrade, refaci compatibilitatea doar acolo unde este necesară, păstrezi DirectAdmin pe da_admin și abia apoi dai din nou drumul panoului.

Faza 0: îngheață monitorizarea serviciului MySQL din DirectAdmin

Înainte să înlocuiești sau să restartezi orice, oprește DirectAdmin din a încerca să „te ajute” prin restartarea serviciului greșit în mijlocul operațiunii.

sed -i -e 's/mysqld=ON/mysqld=OFF/g' /usr/local/directadmin/data/admin/services.status

Asta contează pentru că DirectAdmin monitorizează starea serviciilor prin acel fișier. Dacă lași monitorizarea activă în timpul unei migrări manuale de bază de date, panoul poate interveni exact în momentul cel mai prost, fie la oprire, fie la pornire, fie la tratarea unei erori.

Faza 1: fă backup la datadir înainte de orice pas destructiv

Nu sări peste asta. Fă backup la întregul datadir înainte să cureți binare, wrapper-e sau unități de serviciu. Dacă datele contează, planul tău real de rollback este backupul făcut înainte de upgrade, nu speranța că vei improviza după aceea.

cp -a /var/lib/mysql /var/lib/mysql.pre-mariadb-11.4.$(date +%F-%H%M%S)

Dacă baza de date este mare, folosește o metodă de backup mai serioasă decât cp -a. Principiul rămâne însă același: întâi backup, apoi cleanup, apoi upgrade.

Faza 2: oprește tot ce mai poate deține datadir-ul

Ai nevoie de o oprire cu adevărat curată. Asta înseamnă numele de servicii din pachete, numele helper-elor vechi și orice procese rămase în viață.

systemctl stop mysqld 2>/dev/null || true
systemctl stop mysql 2>/dev/null || true
systemctl stop mariadb 2>/dev/null || true

service mysqld stop 2>/dev/null || true
service mysql stop 2>/dev/null || true
service mariadb stop 2>/dev/null || true

pkill -TERM mysqld 2>/dev/null || true
pkill -TERM mariadbd 2>/dev/null || true
sleep 3

pkill -KILL mysqld 2>/dev/null || true
pkill -KILL mariadbd 2>/dev/null || true
sleep 2

ps -ef | egrep 'mariadbd|mysqld' | grep -v grep

Dacă ultima comandă afișează ceva, nu ești pregătit să continui. Oprește-te acolo și rezolvă procesul rămas. Nu face upgrade la un datadir care încă este atins de ceva ce nu ai vrut să lași activ.

Faza 3: elimină unitățile systemd vechi și shadowing-ul din PATH

Aceasta este una dintre cele mai urâte părți ale stack-urilor de baze de date DirectAdmin vechi. Un /etc/systemd/system/mysqld.service rămas din trecut sau un wrapper vechi în /usr/local/bin poate continua să indice către un tree mort de MySQL sau MariaDB, chiar și după ce ai instalat corect MariaDB 11.4 din pachete.

MariaDB în sine nu este problema aici. Problema este că host-ul mai conține încă mecanisme vechi de service control care nu mai au ce căuta în stack-ul activ.

Arhivează mai întâi fișierele custom de serviciu:

mkdir -p /root/old-systemd-units
mv /etc/systemd/system/mysqld.service /root/old-systemd-units/mysqld.service.$(date +%F-%H%M%S) 2>/dev/null || true
mv /etc/systemd/system/mysql.service  /root/old-systemd-units/mysql.service.$(date +%F-%H%M%S) 2>/dev/null || true

Apoi arhivează wrapper-ele sau binarele care fac shadowing în /usr/local/bin:

mkdir -p /root/old-mysql-bin
mv /usr/local/bin/mariadb-upgrade /root/old-mysql-bin/ 2>/dev/null || true
mv /usr/local/bin/mariadb         /root/old-mysql-bin/ 2>/dev/null || true
mv /usr/local/bin/mysql           /root/old-mysql-bin/ 2>/dev/null || true
mv /usr/local/bin/mysql_upgrade   /root/old-mysql-bin/ 2>/dev/null || true
hash -r

Acum verifică ce va folosi cu adevărat shell-ul:

type -a mariadb mariadb-upgrade mysql mysql_upgrade
/usr/bin/mariadb --version
/usr/bin/mariadb-upgrade --version

După acest pas, uneltele active de client trebuie să vină din /usr/bin, nu din reziduuri rămase sub /usr/local/bin.

Faza 4: adaugă repository-ul MariaDB 11.4 și instalează 11.4 curat

Fluxul documentat de MariaDB pentru upgrade pe Linux este clar și coerent. Cea mai curată abordare aici este să urmezi direct modelul bazat pe pachete și să păstrezi setul de versiuni perfect aliniat.

Șterge mai întâi fișierele de repository aflate în conflict, apoi configurează repository-ul oficial MariaDB 11.4.

rm -f /etc/apt/sources.list.d/*mariadb*.list /etc/apt/sources.list.d/*mariadb*.sources 2>/dev/null || true

curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | bash -s -- \
  --mariadb-server-version="mariadb-11.4"

apt update
apt-cache policy mariadb-server

Dacă versiunea candidat nu este 11.4, oprește-te și repară repository-ul înainte să instalezi ceva.

Apoi instalează un set de pachete 11.4 perfect aliniat:

ver="$(apt-cache madison mariadb-server | awk '/11\.4/{print $3; exit}')"
echo "$ver"

apt install -y \
  mariadb-server="$ver" \
  mariadb-client="$ver" \
  mariadb-server-core="$ver" \
  mariadb-client-core="$ver" \
  mariadb-common="$ver" \
  libmariadb3="$ver" \
  mariadb-backup="$ver" \
  galera-4

Fixarea explicită a versiunii nu este un moft. Reduce riscul de package skew și face instalarea mai ușor de înțeles ulterior, dacă ceva tot pare nelalocul lui.

Faza 5: pornește serverul real MariaDB 11.4 și rulează utilitarul real de upgrade

După ce serverul din pachete este instalat, pornește serviciul Debian-managed real.

systemctl daemon-reload
systemctl enable mariadb
systemctl start mariadb
systemctl status mariadb --no-pager -l

Dacă mariadb.service nu pornește curat aici, oprește-te și repară asta mai întâi. Nu rula utilitarul de upgrade pe un serviciu stricat sau pornit pe jumătate.

Apoi rulează utilitarul de upgrade explicit din /usr/bin, nu din ce găsește shell-ul primul în PATH.

Dacă root local folosește autentificare pe socket, ceea ce este normal pe instalările MariaDB din familia Debian, folosește:

/usr/bin/mariadb-upgrade \
  --no-defaults \
  --protocol=socket \
  --socket=/run/mysqld/mysqld.sock \
  --user=root \
  --force

Dacă root local încă folosește parolă, adaugă -p:

/usr/bin/mariadb-upgrade \
  --no-defaults \
  --protocol=socket \
  --socket=/run/mysqld/mysqld.sock \
  --user=root \
  -p \
  --force

Calea explicită și socket-ul explicit contează, pentru că exact setările implicite vechi, wrapper-ele vechi și presupunerile expirate despre socket sunt cele care creează confuzie în mediile legacy. Partea MariaDB este, în general, mai previzibilă decât reziduurile din jurul ei.

Faza 6: refă compatibilitatea numelor de servicii fără să readuci la viață serviciul greșit

Pe o instalare Debian curată, serviciul real este mariadb.service. Unelte mai vechi pot cere încă mysqld sau mysql. Soluția sigură nu este să reînvii o unitate veche. Soluția sigură este să faci alias vechilor nume către serviciul real.

ln -s /lib/systemd/system/mariadb.service /etc/systemd/system/mysqld.service
ln -s /lib/systemd/system/mariadb.service /etc/systemd/system/mysql.service

systemctl daemon-reload
systemctl reset-failed mariadb mysqld mysql 2>/dev/null || true

Ținta este simplă: un singur serviciu real, numele vechi rezolvându-se curat către el, fără nicio unitate custom rămasă care să indice către binare depășite.

Faza 7: repară compatibilitatea la nivel de socket

Versiunile noi DirectAdmin au mutat socket-ul preferat către /run/mysql/mysql.sock, în timp ce clienți și scripturi mai vechi încă se așteaptă la /var/lib/mysql/mysql.sock sau la tradiționalul /run/mysqld/mysqld.sock. Răspunsul practic pe un deployment manual Debian-based nu este să muți socket-ul real. Răspunsul este să oferi căi de compatibilitate pentru apelanții mai vechi.

mkdir -p /run/mysql
ln -sfn /run/mysqld/mysqld.sock /run/mysql/mysql.sock
ln -sfn /run/mysqld/mysqld.sock /var/lib/mysql/mysql.sock

Asta păstrează compatibilitatea atât pentru așteptările mai noi din DirectAdmin, cât și pentru clienți locali sau scripturi care încă trăiesc în trecut.

Faza 8: păstrează DirectAdmin pe da_admin, nu pe root MariaDB

Aici integrarea devine din nou curată. DirectAdmin trebuie să folosească da_admin prin /usr/local/directadmin/conf/mysql.conf. Nu trebuie să depindă de root MariaDB pentru operațiunile normale ale panoului.

Verifică fișierul:

cat /usr/local/directadmin/conf/mysql.conf

Ar trebui să arate, în esență, astfel:

user=da_admin
passwd=YOUR_DA_DB_PASSWORD

Dacă trebuie să resetezi contul în MariaDB:

/usr/bin/mariadb --protocol=socket --socket=/run/mysqld/mysqld.sock

ALTER USER 'da_admin'@'localhost' IDENTIFIED BY 'daadminpass';
GRANT ALL PRIVILEGES ON *.* TO da_admin@localhost WITH GRANT OPTION;
FLUSH PRIVILEGES;

Apoi actualizezi /usr/local/directadmin/conf/mysql.conf ca să corespundă și testezi direct contul:

/usr/bin/mariadb \
  --protocol=socket \
  --socket=/run/mysqld/mysqld.sock \
  -uda_admin -p \
  -e "SHOW DATABASES;"

Dacă asta funcționează, conectivitatea bazei de date dinspre DirectAdmin este în regulă.

Dacă DirectAdmin încă se comportă ciudat, verifică și existența unor configurări locale conflictuale, de tipul /root/.my.cnf. Override-urile ascunse la nivel de client sunt o cauză clasică pentru erori de autentificare aparent misterioase.

Faza 9: înțelege root, debian-start și unix_socket înainte să le „repari”

Nu șterge /etc/mysql/debian-start. Nu șterge scripturi helper doar pentru că produc un warning care nu îți place. Instalările MariaDB din familia Debian folosesc frecvent autentificare unix_socket pentru root@localhost, ceea ce înseamnă că root local se autentifică prin identitatea de utilizator Unix, nu printr-o parolă de bază de date.

Asta nu strică DirectAdmin, pentru că DirectAdmin ar trebui să folosească în continuare da_admin. Sunt două lucruri separate:

• root Linux local poate păstra acces root local în MariaDB prin autentificare pe socket
• DirectAdmin continuă să folosească da_admin din mysql.conf
• nu există niciun motiv să le amesteci

Dacă autentificarea locală pe socket pentru root funcționează, testeaz-o direct:

/usr/bin/mariadb --protocol=socket --socket=/run/mysqld/mysqld.sock -e "SELECT VERSION();"

Dacă root local merge și da_admin merge, lasă lucrurile așa. Nu inventa complexitate suplimentară în jurul root-ului bazei de date dacă mediul tău nu o cere explicit.

Faza 10: reactivează monitorizarea DirectAdmin

Reactivează monitorizarea doar după ce toate condițiile de mai jos sunt adevărate:

• mariadb.service este sănătos
• numele compatibile de servicii se rezolvă curat
• linkurile de compatibilitate pentru socket există
• da_admin se poate conecta cu succes

sed -i -e 's/mysqld=OFF/mysqld=ON/g' /usr/local/directadmin/data/admin/services.status
systemctl restart directadmin

Checklist-ul final de verificare

Acum rulează un checklist scurt și plictisitor. Exact asta vrei aici.

systemctl status mariadb --no-pager -l
systemctl is-active mariadb mysqld mysql
ps -ef | egrep 'mariadbd|mysqld' | grep -v grep
ss -xl | grep mysql

type -a mariadb mariadb-upgrade mysql mysql_upgrade

/usr/bin/mariadb --protocol=socket --socket=/run/mysqld/mysqld.sock -e "SELECT VERSION();"
/usr/bin/mariadb --protocol=socket --socket=/run/mysqld/mysqld.sock -uda_admin -p -e "SHOW DATABASES;"

Dacă rezultatele arată toate lucrurile de mai jos, migrarea este terminată:

• mariadb.service este activ
• mysqld și mysql se rezolvă curat ca nume de compatibilitate
• există exact un singur proces live mariadbd
• versiunea serverului este 11.4.x
• da_admin se poate conecta și lista bazele de date

Ce să nu faci

• Nu amesteca unelte vechi MySQL/MariaDB din epoca DirectAdmin, aflate în /usr/local/bin, cu uneltele MariaDB 11.4 instalate din pachete în /usr/bin.
• Nu păstra un /etc/systemd/system/mysqld.service custom și vechi după ce pachetul real MariaDB este instalat.
• Nu edita /usr/local/directadmin/conf/my.cnf și nu te aștepta să rămână așa.
• Nu șterge scripturi helper Debian doar ca să ascunzi warning-uri pe care nu le înțelegi.
• Nu presupune că rollback-ul după un upgrade major ratat este simplu fără un backup real făcut înainte.

Tema este mereu aceeași: ambiguitatea este ceea ce strică aceste servere. Elimină ambiguitatea, iar MariaDB 11.4 se comportă mult mai mult ca serverul curat, packaged și predictibil care ar trebui să fie.

Concluzie

Traseul de sysadmin aici nu este elegant, dar este fiabil: îngheți monitorizarea DirectAdmin, faci backup la datadir, oprești orice proces care încă poate atinge fișierele bazei de date, elimini unitățile de serviciu și wrapper-ele rămase din trecut, instalezi un set aliniat de pachete MariaDB 11.4, pornești serviciul real gestionat de Debian, rulezi utilitarul real /usr/bin/mariadb-upgrade, refaci compatibilitatea pentru nume de servicii și socket-uri, păstrezi DirectAdmin pe da_admin și abia apoi dai din nou controlul panoului.

Asta îți oferă MariaDB 11.4 într-un mediu DirectAdmin legacy fără să aștepți ca CustomBuild să salveze un server care nu mai corespunde căii curate. Și îi oferă MarieiDB exact contextul în care tinde să funcționeze cel mai bine: deployment curat prin pachete, model de serviciu previzibil și cât mai puține surprize legacy în jur.

Dacă preferi să nu faci asta manual pe un host de producție, folosește Management DirectAdmin sau Administrare Linux și păstrează serverul plictisitor din motivele corecte.