Les fotos de MercadoFresco ja són a S3, amb el seu cicle de vida i el seu versionatge. Però el cor del negoci continua al servidor de l'oficina: la base de dades de comandes. Allà hi ha els clients, els productes, les cistelles, les rutes de repartiment i la facturació. És la dada que no es pot perdre, la que no pot estar caiguda els divendres a les 19:00, i la que avui es desa amb un pg_dump a un disc extern que ningú no ha provat mai de restaurar.

Aquesta lliçó migra aquesta base de dades a Amazon RDS (Relational Database Service), el servei gestionat de bases de dades relacionals d'AWS. No és només «PostgreSQL al núvol»: és delegar a AWS l'apedaçament, les còpies, la commutació per error i la replicació, tasques que a MercadoFresco ningú no feia perquè ningú no tenia temps. I amb les còpies automàtiques i la restauració a un punt en el temps tanquem definitivament el problema 2, la part que va quedar oberta a 02-02 quan vam resoldre les còpies dels discos però no les de les dades transaccionals.

1. Què és un servei gestionat i què deixa de ser problema teu
2. RDS davant de PostgreSQL instal·lat en una EC2
3. Motors disponibles i quin tria MercadoFresco
4. Crear la instància RDS per consola
5. Crear la instància RDS per CLI
6. Multi-AZ: què és realment una rèplica síncrona en espera
7. Rèpliques de lectura: els informes de la Sara sense castigar producció
8. Còpies automàtiques, retenció i restauració a un punt en el temps
9. Instantànies manuals i el tancament del problema 2
10. Grups de paràmetres i finestres de manteniment
11. Monitoratge: mètriques bàsiques i Performance Insights
12. Connectar-se des de l'aplicació sense credencials al codi
13. Escalat vertical i emmagatzematge autoescalable
14. Migrar des del servidor de l'oficina
15. Costos i com aturar una instància de proves

Al servidor de l'oficina, PostgreSQL era responsabilitat íntegra de la Marta: instal·lar-lo, configurar-lo, actualitzar-lo, vigilar-lo, desar-ne còpies i aixecar-lo quan queia. A RDS, AWS assumeix una part concreta i ben delimitada d'aquesta feina.

És el model de responsabilitat compartida de la lliçó 01-01 aplicat a un servei concret: la línia es mou cap amunt, però no desapareix mai. RDS no arreglarà una consulta sense índex ni dissenyarà les teves taules.

El que RDS no et deixa fer, i convé saber-ho abans de triar-lo:

• No hi ha accés al sistema operatiu. Res d'SSH a la màquina de la base de dades. Si la teva operativa depèn d'scripts al servidor, cal replantejar-la.
• No hi ha superusuari real. L'usuari mestre té el rol rds_superuser, potent però limitat: no pot fer tot el que fa un superuser de PostgreSQL.
• Les extensions estan en llista blanca. Només pots instal·lar les que AWS admet (que són moltes: PostGIS, pg_stat_statements, pgvector…).
• Les versions tenen calendari de fi de suport i AWS acabarà actualitzant-te.

La pregunta legítima del Luis és: «podríem instal·lar PostgreSQL en una EC2 i surt més barat, oi?». La resposta honesta és que el preu per hora és menor, i el cost total gairebé mai.

Tria EC2 només si necessites control del sistema operatiu, una extensió no admesa, una versió concreta fora del catàleg, o si tens un equip d'administradors de bases de dades que ja fa aquesta feina. Per a MercadoFresco, que té la Marta a mitja jornada per a tot, RDS no és una opció: és l'única opció sensata.

El càlcul que tanca la discussió: una db.t3.small a eu-west-1 costa al voltant de 30 USD al mes davant d'uns 20 USD de l'EC2 equivalent. Deu dòlars de diferència. Una sola incidència nocturna de PostgreSQL a l'any, amb la Marta desperta a les 3:00, costa més que això.

MercadoFresco ja feia servir PostgreSQL al servidor de l'oficina, així que RDS PostgreSQL permet migrar sense reescriure consultes. És la decisió de menor risc.

