Les dues lliçons anteriors van dissenyar sistemes nous amb llibertat total. Aquesta és diferent, i per això s'assembla molt més al que et trobaràs en un projecte real. El portal de continguts i el blog corporatiu de Contoso Airlines —notícies de l'aerolínia, guies de destinacions, avisos d'operacions i la sala de premsa— és un WordPress que fa vuit anys que funciona sobre un MySQL 5.7 instal·lat en un servidor del soterrani de l'oficina de Barcelona. Té 14 GB de dades, 40.000 articles, connectors de tercers, còpies de seguretat en un disc USB que ningú no ha provat de restaurar i, sobretot, una regla clara de direcció: no es reescriu res.

L'objectiu és endur-se'l a Azure tal qual, guanyant còpies automàtiques, alta disponibilitat i apedaçament, sense tocar ni una línia de PHP. Això és exactament el que fa Azure Database for MySQL - Servidor flexible, i aquesta lliçó el desplega, el connecta a la xarxa privada i executa la migració amb la seva finestra de manteniment acordada.

Avís de cost: un servidor flexible de nivell Ús general amb 2 vCores ronda els 120-150 € al mes més emmagatzematge, i l'alta disponibilitat amb redundància de zona duplica el còmput. La bona notícia respecte a Azure SQL Database és que aquí sí que es pot aturar el servidor (fins a 30 dies seguits), cosa que en desenvolupament canvia del tot la factura. Tot i així, elimina el grup de recursos de laboratori en acabar.

1. El punt de partida i què cal conservar
2. Servidor flexible: què gestiona Azure i què continues gestionant tu
3. Nivells de còmput i emmagatzematge
4. Alta disponibilitat i el seu cost
5. Desplegament amb Azure CLI i accés privat
6. Paràmetres del servidor
7. Rèpliques de lectura per al trànsit del blog
8. Còpies de seguretat, retenció i restauració
9. La migració des del servidor de Barcelona
10. Aturar el servidor per estalviar en desenvolupament
11. Connexió segura per TLS i què canvia a l'aplicació
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

Aquesta última dada és la que governa tota la lliçó: una finestra de quatre hores permet una migració fora de línia, que és molt més simple que una en línia. Si el tall admissible fos de minuts, l'estratègia canviaria.

Servidor flexible és el model de desplegament actual del servei (l'antic «servidor únic» està en retirada i no s'ha de fer servir en projectes nous). Cada servidor és una instància de MySQL sobre una màquina virtual gestionada, amb emmagatzematge remot redundant, integrable directament a la teva xarxa virtual i amb control fi de paràmetres i finestres de manteniment.

La frontera és nítida: Azure s'ocupa de la màquina i del procés; tu continues sent responsable de tot el que hi ha dins de la base de dades. Migrar a PaaS no converteix un esquema dolent en un de bo.

La trampa del nivell Ampliable és que funciona perfectament fins que s'esgoten els crèdits de CPU, i llavors el rendiment s'esfondra just quan hi ha trànsit. Serveix per a l'entorn de desenvolupament del portal, no per al portal.

L'emmagatzematge té un detall que gairebé ningú no mira: les IOPS van lligades a la mida aprovisionada. Un disc de 32 GB ofereix molt poques operacions per segon, i ampliar-lo és la manera més barata d'arreglar un problema d'E/S. Es pot activar el creixement automàtic, molt recomanable perquè quedar-se sense espai deixa el servidor en només lectura, i als nivells superiors es poden aprovisionar IOPS per damunt del que correspon a la mida. L'emmagatzematge només es pot augmentar, mai reduir.

Contoso tria per a producció Ús general, 2 vCores, 128 GB (amb marge sobre els 14 GB actuals per créixer i per tenir prou IOPS) i per a desenvolupament Ampliable B1ms amb 32 GB.

Dues modalitats, més l'opció de no tenir-ne cap:

Si has de pagar el doble, tria redundància de zona: costa el mateix que la mateixa zona i protegeix de més coses. La modalitat de mateixa zona només té sentit en regions sense zones de disponibilitat o quan la latència entre zones és crítica.

Contoso activa redundància de zona en producció —el portal és la cara pública de l'aerolínia i també publica els avisos d'incidències, justament quan més es consulta— i cap alta disponibilitat en desenvolupament.

Hi ha dos mètodes de connectivitat i es trien en crear el servidor, sense possibilitat de canviar-los després:

• Accés públic amb regles de tallafoc: el servidor té nom públic i es filtra per IP. Còmode per començar, i una superfície d'atac permanent.
• Accés privat amb integració en xarxa virtual: el servidor es col·loca en una subxarxa delegada i només és accessible des de la xarxa. No té cap punt d'entrada des d'internet.

