Categoria: Bases de dades
MySQL i MariaDB gestionats al vostre compte: rèpliques, còpies i actualitzacions provades
La base de dades de la vostra botiga, el vostre ERP o la vostra aplicació amb rèplica, còpies que sabem restaurar i un camí clar per a eixir de versions sense suport.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
En resum
MySQL i MariaDB són bases de dades relacionals de codi obert molt esteses en webs, botigues i aplicacions de gestió. Administrar-les és fer-se responsable que estiguen disponibles, siguen ràpides i es puguen recuperar. Muntem rèpliques amb GTID o clústers Galera quan encaixen, còpies físiques amb recuperació a un moment concret que restaurem en proves, mètriques, revisió de consultes lentes i actualitzacions assajades.
Què ens encarreguem de mantindre?
MySQL i MariaDB solen estar davall d’alguna cosa que factura: una botiga en línia, un ERP, un CRM o l’aplicació de l’empresa. Moltes porten anys al mateix servidor, amb la configuració per defecte i una còpia nocturna que ningú no ha restaurat mai. Ens encarreguem que això canvie sense parar el vostre negoci.
InnoDB i configuració
Memòria del buffer pool, registre de transaccions, connexions i mode SQL.
Rèpliques
Rèplica amb GTID, asíncrona o semisíncrona, o Galera en MariaDB.
Proxy
ProxySQL o MaxScale per a repartir lectures i commutar de principal.
Còpies i binlogs
Còpies físiques i binlogs arxivats per a recuperar a un moment concret.
Mètriques
mysqld_exporter en Prometheus: retard de rèplica, consultes, bloquejos i disc.
Accessos
Usuaris per aplicació, contrasenyes fora del codi i TLS.
Quin tipus de rèplica muntem?
Sempre amb GTID, que identifica cada transacció i permet apuntar una rèplica a un altre principal sense buscar posicions de binlog a mà. L’elecció important és quant podeu perdre si el principal cau.
| Situació | El que muntem | Què implica |
|---|---|---|
| Es tolera perdre uns segons i una estona de tall | Rèplica asíncrona amb GTID | Senzilla i sense cost en escriptura; la commutació la decidim nosaltres o un orquestrador |
| No es pot perdre una transacció confirmada | Rèplica semisíncrona | El principal espera que una rèplica reba cada transacció; afig una mica de latència |
| Diversos nodes que escriuen i commutació immediata (MariaDB) | Galera Cluster amb tres nodes | Sense pèrdua de dades, però sensible a la xarxa i a les transaccions grans |
| Proveïdor amb base de dades gestionada | RDS, Cloud SQL, Azure Database o una altra | El proveïdor commuta; nosaltres ajustem, vigilem i provem restauracions |
Davant posem ProxySQL amb MySQL o MaxScale amb MariaDB: les aplicacions es connecten sempre al mateix lloc, les lectures pesades poden anar a la rèplica i un canvi de principal no obliga a editar la configuració de ningú. I una rèplica no substitueix la còpia: un DROP TABLE arriba a tots els nodes quasi alhora.
Quins problemes trobem més sovint?
- Versió sense suport: MySQL 5.7 o 8.0, o una MariaDB fora del seu cicle LTS, sense pegats de seguretat.
- Rèplica trencada sense avís: es va parar per un error de duplicat fa setmanes i ningú no ho va veure.
- Binlogs omplint el disc: sense caducitat configurada, o retinguts per una rèplica abandonada.
- Taules sense clau primària: alenteixen la rèplica basada en files i donen problemes en Galera.
- Consultes sense índex: un llistat que va bé amb mil files i tomba el servidor amb un milió.
- Tot amb root: l’aplicació, les còpies i les persones entren amb el mateix usuari, de vegades des d’internet.
Com fem i provem les còpies?
Amb Percona XtraBackup en MySQL o mariabackup en MariaDB fem còpies físiques en calent, sense bloquejar la base de dades, i copiem els binlogs de manera contínua a un emmagatzematge d’objectes en un altre compte o en un altre proveïdor, xifrats. Restaurar és aplicar la còpia i reproduir els binlogs fins al minut que trieu. Almenys una vegada al mes ho fem de veritat en un servidor de prova, comprovem que arranca, que la rèplica es pot reconstruir des d’allí i llancem consultes de control. El temps que tarda és el vostre temps real de recuperació, i queda escrit a l’informe.
Com actualitzem de versió?
En MySQL només s’avança d’una sèrie a la següent: de 5.7 a 8.0 i de 8.0 a 8.4 LTS. Abans revisem paraules reservades noves, canvis en el mode SQL, el joc de caràcters i l’autenticació, perquè 8.4 deixa desactivat per defecte l’antic mysql_native_password i algunes aplicacions velles deixen de connectar. En MariaDB passem d’una LTS a la següent, per exemple de 10.6 a 10.11 i després a 11.4. El mètode més segur és alçar una rèplica amb la versió nova, deixar que se sincronitze, provar les aplicacions contra ella i canviar el principal en un tall curt. Si ix malament, la versió anterior continua allí.
Com trobem les consultes lentes?
Activem el registre de consultes lentes amb un llindar raonable, l’agreguem amb pt-query-digest o amb Performance Schema i us passem les poques consultes que s’enduen la major part del temps, amb l’índex o el canvi que proposem per a cadascuna. Quasi sempre s’hi guanya més que ampliant el servidor.
Quan us recomanem la base de dades del vostre proveïdor?
Quan existeix per al vostre motor, la càrrega és normal i no necessiteu connectors ni paràmetres que el servei no permet. RDS, Cloud SQL, Azure Database for MySQL o les bases de dades gestionades de DigitalOcean i OVHcloud resolen bé els pegats i la commutació. Muntem i operem MySQL o MariaDB nosaltres mateixos quan el proveïdor no l’ofereix, com Hetzner, quan necessiteu Galera o funcions pròpies de MariaDB, o quan el cost del gestionat creix més que la base de dades. En els dos casos la vigilància automàtica és contínua; la resposta humana és en horari laboral, com en el SRE com a servei. Les mètriques acaben al monitoratge amb Grafana i Prometheus.
On ho muntem?
Al vostre compte, al proveïdor que ja feu servir o al que encaixe millor. Si les dades s'han de quedar a la UE, Hetzner i OVHcloud són les opcions europees.
Proveïdors on ho muntem
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propi
| Proveïdor | Com ho muntem | A tindre en compte |
|---|---|---|
| Hetzner | Servidors cloud o dedicats amb MySQL o MariaDB, rèplica o Galera en xarxa privada i binlogs arxivats en Object Storage de Hetzner. | Hetzner no ofereix base de dades gestionada: la rèplica, el balanceig i les còpies les muntem nosaltres. |
| AWS | RDS for MySQL, RDS for MariaDB o Aurora MySQL quan encaixen; si no, EC2 amb rèplica GTID i còpies a S3. | Revisem grups de paràmetres, rèpliques de lectura, la retenció de còpies i que la restauració funcione. |
| Google Cloud | Cloud SQL per a MySQL amb alta disponibilitat regional, o Compute Engine amb rèplica i còpies a Cloud Storage. | Cloud SQL no ofereix MariaDB: si depeneu de funcions pròpies de MariaDB, va en màquines virtuals. |
| Azure | Azure Database for MySQL (servidor flexible), o màquines virtuals amb MySQL o MariaDB. | Azure va retirar el seu servei gestionat de MariaDB; qui el feia servir ha de passar a MySQL flexible o a màquines pròpies. |
| DigitalOcean | MySQL gestionat de DigitalOcean amb nodes en espera, o Droplets amb MySQL o MariaDB. | Senzill per a càrregues xicotetes i mitjanes; revisem els límits de connexions del pla. |
| OVH | Base de dades gestionada d'OVHcloud per a MySQL, o instàncies de Public Cloud amb rèplica o Galera. | |
| Servidor propi | MySQL o MariaDB en els vostres servidors o màquines virtuals, amb la rèplica en una altra màquina física i còpies a un emmagatzematge S3 extern. | Galera necessita tres nodes i una xarxa estable entre ells; amb dos, una caiguda deixa el clúster sense quòrum. |
Què inclou
- Rèplica asíncrona o semisíncrona amb GTID, o un clúster Galera en MariaDB quan la càrrega ho demana.
- ProxySQL o MaxScale davant, per a repartir lectures i canviar de principal sense tocar les aplicacions.
- Còpies físiques amb Percona XtraBackup o mariabackup i arxivat de binlogs fora del servidor, xifrats.
- Restauració de prova periòdica a un moment concret, amb el temps mesurat a l'informe.
- Mètriques amb mysqld_exporter i alertes de retard de rèplica, disc, connexions i bloquejos.
- Revisió del registre de consultes lentes, índexs i memòria d'InnoDB.
- Actualitzacions de 5.7 a 8.0 i 8.4 LTS, o entre versions LTS de MariaDB, assajades abans en una còpia.
- Un usuari per aplicació amb permisos mínims, TLS i accés només des de la xarxa privada.
Preguntes freqüents
Continuem en MySQL 5.7 o 8.0, és urgent actualitzar?
Sí. MySQL 5.7 va deixar de rebre pegats el 2023 i la sèrie 8.0 va arribar a la fi de vida l'abril de 2026. La destinació raonable és 8.4 LTS, passant per 8.0 si veniu de 5.7, perquè no es pot saltar directament. L'assagem abans amb una còpia de les vostres dades i les vostres aplicacions.
MySQL o MariaDB?
Si ja en teniu una funcionant, quasi mai no compensa canviar. Avui són productes diferents: la replicació, el format de GTID i algunes funcions no coincideixen, així que una migració entre ells es tracta com un projecte, no com una actualització. Per a una cosa nova, ho decidim segons el que admeten la vostra aplicació i el vostre proveïdor.
Necessitem un clúster Galera?
Poques vegades. Galera dona escriptura en diversos nodes i commutació sense pèrdua de dades, però exigeix tres nodes, xarxa de baixa latència i taules amb clau primària, i les transaccions grans l'alenteixen. Per a la majoria de càrregues n'hi ha prou amb un principal amb rèplica i ProxySQL o MaxScale davant.
Ens val amb mysqldump?
Per a bases de dades xicotetes, com a complement. Una còpia lògica tarda molt a restaurar quan la base creix i només recupera al moment en què es va fer. Amb una còpia física i els binlogs arxivats es recupera al minut anterior a un esborrat per error, en molt menys temps.
Gestioneu també PostgreSQL o MongoDB?
Sí, amb el mateix enfocament de rèplica, còpies provades i actualitzacions planificades. Teniu els detalls a les pàgines de PostgreSQL i MongoDB.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Documentació oficial consultada
Les dades tècniques d'aquesta pàgina es basen en:
- MySQL 8.4 Reference Manual: Replication
- MySQL 8.4 Reference Manual: Point-in-Time (Incremental) Recovery
- MariaDB Documentation: mariadb-backup Overview
Revisat el