Un aclariment que estalvia confusió: Aurora també és RDS, es gestiona des de la mateixa consola i comparteix gairebé tota l'operativa que veurem aquí, però la seva arquitectura d'emmagatzematge és diferent. A 06-03 valorarem si a MercadoFresco li compensa migrar a Aurora quan obri a tres ciutats més. I l'elecció general entre relacional, clau-valor o magatzem de columnes és la lliçó 06-01.

1. Consola → RDS → verifica la regió Irlanda (eu-west-1) → Crear base de dades.
2. Mètode: Creació estàndard (la fàcil amaga opcions que necessites veure).
3. Motor: PostgreSQL, versió 16.x.
4. Plantilla: Producció activa Multi-AZ i l'emmagatzematge provisionat per defecte. Per aprendre, tria Capa gratuïta i així no gastes; aquí descrivim la de producció.
5. Configuració:
   • Identificador: mercadofresco-pedidos
   • Usuari mestre: mfadmin (no facis servir postgres ni admin)
   • Contrasenya: marca Gestionar credencials mestres a AWS Secrets Manager. Amb això la contrasenya no la veus mai, no l'escrius mai i AWS la rota sola. Secrets Manager és la lliçó 04-03.
6. Configuració de la instància: db.t3.small (2 vCPU, 2 GiB). Per a producció real de MercadoFresco, db.m6g.large.
7. Emmagatzematge: gp3, 20 GiB, amb escalat automàtic activat i màxim 100 GiB.
8. Disponibilitat: Instància en espera Multi-AZ. És la casella que resol la meitat del problema 1 per a la base de dades.
9. Connectivitat: VPC per defecte, accés públic = No, grup de seguretat sg-mercadofresco-basedatos. La xarxa es veu al mòdul 3 (03-01 VPC, 03-02 grups de seguretat).
10. Autenticació: contrasenya; opcionalment autenticació IAM, que elimina les contrasenyes.
11. Configuració addicional:
    • Nom de base de dades inicial: pedidos
    • Còpies automàtiques: 7 dies de retenció
    • Finestra de còpies: 02:00-03:00 UTC (matinada a Espanya, trànsit mínim)
    • Finestra de manteniment: diumenge 04:00-05:00 UTC
    • Xifratge activat
    • Protecció contra eliminació: activada
    • Performance Insights: activat (7 dies són gratuïts)
12. Revisa l'estimació de cost mensual que mostra la consola i prem Crear base de dades.

La creació triga entre 5 i 15 minuts (més amb Multi-AZ, perquè construeix dues instàncies).

Avís de cost. Una db.t3.micro d'una sola AZ entra a la capa gratuïta durant 12 mesos (750 h/mes, 20 GB d'emmagatzematge i 20 GB de còpies). Multi-AZ duplica el cost de còmput i no és a la capa gratuïta. Si estàs practicant, crea la instància sense Multi-AZ i activa la casella només una estona per veure com funciona. L'apartat final explica com aturar-la i esborrar-la.

Els paràmetres que més importen:

• --manage-master-user-password: AWS genera la contrasenya, la desa a Secrets Manager i la rota automàticament. No l'escrius ni la veus mai. És la millor pràctica actual i evita el clàssic --master-user-password "Password123" a l'historial de l'intèrpret d'ordres.
• --no-publicly-accessible: la base de dades no té IP pública. Només s'hi accedeix des de dins de la VPC. Innegociable per a dades de clients.
• --max-allocated-storage 100: activa l'escalat automàtic d'emmagatzematge. Si el disc arriba al 90 % d'ocupació, RDS l'amplia sol fins a aquest sostre.
• --deletion-protection: impedeix esborrar la instància per error. Per esborrar-la de debò cal desactivar-lo primer, en un pas conscient i separat.

El punt d'enllaç tindrà aquesta forma:

