Cum instalezi MySQL pe un VPS: utilizatori, acces de la distanță sigur, mai puțin RAM și backupuri

Instalarea MySQL e o singură comandă. Cea mai mare parte a muncii vine după: un utilizator pentru aplicație, o cale de a ajunge la bază de pe calculatorul tău fără să pui portul 3306 pe internet, setări de memorie pentru un server mic și backupuri care rulează fără tine. Acest ghid le acoperă pe toate patru pe Ubuntu 24.04. Fiecare pas a fost rulat pe imaginea noastră Ubuntu 24.04, iar cifrele de mai jos vin de pe acel server.

Rulează comenzile cu un utilizator care are sudo. Ghidul de configurare Ubuntu creează unul.

1. Instalează

sudo apt update
sudo apt install -y mysql-server
mysql --version

Pe serverul nostru instalarea a durat 51 de secunde și ne-a dat MySQL 8.0.46. Pornește imediat, pornește din nou la fiecare boot și ascultă doar pe serverul însuși: 127.0.0.1:3306 pentru conexiunile obișnuite și 127.0.0.1:33060 pentru protocolul X, mai nou. Din exterior nu se poate ajunge încă la nimic.

2. Creează o bază de date și un utilizator

Contul root din MySQL folosește pe Ubuntu autentificare prin socket, deci sudo mysql te conectează fără parolă. Creează o bază de date și un utilizator pentru aplicație:

sudo mysql

CREATE DATABASE app CHARACTER SET utf8mb4;
CREATE USER 'app'@'localhost' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON app.* TO 'app'@'localhost';
EXIT;

Testează așa cum se va conecta aplicația:

mysql -u app -p app -e "SELECT CURRENT_USER();"

Ar trebui să afișeze app@localhost. O parolă greșită primește ERROR 1045 (28000): Access denied for user 'app'@'localhost'. Utilizatorul poate face orice în app și nimic în afara ei.

3. Conectarea de pe calculatorul tău: tunel SSH

Ca să folosești un client desktop precum DBeaver, MySQL Workbench sau linia de comandă mysql pe propria mașină, nu deschide niciun port. Redirecționează unul prin SSH:

ssh -L 3307:127.0.0.1:3306 deploy@YOUR.SERVER.IP

Pe un plan NAT adaugă -p și portul SSH personal din panou. Cât timp fereastra e deschisă, îndreaptă clientul spre gazda 127.0.0.1, portul 3307, utilizatorul app. Pe partea locală am folosit 3307 ca să nu intre în conflict cu un MySQL pe care l-ai putea rula pe calculator. În testul nostru serverul a răspuns imediat prin tunel, în timp ce o conexiune directă la adresa lui pe 3306 a fost refuzată.

4. Acces direct pentru un alt server

Uneori aplicația rulează pe un al doilea server și trebuie să se conecteze direct. Pentru asta baza are nevoie de un plan cu IPv4 propriu, pentru că un plan NAT redirecționează doar portul tău SSH. Trei schimbări, toate limitate la adresa serverului aplicației (aici 203.0.113.20):

sudo sed -i 's/^bind-address.*/bind-address = 0.0.0.0/' /etc/mysql/mysql.conf.d/mysqld.cnf
sudo systemctl restart mysql
sudo ufw allow from 203.0.113.20 to any port 3306 proto tcp

CREATE USER 'app'@'203.0.113.20' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON app.* TO 'app'@'203.0.113.20';

Dacă ufw nu e încă activat, permite mai întâi SSH (sudo ufw allow OpenSSH) și apoi rulează sudo ufw enable. Ghidul ufw are detaliile.

Am verificat ambele încuietori separat. Cu regula din firewall, dar fără un utilizator MySQL potrivit, serverul a refuzat cu error 1130: Host '…' is not allowed to connect to this MySQL server. Cu utilizatorul adăugat, conexiunea a trecut. Fără regula din firewall, conexiunea pur și simplu a expirat. Orice altă adresă de pe internet primește aceeași expirare.

