Categoria: Bases de dades
MongoDB gestionat al vostre compte: replica sets, còpies i actualitzacions
El vostre MongoDB en un replica set que aguanta la caiguda d'un node, amb còpies que es restauren i actualitzacions d'una versió a la següent, sense ensurts.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
En resum
MongoDB és una base de dades de documents, molt utilitzada en aplicacions web i mòbils. Administrar-la és fer-se responsable que estiga disponible, siga ràpida i es puga recuperar. Muntem replica sets de tres nodes, còpies amb recuperació a un moment concret que restaurem en proves, índexs, mètriques, seguretat i actualitzacions versió a versió, sempre al vostre compte i per al vostre propi ús.
Què ens encarreguem de mantindre?
MongoDB és fàcil d’arrancar i per això moltes instal·lacions continuen com el primer dia: un sol node, sense autenticació, amb còpies fetes a mà i una versió que ja no rep pegats. Ens encarreguem de portar-la a un estat que aguante una caiguda i un esborrat per error.
Replica set
Tres nodes, un primari elegit per votació i dos secundaris al dia.
Còpies i oplog
Còpies coherents i oplog guardat per a tornar a un moment concret.
Índexs
Consultes lentes, plans d’execució i índexs que de veritat es fan servir.
Mètriques
mongodb_exporter en Prometheus: retard, finestra d’oplog, memòria cau i connexions.
Actualitzacions
D’una versió major a la següent, assajades abans.
Seguretat
Autenticació, rols per aplicació, TLS i xarxa privada.
Per què tres nodes?
En un replica set, el primari s’elegeix per majoria de vots. Amb tres nodes, si en cau un, els altres dos continuen sent majoria, elegeixen un primari nou en segons i els drivers de l’aplicació es reconnecten sols. Amb dos nodes, la caiguda d’un deixa l’altre sense majoria i sense escriptures. Un àrbitre estalvia un servidor, però no guarda dades i complica les escriptures amb majoria, així que preferim tres nodes amb dades. Revisem també el writeConcern de l’aplicació: amb majoria, una escriptura confirmada sobreviu a la caiguda del primari.
| Situació | El que muntem | Per què |
|---|---|---|
| Desenvolupament o dades que es poden regenerar | Un node amb còpies fora | Sense complexitat, però sense commutació |
| Producció normal | Replica set de tres nodes en màquines o zones diferents | Aguanta la caiguda d’un node sense intervenció |
| Dades o escriptures que no caben en un servidor | Clúster amb sharding | Reparteix la càrrega, a canvi de bastants més peces |
| Ja sou a AWS, Google Cloud o Azure | MongoDB Atlas | Menys operació; nosaltres revisem índexs, alertes i restauracions |
Quins problemes trobem més sovint?
- Sense autenticació i obert a internet: la manera més habitual de perdre una base MongoDB sencera.
- Un sol node en producció: qualsevol reinici del servidor és una caiguda de l’aplicació.
- Finestra d’oplog curta: un secundari que es queda arrere unes hores ja no pot posar-se al dia i cal resincronitzar-lo sencer.
- Consultes sense índex: recorreguts complets de la col·lecció que disparen la CPU i buiden la memòria cau.
- Documents que creixen sense límit: arrays que acumulen elements fins a acostar-se al màxim de 16 MB per document.
- Versió sense suport: diverses versions majors per darrere, amb un salt pendent que fa por.
Com fem i provem les còpies?
Hi ha tres maneres i no valen igual. mongodump serveix per a bases xicotetes o per a exportar una col·lecció, però és lent i restaurar una base gran pot portar hores. Les instantànies del disc són ràpides si es prenen de manera coherent, amb el journal al mateix volum. Per a producció fem servir Percona Backup for MongoDB, que fa còpies físiques o lògiques del replica set i guarda l’oplog de manera contínua, cosa que permet recuperar al minut anterior a un esborrat. Les còpies van xifrades a un emmagatzematge d’objectes en un altre compte o en un altre proveïdor. Almenys una vegada al mes restaurem en un entorn a part, comprovem els recomptes de documents i els índexs, i anotem a l’informe quant ha tardat.
Com actualitzem de versió?
MongoDB només s’actualitza d’una versió major a la següent: de 6.0 a 7.0 i de 7.0 a 8.0, sense salts. A cada pas actualitzem primer els secundaris, un a un, després canviem el primari i l’actualitzem. L’aplicació continua funcionant durant el procés. Després deixem uns dies el featureCompatibilityVersion en la versió anterior, per si cal tornar arrere, i només el pugem quan tot va bé; sense aquest pas no es pot passar a la versió següent. Abans revisem que els drivers de les vostres aplicacions admeten la versió de destinació.
Què passa amb la llicència?
MongoDB Community es publica amb la llicència SSPL, que imposa condicions a qui ofereix MongoDB com a servei a tercers. Per això treballem sempre igual: la base de dades s’instal·la al vostre compte o en els vostres servidors, per a les vostres aplicacions, i nosaltres només l’administrem. No oferim MongoDB com a servei compartit entre clients. Si la llicència no us encaixa, parlem d’Atlas o de passar a una altra base de dades, com PostgreSQL.
Com vigilem que tot va bé?
Les alertes cobreixen nodes caiguts, retard de rèplica i disc, 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 | Replica set en tres servidors cloud o dedicats, en xarxa privada, amb còpies en Object Storage de Hetzner. | Sense MongoDB gestionat a Hetzner: el replica set, les còpies i les actualitzacions les portem nosaltres. |
| AWS | MongoDB Atlas sobre AWS, o EC2 amb un replica set repartit en tres zones i còpies a S3. | Amazon DocumentDB és compatible amb part de l'API, però no és MongoDB: comprovem abans que la vostra aplicació no faça servir el que li falta. |
| Google Cloud | MongoDB Atlas sobre Google Cloud, o Compute Engine amb replica set i còpies a Cloud Storage. | Google Cloud no té un MongoDB gestionat propi; l'opció gestionada és Atlas. |
| Azure | MongoDB Atlas sobre Azure, o màquines virtuals amb replica set en zones diferents. | Azure Cosmos DB for MongoDB imita l'API amb un altre motor: serveix en alguns casos i convé provar-lo amb les vostres consultes. |
| DigitalOcean | MongoDB gestionat de DigitalOcean amb nodes en espera, o Droplets amb replica set. | Còmode per a càrregues xicotetes i mitjanes; revisem versió, mida i retenció de còpies del pla. |
| OVH | Base de dades gestionada d'OVHcloud per a MongoDB quan està disponible a la vostra regió, o instàncies de Public Cloud amb replica set. | Comprovem abans la versió de MongoDB que ofereix. |
| Servidor propi | Replica set en tres servidors o màquines virtuals vostres, amb les còpies en un emmagatzematge S3 extern. | Els tres nodes en el mateix amfitrió físic no són alta disponibilitat: si cau aquest amfitrió, cau tot. |
Què inclou
- Replica set de tres nodes en màquines o zones diferents, amb prioritats i eleccions revisades.
- Còpies amb Percona Backup for MongoDB o instantànies de disc coherents, i oplog arxivat per a recuperar a un moment concret.
- Restauració de prova periòdica en un entorn a part, amb el temps mesurat a l'informe.
- Revisió de consultes lentes amb el profiler i explain, i índexs que les cobreixen.
- Mètriques amb mongodb_exporter i alertes de retard de rèplica, finestra d'oplog, disc i connexions.
- Actualitzacions d'una versió major a la següent, amb featureCompatibilityVersion controlat.
- Autenticació activada, un usuari per aplicació amb rols mínims, TLS i accés només des de la xarxa privada.
- Pla de migració des de MongoDB Atlas, o cap a Atlas, si és el que us convé.
Preguntes freqüents
Quina llicència té MongoDB i ens afecta?
MongoDB Community es publica amb la llicència SSPL. Per a fer-la servir a la vostra pròpia empresa, com a base de dades de les vostres aplicacions, no suposa cap problema. Per això la instal·lem i la gestionem sempre dins del vostre compte i per al vostre ús; mai no l'oferim com a servei compartit entre clients.
Atlas o MongoDB en els nostres propis servidors?
Atlas us estalvia pegats, còpies i commutació, i sol ser el més assenyat si ja sou a AWS, Google Cloud o Azure i la base de dades és mitjana. Muntar-lo pel vostre compte compensa quan Atlas s'encareix amb el volum, quan el vostre proveïdor no l'ofereix, com Hetzner, o quan voleu les dades en servidors que controleu.
Es pot migrar d'Atlas sense parar l'aplicació?
Quasi. Es prepara el replica set nou amb la mateixa versió, es copien les dades i es manté sincronitzat amb una eina de sincronització contínua mentre proveu. El tall es redueix a canviar la cadena de connexió. Abans revisem que no feu servir funcions exclusives d'Atlas, com la seua cerca integrada.
Necessitem sharding?
Quasi mai al principi. Un replica set ben dimensionat i amb bons índexs aguanta molt més del que se sol pensar. El sharding afegeix servidors de configuració, encaminadors i una clau de repartiment que és difícil de canviar; el proposem només quan les dades o les escriptures ja no caben en un servidor.
I Percona Server for MongoDB?
És una distribució compatible amb MongoDB Community que afegeix de sèrie còpies en calent, auditoria i autenticació amb LDAP. Té la mateixa llicència SSPL, així que no canvia res en aquest aspecte; la proposem quan necessiteu aquestes funcions sense passar a l'edició de pagament.
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:
Revisat el