És un nom DNS, no una IP, i això és fonamental. Quan es produeixi una commutació per error, AWS canviarà a què apunta aquest nom i l'aplicació es reconnectarà al servidor nou sense canviar ni una línia de configuració. Si en algun lloc del codi de MercadoFresco hi ha una IP de base de dades escrita a mà, cal treure-la ara.

Aquí hi ha un malentès molt estès que convé desfer amb claredat: la instància en espera de Multi-AZ no serveix trànsit. No és un segon servidor que reparteix càrrega. No t'hi pots connectar. És una còpia sincronitzada esperant que la principal falli.

Com funciona la replicació síncrona: quan l'aplicació confirma una transacció, PostgreSQL escriu a la principal i espera que l'escriptura s'hagi confirmat també a la instància en espera abans de respondre «fet» al client. Conseqüència doble:

• Avantatge: zero pèrdua de dades (RPO = 0). El que està confirmat és a les dues AZ.
• Cost: cada escriptura triga una mica més, perquè inclou un viatge de xarxa entre AZ (típicament 1-2 ms). En càrregues amb escriptures molt intenses es nota.

1. AWS detecta la fallada (de la instància, de l'emmagatzematge o de l'AZ sencera).
2. Canvia el registre DNS del punt d'enllaç perquè apunti a la instància en espera.
3. L'antiga instància en espera passa a ser la principal.
4. AWS crea una nova instància en espera a l'altra AZ, en segon pla.

Durada típica: 60-120 segons. Durant aquesta estona l'aplicació rep errors de connexió. Multi-AZ no és màgia invisible: és recuperació ràpida, no absència d'interrupció. L'aplicació ha d'estar preparada:

• Reintents amb espera exponencial a les operacions de base de dades.
• TTL de DNS baix al resolutor del client. Un conjunt de connexions que desa la IP a la memòria cau per sempre continuarà intentant connectar-se al servidor caigut.
• Conjunt de connexions que sàpiga descartar connexions mortes (pool_pre_ping a SQLAlchemy).

Es pot provocar una commutació a propòsit per comprovar que l'aplicació aguanta. Fes-ho en un entorn de proves, i fes-ho abans que passi sense avisar:

Són coses diferents i es confonen constantment:

MercadoFresco necessita totes dues, i per raons diferents: Multi-AZ perquè el negoci no pot perdre comandes, i rèpliques de lectura perquè els informes de la Sara estan matant la base de dades.

El problema real, mesurat: la Sara executa cada dilluns al matí una consulta que agrega les comandes del mes per barri i per franja horària. Triga 4 minuts i durant aquesta estona la botiga va lenta, perquè el mateix servidor està atenent els clients.

Una rèplica de lectura és una còpia asíncrona de la base de dades que accepta consultes de només lectura. Les escriptures continuen anant a la principal; les lectures pesades es dirigeixen a la rèplica.

Fixa't en l'etiquetatge: Componente=analitica, Propietario=sara, CentroCoste=marketing. La rèplica existeix per a la Sara, així que el seu cost s'imputa a màrqueting i no a operacions. Això és exactament el que farà possible l'informe d'assignació de costos de la lliçó 11-02.

Punts que cal tenir clars:

• La replicació és asíncrona: la rèplica va uns segons per darrere. Vigila la mètrica ReplicaLag. Per a informes agregats de vendes és perfectament acceptable; per a «consultar l'estat de la comanda que acabo de fer», no.
• L'aplicació ha de dirigir el trànsit. AWS et dona un punt d'enllaç diferent per a la rèplica; el codi decideix quin fa servir. RDS no reparteix sol.
• Una rèplica es pot promoure a instància independent, cosa que trenca la replicació de manera irreversible. És una estratègia vàlida de migració entre regions.
• Es poden crear en una altra regió, cosa que a més dona recuperació davant de desastres geogràfica.

Al codi de MercadoFresco, la separació queda així:

La consulta en SQL pur, per veure-la completa i entendre per què és cara: recorre totes les comandes del mes, les uneix amb clients i línies de comanda, i agrega per dues dimensions. Amb centenars de milers de files això és un recorregut seqüencial llarg que satura la CPU i expulsa dades calentes de la memòria cau de PostgreSQL. Justament el que no vols que passi mentre 900 clients estan comprant.