5. Mai puțin RAM

În repaus, fără date proprii, MySQL 8.0 folosea 383 MB pe serverul nostru. Cea mai mare parte e Performance Schema, o funcție de diagnosticare care rezervă memorie din start. Pe un VPS mic, oprește-o și stabilește tu mărimea cache-ului principal:

sudo tee /etc/mysql/mysql.conf.d/zz-small-vps.cnf >/dev/null <<'EOF'
[mysqld]
performance_schema = OFF
innodb_buffer_pool_size = 256M
max_connections = 50
EOF
sudo systemctl restart mysql
ps -o rss= -C mysqld

După repornire folosea 165 MB. Buffer pool-ul ține în cache datele și indexurile, iar 256 MB se potrivesc unui server de 2 GB care rulează și aplicația. Mărește-l dacă baza e principalul lucru de pe server și a depășit mărimea cache-ului. max_connections = 50 e mai mult decât suficient pentru o aplicație cu pool de conexiuni. Pierzi statisticile din performance_schema. Repornește-l dacă vreodată trebuie să analizezi în detaliu interogări lente.

6. Backupuri nocturne

mysqldump --single-transaction face o copie consecventă a tabelelor InnoDB fără să blocheze aplicația. Pune-l într-un script mic:

sudo tee /usr/local/bin/mysql-backup >/dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
umask 077
mkdir -p /var/backups/mysql
mysqldump --single-transaction --routines --triggers app | gzip > /var/backups/mysql/app-$(date +%F).sql.gz
find /var/backups/mysql -name 'app-*.sql.gz' -mtime +14 -delete
EOF
sudo chmod 755 /usr/local/bin/mysql-backup
echo '0 3 * * * root /usr/local/bin/mysql-backup' | sudo tee /etc/cron.d/mysql-backup
sudo /usr/local/bin/mysql-backup && sudo ls -l /var/backups/mysql

Fiecare linie are motivul ei:

• umask 077 face ca dump-ul să poată fi citit doar de root (-rw-------), fiindcă conține toate datele tale.
• pipefail face ca întregul script să eșueze dacă eșuează mysqldump. Fără el, gzip ar scrie o arhivă minusculă și goală și ar raporta succes. Am stricat comanda intenționat, iar scriptul a ieșit cu codul 2, cum trebuie.
• find … -mtime +14 -delete păstrează copii pe două săptămâni.
• Scriptul rulează ca root, deci mysqldump se autentifică prin socket și nicio parolă nu stă într-un fișier.

Un backup pe care nu l-ai restaurat niciodată încă nu contează. Restaurează-l într-o bază temporară și uită-te la date:

sudo mysql -e "CREATE DATABASE app_restore"
gunzip -c /var/backups/mysql/app-2026-10-25.sql.gz | sudo mysql app_restore
sudo mysql -e "SHOW TABLES FROM app_restore"
sudo mysql -e "DROP DATABASE app_restore"

În testul nostru tabelul restaurat avea aceleași rânduri ca originalul. Copiile de pe același disc nu te protejează dacă pierzi serverul, așa că mută-le din când în când pe altă mașină cu scp sau restic. Managed Backups adaugă pe deasupra puncte zilnice de restaurare ale întregului server.

Ce plan

Micro (2 vCPU, 2 GB, 25 GB, $5/lună) duce MySQL reglat ca mai sus plus o aplicație web. Dacă baza în sine trece de câțiva gigaocteți, Small cu 4 GB și 35 GB pentru $8/lună îți permite să dai buffer pool-ului 1 GB sau mai mult. Ambele sunt planuri NAT, iar tunelul SSH de la pasul 3 merge pe ele. Pasul 4 cere IPv4 propriu: Micro-IP costă $10/lună.

Preferi PostgreSQL? Ghidul PostgreSQL urmează același plan. Toate planurile sunt în VPS, iar plata se face în USDT, USDC sau ETH pe Base, Ethereum sau Polygon.