Categoria: Bases de dades
PostgreSQL gestionat al vostre compte: rèpliques, còpies i PITR provats
La vostra base de dades amb rèplica, recuperació a un minut concret i actualitzacions majors planificades, en els vostres servidors o al costat del servei gestionat del vostre proveïdor.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
En resum
PostgreSQL és un sistema de base de dades relacional de codi obert. Gestionar-lo és fer-se responsable que estiga disponible, siga ràpid i es puga recuperar. Muntem rèpliques amb commutació automàtica, còpies amb recuperació a un moment concret (PITR) que restaurem en proves, agrupació de connexions, mètriques i actualitzacions majors. I us diem quan us ix més a compte la base de dades gestionada del vostre proveïdor.
Què ens encarreguem de mantindre?
Una base de dades pot funcionar anys sense que ningú la mire, fins al dia que el disc s’omple de WAL o la còpia nocturna resulta que és buida. La nostra feina és que aquest dia no arribe i, si arriba, que la recuperació siga un procediment ja assajat.
Servidor principal
Configuració de memòria, autovacuum, connexions i registre de consultes lentes.
Rèpliques
Streaming replication amb Patroni per a commutar només si el principal cau.
Còpies i WAL
Còpies base i arxivat continu per a recuperar a un moment concret.
PgBouncer
Agrupació de connexions entre les aplicacions i la base de dades.
Mètriques
postgres_exporter en Prometheus: retard de rèplica, bloquejos, mida i transaccions.
Accessos
Un usuari per aplicació, TLS i res exposat a internet.
Quina arquitectura recomanem?
Per a producció, un principal i almenys una rèplica en una altra màquina, amb Patroni decidint qui és el principal a partir d’un magatzem de consens com etcd. Les aplicacions es connecten a través de PgBouncer o d’una adreça que sempre apunta al principal, així que una commutació no obliga a tocar-ne la configuració.
| Situació | El que muntem | Per què |
|---|---|---|
| Base de dades xicoteta, es tolera una estona de tall | Un servidor i arxivat de WAL fora | Recuperació provada sense la complexitat d’un clúster |
| Producció que no pot parar | Patroni amb principal i rèplica, més arxivat de WAL | Commutació automàtica en segons |
| Proveïdor amb base de dades gestionada | RDS, Cloud SQL, Azure Database o una altra | Menys peces; nosaltres vigilem, ajustem i provem restauracions |
Una rèplica no és una còpia: si algú esborra una taula, l’esborrat arriba a la rèplica en mil·lisegons. Per això l’arxivat de WAL hi va sempre, hi haja rèplica o no.
Quins problemes trobem més sovint?
- Còpies amb pg_dump que ningú no restaura: tarden hores, només recuperen al moment de la còpia i de vegades fallen sense avisar.
- Disc ple de WAL: un arxivat trencat o una ranura de replicació abandonada reté WAL fins a omplir el disc.
- Connexions esgotades: cada procés de l’aplicació obri les seues i el servidor rebutja les noves en hora punta.
- Autovacuum desajustat: taules inflades, consultes cada vegada més lentes i risc d’esgotar els identificadors de transacció.
- Versió fora de suport: diverses versions majors per darrere, sense pegats de seguretat.
- Un sol compte per a tot: totes les aplicacions entren amb el superusuari.
Com provem que la còpia funciona?
Amb pgBackRest o WAL-G fem còpies base periòdiques i arxivem cada segment de WAL en un emmagatzematge d’objectes d’un altre compte o d’un altre proveïdor, xifrat. Una vegada al mes, com a mínim, restaurem en un servidor de prova a un moment concret, comprovem que la base de dades arranca i llancem unes consultes de control. El temps que tarda és el vostre temps real de recuperació, i l’anotem a l’informe perquè no siga una estimació.
Com fem una actualització major?
Hi ha dos camins. Amb pg_upgrade l’actualització es fa al mateix servidor i el tall és curt, sobretot amb enllaços d’arxius. Amb replicació lògica preparem un servidor nou amb la versió nova, el mantenim sincronitzat i canviem les aplicacions quan ja està provat; tarda més a preparar-se però el tall és mínim, i és el mateix mètode que fem servir per a migrar de RDS o de Cloud SQL a un altre lloc. En els dos casos assagem abans amb una còpia i revisem les extensions.
És millor RDS o Cloud SQL que un PostgreSQL propi?
| Aspecte | RDS, Cloud SQL o PostgreSQL gestionat d’OVHcloud | PostgreSQL propi administrat |
|---|---|---|
| Control i extensions | Només les extensions i els paràmetres que admet el proveïdor, sense superusuari real ni accés al sistema operatiu | Qualsevol extensió i paràmetre, amb accés complet al servidor |
| Versions i actualitzacions | Pegats menors en la finestra de manteniment; el proveïdor marca fins quan dona suport a cada versió major | Decidiu quan; l’actualització major la preparem i l’assagem amb pg_upgrade o replicació lògica |
| Còpies i recuperació a un moment concret | Còpies automàtiques i, segons el proveïdor, recuperació a un moment concret, amb una retenció màxima i dins del seu compte | pgBackRest o WAL-G, amb la retenció que pactem i les còpies en un altre compte o en un altre proveïdor |
| Cost | Més car que una màquina equivalent, i puja amb la mida, les rèpliques i l’alta disponibilitat | Menys cost d’infraestructura, però cal sumar les hores d’administració |
| Dependència del proveïdor | Major: eixir-ne exigeix una migració, per exemple amb replicació lògica | Menor: PostgreSQL estàndard, que es porta a un altre proveïdor amb les mateixes eines |
| Qui respon | El proveïdor, de la infraestructura del servei segons el seu acord de nivell de servei; la configuració, les dades i les consultes continuen sent vostres | Nosaltres, de l’operació, les còpies i la recuperació, segons el que hàgem pactat; el proveïdor, només de la màquina |
Moltes vegades sí: quan existeix, la càrrega és normal i no necessiteu res especial. RDS, Cloud SQL, Azure Database o les bases de dades gestionades de DigitalOcean i OVHcloud fan bé els pegats, les rèpliques i les còpies de baix nivell. Muntem un PostgreSQL propi quan el proveïdor no l’ofereix, com Hetzner, quan necessiteu extensions o paràmetres que el servei no permet, o quan el cost del gestionat es dispara amb la mida. Tot i això hi ha feina: paràmetres, índexs, consultes lentes, alertes i proves de restauració. Si voleu que aquesta vigilància siga contínua, encaixa en el SRE com a servei; i les mètriques acaben al monitoratge amb Grafana i Prometheus.
I TimescaleDB?
TimescaleDB no és una altra base de dades: és una extensió de PostgreSQL per a sèries temporals, com lectures de sensors, mètriques o preus. Converteix les taules grans en hipertaules partides per temps, comprimeix les dades antigues i esborra el que caduca amb polítiques de retenció. El que sabeu de PostgreSQL continua valent, i el gestionem igual: rèplica, còpies amb pgBackRest i restauració provada.
Hi ha dos detalls propis. La compressió, els agregats continus i les polítiques de retenció van amb la Timescale License, no amb Apache 2.0: podeu fer-les servir al vostre compte, però moltes bases de dades gestionades dels proveïdors no ofereixen l’extensió o només porten la part Apache, així que normalment la muntem en un PostgreSQL propi. I a cada actualització major comprovem abans que la versió de l’extensió és compatible amb la versió de PostgreSQL de destinació, i l’actualitzem primer.
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 PostgreSQL, Patroni i pgBackRest muntats per nosaltres, en xarxa privada. Arxivat de WAL en Object Storage de Hetzner, compatible amb S3. | Hetzner no ofereix base de dades gestionada: l'alta disponibilitat i les còpies les posem nosaltres. |
| AWS | RDS for PostgreSQL o Aurora quan encaixen; si no, EC2 amb Patroni i còpies a S3. | Amb RDS revisem paràmetres, rèpliques de lectura, finestres de manteniment i que la restauració funcione. |
| Google Cloud | Cloud SQL per a PostgreSQL, o Compute Engine amb Patroni i còpies a Cloud Storage. | Cloud SQL té recuperació a un moment concret; la provem igualment. |
| Azure | Azure Database for PostgreSQL (servidor flexible), o màquines virtuals amb Patroni. | Triem l'alta disponibilitat entre zones quan la càrrega ho justifica. |
| DigitalOcean | PostgreSQL gestionat de DigitalOcean amb nodes en espera, o Droplets amb Patroni. | |
| OVH | Base de dades gestionada d'OVHcloud per a PostgreSQL, o instàncies de Public Cloud amb Patroni. | |
| Servidor propi | PostgreSQL amb Patroni en els vostres servidors o màquines virtuals, i arxivat de WAL a un emmagatzematge S3 extern. | Convé que la rèplica estiga en una altra màquina física; si no, l'alta disponibilitat només és aparent. |
Què inclou
- PostgreSQL amb rèplica en streaming i commutació automàtica amb Patroni, o el servei gestionat del vostre proveïdor si encaixa millor.
- Còpies base i arxivat continu de WAL amb pgBackRest o WAL-G, fora del servidor i xifrades.
- Restauració de prova periòdica a un moment concret, amb el temps que tarda anotat a l'informe.
- PgBouncer perquè les aplicacions no esgoten les connexions.
- Mètriques amb postgres_exporter i alertes de rèplica endarrerida, disc, bloquejos i consultes lentes.
- Revisió de consultes lentes, índexs i configuració de memòria amb pg_stat_statements.
- Actualitzacions majors amb pg_upgrade o replicació lògica, assajades abans amb una còpia.
- Usuaris i permisos per aplicació, connexions xifrades i accés només des de la xarxa privada.
Preguntes freqüents
Podem migrar de RDS a un altre proveïdor sense parar l'aplicació?
Quasi sense parar. Amb replicació lògica des de RDS a la base de dades nova, les dades es mantenen sincronitzades mentre proveu; el tall es redueix al moment de canviar la cadena de connexió. Revisem abans les extensions i les seqüències, que no es repliquen soles.
A quin moment podem recuperar la base de dades?
Amb arxivat continu de WAL, a qualsevol moment dins del període de retenció que pactem, per exemple al minut anterior a un esborrat per error. El termini de retenció i el temps de restauració mesurat queden per escrit.
Gestioneu també MySQL o MariaDB?
Sí, amb el mateix enfocament de rèplica, còpies provades i actualitzacions planificades, encara que amb les seues pròpies eines.
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:
- PostgreSQL Documentation: Continuous Archiving and Point-in-Time Recovery (PITR)
- PostgreSQL Documentation: pg_upgrade
Revisat el