Aquí es tanca el problema 2 de MercadoFresco.

RDS fa dues coses de manera contínua i automàtica:

1. Una còpia completa diària durant la finestra que hagis fixat (02:00-03:00 UTC en el nostre cas). Amb Multi-AZ, es pren de la instància en espera, així que producció no ho nota.
2. Còpia contínua dels registres de transaccions (WAL) a S3, cada 5 minuts.

La combinació de totes dues és el que permet la restauració a un punt en el temps (Point-In-Time Recovery, PITR): pots restaurar la base de dades a qualsevol segon dins del període de retenció, no només a l'hora de la còpia diària.

L'escenari que justifica tot això: el dimarts a les 11:47, un desplegament del Luis executa per error un UPDATE sense WHERE que posa a zero el preu de tots els productes. A les 11:52 algú se n'adona.

Que la restauració creï una instància nova és deliberat i molt útil: pots verificar les dades abans de tocar producció, o fins i tot extreure només la taula afectada i copiar-la, en comptes de tirar enrere tota la base de dades i perdre les comandes legítimes d'aquests cinc minuts.

Sobre la retenció:

Les còpies automàtiques s'emmagatzemen de franc fins a la mida de la base de dades; més enllà es cobren a preu d'instantània. I hi ha un detall crític: en eliminar la instància, les còpies automàtiques s'esborren amb ella. Només les instantànies manuals sobreviuen.

Una instantània manual és una còpia que crees tu i que viu fins que tu l'esborres, fins i tot si elimines la instància. És la còpia per a fites: abans d'una migració d'esquema, abans d'una actualització de versió major, al tancament de l'exercici fiscal.

Comparació de les tres formes de recuperació a RDS:

I així queda tancat el problema 2 de MercadoFresco, sumant el de 02-02 i el d'aquesta lliçó:

Amb un advertiment que es repeteix i no sobra: la prova de restauració trimestral és part del pla, no un extra. La Marta la té al calendari.

Com que no hi ha accés al sistema operatiu, no pots editar postgresql.conf. En comptes d'això, RDS fa servir grups de paràmetres: un conjunt amb nom d'ajustos que s'associa a una o diverses instàncies.

El grup per defecte no es pot modificar, així que el primer és crear-ne un de propi:

Què hem configurat i per què:

• log_min_duration_statement = 1000: registra tota consulta que trigui més d'1 segon. És la manera més directa de trobar les consultes que enfonsen la botiga els divendres.
• shared_preload_libraries = pg_stat_statements: activa l'extensió que acumula estadístiques per consulta. Base de qualsevol treball seriós d'optimització.
• ApplyMethod: immediate s'aplica a l'instant; pending-reboot requereix reiniciar la instància. Un paràmetre dinàmic marcat com a pendent no està fent res encara, i això despista molt.

Sobre la finestra de manteniment: és l'interval setmanal en què AWS aplica pedaços del sistema operatiu i del motor. Tria-la a la vall de trànsit (diumenge de matinada per a MercadoFresco, mai un divendres a la tarda). Amb Multi-AZ, el manteniment s'aplica primer a la instància en espera, després es commuta i després s'apedaça l'altra: la interrupció es redueix al temps de la commutació.

Les actualitzacions de versió menor poden ser automàtiques (--auto-minor-version-upgrade); les de versió major (de PostgreSQL 16 a 17) no ho són mai: requereixen la teva acció explícita i cal provar-les abans en una instància restaurada des d'una instantània.

RDS publica mètriques a CloudWatch sense configurar res. Les que cal mirar:

Performance Insights va un pas més enllà: és un tauler que mostra la càrrega de la base de dades descomposta per consulta, per usuari, per amfitrió i per tipus d'espera. Aquesta última dimensió és la que resol incidències: no et diu només «la CPU està al 90 %», et diu «el 70 % de la càrrega està esperant bloqueigs de la taula pedidos, i la consulta responsable és aquesta».

