Agrāk uz jautājumu "kā migrēsim datubāzi" noklusētā atbilde bija tehniskais pārtraukums. Daudzām mūsdienu produkcijas sistēmām tas vairs nav iespējams — loģistikas platformām, maksājumu sistēmām un spēļu aizmugursistēmām nav klusa loga plkst. 2 naktī, kad neviens nepamanītu pāris stundu dīkstāvi. Slodze neapstājas, un tāpēc datubāze arī nedrīkst apstāties.
Labā ziņa ir tā, ka PostgreSQL kopš 10. versijas nodrošina iebūvētu loģisko replikāciju, un paņēmiens, kā to izmantot nulles dīkstāves migrācijai, ir labi zināms. Sliktā ziņa ir tā, ka lielākā daļa riska šādā migrācijā nemaz nav pašā replikācijas tehnoloģijā — tas slēpjas desmitos sīku detaļu ap to, kuras automātiski netiek replicētas.
Pamatprincips
Loģiskā replikācija straumē rindu līmeņa izmaiņas no avota datubāzes uz mērķa datubāzi neatkarīgi no infrastruktūras katrā pusē. Tieši tāpēc tā noder migrācijām, kas šķērso mākoņpakalpojumu sniedzējus, veic lielu versiju jaunināšanu vai pāriet starp pilnīgi atšķirīgām vidēm — avots turpina apkalpot produkcijas slodzi, kamēr mērķis klusi turpina sekot līdzi izmaiņām fonā.
Pati migrācija seko paredzamai secībai:
- Sākotnējā inventarizācija. Shēma, paplašinājumi, sekvences, trigeri, ārējo datu apvijēji (foreign data wrappers) un viss cits, ko loģiskā replikācija pati par sevi nepārnes.
- Sagatavot mērķa datubāzi un replicēt shēmu — ne tikai tabulas, bet arī indeksus, ierobežojumus un paplašinājumu versijas, kas pietiekami precīzi atbilst avotam, lai zem slodzes uzvestos tāpat.
- Sākotnējā masveida kopēšana esošajiem datiem, kam seko replikācijas slots, kas sāk panākt visu, kas ierakstīts kopš kopēšanas sākuma.
- Validēt reālā slodzē. Vispirms rindu skaitu un kontrolsummas, pēc tam replikācijas aizkavi zem faktiskas produkcijas slodzes — nevis sintētiska testa.
- Pārslēgšana. Īss, precīzi nomērīts logs — sekundes, nevis stundas — kurā savienojumi tiek noslēgti no vecā mērķa un pārslēdzas uz jauno.
- Atstāt atgriešanās ceļu dzīvu vēl vairākas dienas pēc pārslēgšanas, nevis minūtes. Vecā kopa turpina saņemt replicētas izmaiņas pretējā virzienā, kamēr jaunā nav pierādījusi sevi pilnā biznesa ciklā.
Šo precīzo paņēmienu esam izmantojuši kopās, kas pārslēgšanas loga laikā uztur vairāk nekā 16 000 transakciju sekundē — tehnika strādā tikpat labi šādā mērogā, cik pieticīgā vienreģiona izvietojumā. Atšķirība lielā mērogā ir tikai un vienīgi tajā, cik daudz validācijas notiek pirms kāds pieskaras pārslēgšanas slēdzim.
Kur migrācijas patiesībā noiet greizi
Gandrīz neviens no incidentiem, ko esam redzējuši PostgreSQL migrācijās, nav radies tāpēc, ka loģiskā replikācija nespēja replicēt. Tie radās lietu dēļ, ko loģiskā replikācija nekad arī nebija paredzēta risināt:
- Sekvences. Loģiskā replikācija automātiski nesaskaņo sekvenču vērtības — ja tās pirms pārslēgšanas nesinhronizējat skaidri, pirmie ieraksti jaunajā primārajā serverī var sadurties ar jau esošām rindām.
- DDL izmaiņas migrācijas laikā. Natīvā loģiskā replikācija nereplicē shēmas izmaiņas. Migrācijai, kuras laikā uz avota tiek izpildīta shēmas izmaiņa vidū starp sinhronizāciju, ir nepieciešams skaidrs plāns, kā to pārnest uz mērķi — pretējā gadījumā abas datubāzes klusi sāk atšķirties.
- Lielie objekti un neierasti datu tipi. Dažiem objektu tipiem loģiskās replikācijas apstākļos nepieciešama īpaša apstrāde. To noskaidrojiet inventarizācijas posmā, nevis pārslēgšanas brīdī.
- Paplašinājumu versiju neatbilstības. PostGIS, pg_cron un līdzīgiem paplašinājumiem abās pusēs jābūt saskaņotām versijām — pretējā gadījumā uzvedība var atšķirties smalkos veidos, kas neatklājas, kamēr netiek izpildīti konkrēti vaicājumi.
- Sasteigta savienojumu iztukšošana. Visbiežāk pašu izraisītais dīkstāves gadījums "nulles dīkstāves" migrācijā ir savienojumu aizvēršana ar veco datubāzi, pirms lietojumprogramma patiešām ir gatava pieslēgties jaunajai. Tā vairāk ir lietojumprogrammas līmeņa koordinācijas problēma nekā datubāzes problēma.
Kas patiesībā padara to par nulles dīkstāves migrāciju
Replikācijas tehnoloģija jūs aizved 90% no ceļa. Pārējie 10% — sekvenču resinhronizācija, DDL disciplīna, savienojumu iztukšošana un atgriešanās plāns, ko esat tiešām gatavi izmantot — ir tas, kur iet inženiertehniskā piepūle, un šo daļu ir viegli nenovērtēt, ja par loģisko replikāciju esat tikai lasījuši, nevis paši veikuši pārslēgšanu dzīvā produkcijas sistēmā.
Galvenās atziņas
- Loģiskā replikācija nodrošina datu sinhronizāciju; tā neapstrādā sekvences, DDL izmaiņas vai savienojumu iztukšošanu — tie jāplāno atsevišķi.
- Validējiet reālā produkcijas slodzē pirms pārslēgšanas, nevis sintētiskā slodzes testā.
- Turiet atgriešanās ceļu dzīvu vairākas dienas, nevis minūtes, pēc pārslēgšanas.
- Pārslēgšanas logam jābūt mērāmam sekundēs — ja tas mērāms stundās, vispirms jāsakārto kaut kas augstāk par pašu datubāzi.