Contoso tria accés privat, per coherència amb el que s'ha fet a pe-sql-reservas i perquè el WordPress s'executa a App Service amb integració de xarxa virtual: res no ha d'arribar a la base des de fora. La subxarxa delegada és snet-integracion-app, que ja es va reservar al mòdul 2 per a aquest tipus de serveis.

Dos paràmetres mereixen atenció especial. --private-dns-zone reutilitza la zona privada interno.contosoairlines.example del mòdul 2, de manera que el servidor es resol per nom intern des de tota la xarxa. I --charset utf8mb4: MySQL arrossega un joc de caràcters històric anomenat utf8 que no és UTF-8 complet i no admet emojis ni certs caràcters; fer servir utf8mb4 des del principi evita el clàssic article del blog que apareix amb símbols trencats després de la migració.

No hi ha accés al fitxer my.cnf, però tots els seus paràmetres estan exposats com a configuració del servidor. Els que es toquen a la pràctica:

Sobre max_connections: pujar-lo sense més és una mala solució, perquè cada connexió consumeix memòria i el màxim permès depèn de la mida del servidor. Si l'aplicació obre moltes connexions curtes, el correcte és agrupar connexions al client. Alguns paràmetres són estàtics i exigeixen reiniciar el servidor; la CLI ho adverteix, i aquest reinici s'ha de planificar.

El portal és un cas de manual: el 98 % del trànsit són lectures d'articles i només el 2 % són escriptures de l'equip de comunicació. Una rèplica de lectura copia el servidor de manera asíncrona i absorbeix aquest trànsit:

Tres advertiments imprescindibles: la rèplica és asíncrona, així que pot anar uns segons per darrere i no serveix per llegir una cosa que s'acaba d'escriure; l'aplicació ha de dirigir explícitament les lectures al seu nom, cosa que en WordPress es resol amb un connector de bases de dades separades; i la rèplica factura com un servidor complet, així que es justifica quan el trànsit ho demana, no per defecte. Si calgués promocionar-la a servidor independent, s'atura la replicació amb az mysql flexible-server replica stop, operació irreversible.

Les còpies són automàtiques: completa diària i del registre de transaccions cada pocs minuts, amb retenció configurable d'1 a 35 dies i opció de redundància geogràfica cap a North Europe, que és la que es va activar amb --geo-redundant-backup Enabled. Contoso fixa 14 dies, prou per detectar l'error típic del portal —un connector que corromp taules o un esborrat massiu de comentaris— sense engreixar la factura.

La restauració funciona igual que a Azure SQL Database: crea un servidor nou, mai no sobreescriu l'original.

I la regla que es repeteix a tot el mòdul: aquest servidor restaurat factura des del primer minut. Es recuperen les dades, es verifiquen i s'elimina el mateix dia. Una còpia provada val infinitament més que tres còpies sense provar, així que convé assajar la restauració una vegada per trimestre.

Dos camins, i la tria depèn del tall admissible:

Amb 14 GB i una finestra de quatre hores un diumenge de matinada, Contoso tria mysqldump en mode fora de línia. És més simple, i el que és simple falla menys a les tres de la matinada.

Llista de verificació prèvia (la setmana anterior, no el mateix dia):

1. Versió d'origen i destinació compatibles; provar abans la migració a mysql-contoso-portal-dev.
2. Inventariar jocs de caràcters i intercalacions de totes les taules: SELECT table_name, table_collation FROM information_schema.tables WHERE table_schema='portal_contenidos';
3. Comprovar que no es fan servir funcionalitats no admeses (motor MyISAM en taules crítiques, SUPER, procediments que depenen del sistema de fitxers).
4. Anotar el recompte de files de les taules grans: wp_posts, wp_postmeta, wp_comments.
5. Revisar usuaris i permisos: els usuaris de MySQL no viatgen en un bolcat normal.
6. Congelar la publicació de continguts i avisar l'equip de comunicació.

Execució, amb la connectivitat ja muntada per la VPN de lloc a lloc del mòdul 2:

Verificació posterior, abans de reobrir el portal:

1. Recompte de files per taula, comparat amb l'anotat abans.
2. Comprovar accents i emojis en articles recents; si apareixen trencats, el problema és al joc de caràcters i cal repetir el bolcat, no arreglar-ho a mà.
3. Recrear usuaris i permisos d'aplicació amb CREATE USER i GRANT mínims (mai l'administrador per a l'aplicació).
4. Canviar la cadena de connexió de WordPress i provar la web completa: portada, article, cerca, comentari, tauler d'administració.
5. Deixar el servidor de Barcelona apagat però intacte dues setmanes, com a pla de reversió.