Els 7 dies de retenció són gratuïts i val la pena activar-ho sempre. El monitoratge a fons, amb alarmes, taulers i agregació de registres, és la lliçó 05-01.

Primer, la comprovació manual des d'una instància EC2 de la botiga (recorda: la base de dades no és pública, així que cal connectar-s'hi des de dins de la VPC):

Un cop a dins, comprovacions útils:

I així es connecta l'aplicació, llegint el secret a l'arrencada i sense que cap credencial toqui el codi ni el repositori:

Les tres regles que resumeix aquest codi:

1. Cap credencial al codi ni al repositori. Només l'identificador del secret.
2. Autorització per rol IAM, no per claus d'accés. La instància EC2 té un rol que li permet llegir aquest secret concret i res més.
3. sslmode=require: la connexió va xifrada. RDS proporciona el certificat.

Escalat vertical (canviar la classe d'instància). És una operació amb interrupció, llevat que hi hagi Multi-AZ, on AWS modifica primer la instància en espera, commuta i després l'altra: l'aturada es redueix als 60-120 segons de la commutació.

--apply-immediately aplica el canvi ja, amb la interrupció corresponent. Sense aquest paràmetre, el canvi espera a la finestra de manteniment, que és el que vols en producció llevat d'urgència.

Escalat de l'emmagatzematge. Es pot ampliar en qualsevol moment i sense aturar res, però no reduir. Amb --max-allocated-storage, RDS ho fa sol:

Quan escalar cada cosa, en el cas de MercadoFresco:

L'ordre importa: pujar de mida és l'última opció, no la primera. Un índex que falta costa zero euros al mes; una classe d'instància més gran costa tots els mesos, per sempre.

Amb la base de dades de MercadoFresco (uns pocs GB i una finestra de manteniment nocturna acceptable), la migració clàssica amb abocament i restauració és suficient.

Per què --no-owner --no-privileges: els rols i permisos del servidor d'origen no existeixen a RDS, i sense aquestes opcions la restauració s'omple d'errors per intentar assignar objectes a usuaris inexistents.

Verificació obligatòria abans de commutar el trànsit:

Pla de commutació de MercadoFresco, un diumenge de matinada:

1. 02:00 — Posar la botiga en mode manteniment (només lectura).
2. 02:05 — pg_dump final del servidor de l'oficina.
3. 02:20 — pg_restore a RDS i ANALYZE.
4. 02:40 — Verificar recomptes i executar la bateria de proves de fum.
5. 02:50 — Canviar les variables d'entorn de l'aplicació al nou punt d'enllaç.
6. 03:00 — Treure el mode manteniment i vigilar mètriques durant una hora.
7. El servidor de l'oficina es deixa encès i sincronitzat una setmana, per si cal tirar enrere.

Quan no es pot aturar la botiga, l'eina és AWS DMS (Database Migration Service): copia l'estat inicial i després replica els canvis en continu (change data capture), de manera que la finestra de tall es redueix a segons. A més pot migrar entre motors diferents (d'Oracle a PostgreSQL, per exemple). Per a MercadoFresco és exagerat; per a una migració sense aturada, és el camí.

Components de la factura de RDS:

Cost mensual de la configuració de producció de MercadoFresco:

Uns 78 € al mes per una base de dades amb alta disponibilitat, còpies automàtiques, PITR de 7 dies i una rèplica per a analítica. Comparat amb els 6.000 € del servidor original —que no tenia res d'això— i amb el temps que la Marta dedicava a mantenir-lo, la conversa econòmica es torna fàcil.

Aturar una instància de proves:

Dues limitacions importants: RDS només permet tenir una instància aturada 7 dies; al vuitè l'arrenca sola. I una instància Multi-AZ no es pot aturar. Per a entorns de desenvolupament que només es fan servir en horari laboral, el pràctic és programar l'arrencada i l'aturada, o simplement esborrar i recrear des d'una instantània.

Eliminar per complet quan acabis la pràctica:

• Creure que la instància en espera de Multi-AZ serveix lectures. No. Per a això hi ha les rèpliques de lectura. És el malentès número u de RDS.
• Posar --publicly-accessible per «poder connectar-me des de casa». Exposa la base de dades a internet. La manera correcta és un bastió, Session Manager o una VPN.
• Escriure la contrasenya a la comanda o al codi. Fes servir --manage-master-user-password i Secrets Manager (04-03).
• Retenció de còpies a 0 dies. Desactiva el PITR. És la configuració que converteix un error humà recuperable en una pèrdua definitiva.
• Oblidar que les còpies automàtiques s'esborren amb la instància. Abans d'eliminar, treu una instantània final.
• Canviar un paràmetre pending-reboot i esperar que actuï. No fa res fins a reiniciar.
• Restaurar i no executar ANALYZE. Sense estadístiques, el planificador pren decisions pèssimes i sembla que RDS «va lent».
• Posar la finestra de manteniment en hora punta. Diumenge de matinada, mai divendres a la tarda.
• Pujar de classe d'instància abans de mirar les consultes. Un índex que falta costa 0 USD al mes; una instància més gran, tots els mesos.
• Llegir de la rèplica el que l'usuari acaba d'escriure. El retard asíncron farà que de vegades no aparegui. Lectures crítiques, sempre a la principal.
• No provar mai una commutació per error. Provoca-la en un entorn de proves i comprova que l'aplicació es reconnecta. Descobrir-ho en producció surt car.
• Consell: activa Performance Insights des del primer dia. És gratis 7 dies i el dia que hi hagi una incidència voldràs tenir l'històric.

MercadoFresco obre a tres ciutats més (problema 3). La previsió és:

• El pic dels divendres passa a 2.100 comandes/hora (escriptures intenses).
• La Sara passa d'un informe setmanal a un tauler que es refresca cada 15 minuts.
• Apareix un requisit nou: si es perd la regió eu-west-1 sencera, el negoci ha de poder operar en menys de 4 hores.
• Es manté el requisit de no perdre cap comanda confirmada.

Dissenya la topologia de RDS: quines instàncies, de quin tipus, en quines AZ i regions, i quin mecanisme cobreix cada requisit. Indica quin requisit no pot cobrir RDS per si sol.

El dijous a les 16:12, un script de sincronització de catàleg executa per error:

Ha esborrat 47.000 línies de comandes històriques que sí que eren vàlides. Ningú no se n'adona fins al divendres a les 10:30, quan la Sara veu que les xifres de juliol no quadren. En aquest temps s'han registrat unes 1.400 comandes noves que no es poden perdre.

Descriu el procediment complet de recuperació, amb les comandes, i explica per què no es pot simplement restaurar la base de dades al dijous a les 16:11.

Per a cada consulta de MercadoFresco, indica si ha d'anar a la instància principal o a la rèplica de lectura, i justifica-ho en una frase:

• A) INSERT d'una comanda nova des de la cistella.
• B) «Les meves comandes» d'un client que acaba de comprar fa 3 segons.
• C) Informe mensual de vendes agregades per barri.
• D) Llistat del catàleg de productes a la pàgina principal.
• E) Comprovació d'estoc just abans de confirmar una comanda.
• F) Exportació nocturna de totes les comandes a S3 per a analítica.

Solució 1.

Topologia resultant:

El que RDS no cobreix per si sol: el pic d'escriptures dels divendres continua depenent d'una sola instància escriptora. Escalar verticalment té un sostre. Les solucions reals són fora d'aquesta lliçó: encuar les comandes amb SQS per absorbir el pic i escriure-les a ritme sostingut (mòdul 7), posar les lectures calentes a la memòria cau amb ElastiCache (06-05), o repartir l'escriptura amb un model diferent de dades (DynamoDB, 06-02). Reconèixer aquest sostre és part de saber fer servir RDS.

Solució 2.

Per què no es pot restaurar sense més al dijous a les 16:11: això retornaria la base de dades a l'estat d'aquell instant, i amb això desapareixerien les 1.400 comandes registrades entre el dijous a la tarda i el divendres al matí. S'arreglaria un problema creant-ne un de pitjor. La restauració completa només val quan el dany es detecta en minuts.

El procediment correcte és restaurar en paral·lel i recuperar només el que s'ha esborrat:

Lliçons que deixa l'incident: el DELETE s'hauria d'haver executat dins d'una transacció amb verificació prèvia del recompte; els scripts de manteniment no han de fer servir l'usuari mestre sinó un rol amb permisos acotats (04-01); i una alarma sobre variacions brusques del nombre de files hauria avisat el dijous i no el divendres.