Aquesta és la diferència pràctica més agradable respecte a Azure SQL Database: un servidor flexible es pot aturar, i mentre està aturat no es factura còmput (l'emmagatzematge sí).

Es reinicia sol al cap de 30 dies aturat, així que no serveix com a manera d'«arxivar» un servidor: per a això, es fa un bolcat i s'elimina. Combinat amb un runbook d'Azure Automation (07-04) que l'atura a les 19:00 i l'arrenca a les 8:00 de dilluns a divendres, l'entorn de desenvolupament passa a costar aproximadament un terç.

Azure Database for MySQL exigeix TLS de manera predeterminada, i així ha de quedar-se. Per a l'aplicació això significa dos canvis petits però obligatoris a la cadena de connexió: indicar el mode TLS i, si el client ho requereix, el certificat arrel.

Tingues en compte que el nom de l'amfitrió és el privat, resoluble només des de la xarxa virtual; que l'usuari és un d'aplicació amb permisos mínims sobre portal_contenidos; i que la contrasenya no hauria de ser al fitxer, sinó a Key Vault, referenciada des dels ajustos de l'aplicació d'App Service (lliçó 04-03). Si un client antic no admet TLS 1.2, la solució és actualitzar el client, no rebaixar el servidor.

• Triar accés públic «per provar» i quedar-se així. El mètode de connectivitat no es pot canviar després de crear el servidor: obliga a recrear-lo i tornar a migrar.
• Fer servir utf8 en lloc de utf8mb4. L'utf8 de MySQL no és UTF-8 complet. Es detecta quan els articles apareixen amb caràcters trencats i ja hi ha trànsit a sobre.
• Posar el nivell Ampliable en producció. Va bé fins que s'esgoten els crèdits de CPU, i això passa precisament el dia de més visites.
• Pujar max_connections com a resposta a qualsevol error de connexions. Cada connexió consumeix memòria; la solució sol ser agrupar connexions a l'aplicació.
• Confiar en la rèplica de lectura per a dades acabades d'escriure. És asíncrona: el redactor publicaria un article i no el veuria a la web.
• Migrar sense comptar files abans i després. Sense aquest recompte no hi ha manera objectiva de saber si la migració va ser completa.
• Oblidar els usuaris i permisos. Un mysqldump d'una base no inclou els comptes de MySQL: si ningú no els recrea, l'aplicació no arrenca a la finestra de tall.
• Consell: assaja la migració completa a l'entorn de desenvolupament amb una còpia real de les dades. La primera vegada sempre apareix alguna cosa, i és millor que aparegui un dimecres a la tarda.
• Consell: mantén el servidor d'origen apagat i intacte dues setmanes. És el pla de reversió més barat que existeix.

El portal rep 120.000 visites al mes, amb pics els dilluns al matí quan es publiquen els avisos operatius. La base ocupa 14 GB i creix uns 3 GB l'any.

1. Tria nivell de còmput, mida d'emmagatzematge i modalitat d'alta disponibilitat per a producció i per a desenvolupament, justificant cada tria.
2. Quin mètode de connectivitat tries i per què és una decisió que no admet penediment?
3. Quina retenció de còpies fixaries a cada entorn?

L'equip disposa d'una finestra de quatre hores el diumenge de 02:00 a 06:00.

1. Tria entre mysqldump i Azure Database Migration Service i justifica-ho.
2. Escriu tres comprovacions prèvies i tres de posteriors, indicant què faries si alguna falla.
3. Descriu el pla de reversió si a les 05:30 el portal no funciona correctament.

Després de la migració, el portal respon bé llevat dels dilluns a les 09:00, quan algunes pàgines triguen més de 10 segons i apareixen errors de «too many connections».

1. Quin paràmetre del servidor activaries primer per diagnosticar, i com?
2. Enumera tres causes possibles, amb la seva correcció respectiva.
3. Resoldria el problema una rèplica de lectura? I una simple ampliació de l'emmagatzematge?

Solució 1:

1. Producció: Ús general amb 2 vCores (la CPU dedicada evita l'esfondrament del nivell Ampliable al pic del dilluns), 128 GB d'emmagatzematge —no per espai, sinó per les IOPS associades a la mida i per marge de creixement— amb creixement automàtic activat, i alta disponibilitat amb redundància de zona, ja que el portal publica els avisos d'incidències justament quan més es consulta. Desenvolupament: Ampliable B1ms, 32 GB, sense alta disponibilitat.
2. Accés privat amb integració a snet-integracion-app. No admet penediment perquè el mètode de connectivitat es fixa en crear el servidor: canviar-lo obliga a crear un altre servidor i repetir la migració completa.
3. Producció, 14 dies amb redundància geogràfica; desenvolupament, 7 dies sense ella, ja que les dades són una còpia i són regenerables.

Solució 2:

1. mysqldump fora de línia. Amb 14 GB, el bolcat i la càrrega caben de sobres en quatre hores, i no cal replicació contínua. El servei de migració afegiria complexitat de configuració sense resoldre cap problema real; es reservaria per a volums de centenars de GB o talls de minuts.
2. Prèvies: (a) provar la migració completa en desenvolupament —si falla, s'ajorna la finestra, mai no s'improvisa; (b) verificar jocs de caràcters de totes les taules —si hi ha barreja, es normalitza abans; (c) anotar recomptes de files —sense ells no hi haurà verificació possible. Posteriors: (a) comparar recomptes —si no quadren, es reverteix; (b) revisar accents i emojis —si estan trencats, es repeteix el bolcat amb --default-character-set=utf8mb4; (c) provar el recorregut complet de la web, inclosa la publicació d'un article de prova.
3. Reversió: tornar la cadena de connexió de WordPress al servidor de Barcelona, que s'ha mantingut apagat però intacte, arrencar-lo, verificar el portal i reprogramar la finestra. Com que la publicació de continguts estava congelada, no hi ha escriptures noves per perdre.

Solució 3:

1. slow_query_log en ON amb long_query_time en 2 segons, i després revisar el registre per identificar les consultes que es repeteixen al pic. És la primera mesura perquè converteix una queixa en dades.
2. Causes i correccions: (a) consultes lentes d'un connector sobre wp_postmeta sense índex adequat, que es corregeix creant l'índex o desactivant el connector; (b) excés de connexions curtes per no agrupar connexions, que es corregeix amb agrupació al client i, secundàriament, ajustant max_connections; (c) IOPS insuficients per un emmagatzematge petit, que es corregeix ampliant el disc o aprovisionant IOPS addicionals.
3. Una rèplica de lectura sí que ajudaria, perquè el 98 % del trànsit són lectures i repartir-les alleuja el servidor principal, però requereix que l'aplicació dirigeixi les lectures a la rèplica. Ampliar l'emmagatzematge ajuda només si el coll d'ampolla són les IOPS; si el problema són consultes mal indexades o connexions, no canvia res i només puja la factura. Per això el diagnòstic va primer.

Has portat a Azure un sistema heretat sense reescriure ni una línia, que és la migració més freqüent i menys glamurosa de qualsevol projecte real. Saps què és Azure Database for MySQL - Servidor flexible, on és la frontera entre el que gestiona Azure i el que continua sent teu, i per què el model de servidor únic ja no es fa servir. Distingeixes els nivells Ampliable, Ús general i Optimitzat per a memòria i coneixes la trampa dels crèdits de CPU, a més de la relació entre mida d'emmagatzematge i IOPS i per què convé el creixement automàtic. Has comparat l'alta disponibilitat de mateixa zona davant de redundància de zona —mateix preu, més protecció— i has desplegat mysql-contoso-portal-pro amb accés privat a snet-integracion-app i la seva zona DNS interna, sabent que aquest mètode de connectivitat no es pot canviar després.

Has ajustat els paràmetres que realment es toquen —max_connections, slow_query_log, character_set_server amb utf8mb4 perquè els accents i els emojis no es trenquin—, afegit una rèplica de lectura per al 98 % de trànsit de lectura del blog amb els seus tres advertiments, configurat còpies amb 14 dies de retenció i restaurat a un servidor nou que cal eliminar el mateix dia. I sobretot has executat la migració: la comparació entre mysqldump i Azure Database Migration Service, la tria del mode fora de línia per la finestra de quatre hores, la llista de verificació prèvia, les ordres de bolcat i càrrega, la verificació posterior amb recomptes de files i el pla de reversió de dues setmanes. Tanques amb dos detalls molt pràctics: que aquest servei sí que permet aturar el servidor per no pagar còmput en desenvolupament i què canvia exactament a la cadena de connexió en forçar TLS.

El següent sistema del mapa de dades també ve de fora, però per un motiu oposat. El sistema de planificació de tripulacions de Contoso no fa servir PostgreSQL per casualitat: el va triar perquè necessita consultes complexes sobre torns i descansos, tipus de dades rics i extensions que no existeixen en altres motors, en particular càlculs geogràfics de distàncies i rutes entre aeroports. A Azure Database for PostgreSQL veuràs què comparteix amb el que acabes d'aprendre —que és molt, i ho marcarem explícitament per no repetir-ho— i, sobretot, el que és diferencial: les extensions i la seva llista de permeses, amb postgis per a les rutes i pgvector mirant ja cap als serveis d'IA del mòdul 6, l'ajust de rendiment amb EXPLAIN ANALYZE, el problema de l'autovacuum en taules amb molta rotació i l'agrupació de connexions amb PgBouncer.