Solució 3.

Patró general: escriptures i lectures crítiques o immediates → principal; lectures analítiques, històriques o tolerants al retard → rèplica.

La base de dades de comandes de MercadoFresco ja és a AWS, i amb ella el cor del negoci. Entens què significa un servei gestionat: AWS assumeix el maquinari, el sistema operatiu, els pedaços del motor, les còpies i la commutació per error; tu continues sent responsable de l'esquema, els índexs, les consultes i la seguretat de l'aplicació. Saps també a què renuncies a canvi —accés al sistema operatiu, superusuari real, extensions fora de llista— i en quins casos concrets això obliga a triar PostgreSQL sobre EC2 en comptes de RDS.

Has creat la instància mercadofresco-pedidos per consola i per CLI, amb les decisions que importen preses conscientment: contrasenya gestionada a Secrets Manager per no escriure-la mai, sense accés públic, xifratge activat, protecció contra eliminació, escalat automàtic d'emmagatzematge, retenció de còpies de 7 dies i finestres de còpia i manteniment col·locades a la vall de trànsit i mai un divendres a la tarda.

Has desfet el malentès més comú de RDS: la instància en espera de Multi-AZ no serveix trànsit. És una rèplica síncrona que garanteix zero pèrdua de dades i commuta en 60-120 segons canviant el DNS del punt d'enllaç, amb la contrapartida de sumar latència a cada escriptura i d'exigir que l'aplicació reintenti. Davant d'ella, les rèpliques de lectura són asíncrones, sí que es poden consultar i són l'eina correcta perquè el tauler de la Sara no castigui producció; has vist en codi i en taula quina consulta va a cada lloc.

I has tancat el problema 2 de MercadoFresco. Entre les instantànies d'EBS automatitzades amb DLM de la lliçó 02-02, el versionatge d'S3 de la 02-03 i ara les còpies automàtiques de RDS amb registres de transaccions cada cinc minuts, l'empresa ha passat d'«un pg_dump a un disc extern quan algú se'n recorda» a poder restaurar a qualsevol segon dels últims set dies. Has practicat la recuperació real d'un esborrament massiu restaurant en paral·lel i reinserint només el que s'havia perdut, sense sacrificar les comandes posteriors. Hi sumes les instantànies manuals que sobreviuen a l'esborrament de la instància, els grups de paràmetres amb log_min_duration_statement i pg_stat_statements per caçar consultes lentes, Performance Insights per saber en què espera realment la base de dades, la connexió des de l'aplicació sense ni una sola credencial al codi, l'escalat vertical i d'emmagatzematge amb la seva regla d'or —mira els índexs abans de pujar de classe— i el pla complet de migració amb pg_dump/pg_restore i la seva alternativa sense aturada, AWS DMS.

Queda una última peça del mòdul. Tenim servidors que cal dimensionar, arrencar i pagar encara que estiguin ociosos. Però hi ha tasques de MercadoFresco que no necessiten un servidor esperant: generar la miniatura d'una foto quan es puja, respondre a una consulta puntual de l'estat d'una comanda, processar un fitxer. A la lliçó 02-05, «AWS Lambda», escriurem codi que s'executa només quan passa alguna cosa i només es paga mentre corre, connectarem per fi l'esdeveniment d'S3 que vam deixar configurat a 02-03 per generar les miniatures del catàleg, i recapitularem quines peces de MercadoFresco ja són al núvol i què falta per construir.