Darbs, kas runā pats par sevi.

Produkcijas PostgreSQL klasteris bija jāpārceļ no lokālās infrastruktūras uz AWS, kamēr platforma vairākās vidēs apstrādāja 2 000–16 000 darījumu sekundē. Mērķis: ļaut AWS pārņemt 90% no slodzes. Ierobežojums: bez dīkstāves, bez datu zuduma.

• Platforma nepieejama 1+ stundu pārslēgšanās (cutover) laikā
• Datu bojāšanās starp veco un jauno klasteri
• Replikācijas kļūme bez drošas atgriešanās iespējas
• Tiešā ietekme uz ieņēmumiem, skarot 1+ miljardu galalietotāju

• Uzbūvējām jauno vidi pilnībā no jauna
• Pārbaudījām replikāciju un failover reālas slodzes apstākļos
• Kontrolējām katru pārslēgšanās soli ar iespēju momentāni atgriezties
• Pabeidzām visu iestatīšanu mazāk nekā 3 mēnešos

PostgreSQL tehniski bija "aktīvs" — taču sistēma nemanāmi tuvojās savām reālajām robežām. CPU piesātinājums primārajā mezglā, augoša replikācijas aizture, atpalikuši lasīšanas replikas un savienojumu virsotnes no automātiskās mērogošanas veidoja ķēdes reakciju.

Ja primārais mezgls būtu atteicies, replikas būtu pārāk tālu atpalikušas, lai tās droši paaugstinātu. Iespējamais iznākums: pilna platformas dīkstāve ar iespējamu datu zudumu. Ķēde jau bija sākusies.

• Ierobežojām savienojumu vētras un apturējām ilgstoši bloķējošos vaicājumus
• Pielāgojām replikāciju, WAL apstrādi un I/O slodzes apstākļos
• Novērsām neefektīvus vaicājumus un pievienojām trūkstošos indeksus bez dīkstāves
• Ieviesām pretspiediena (back-pressure) mehānismus un circuit breaker principus
• Simulējām failover un avārijas scenārijus reālas slodzes apstākļos

ClickHouse nodrošināja norēķinu sistēmu — apkopoja visus klientu lietojuma datus un ģenerēja rēķinus. Datu apjoms un vienlaicīgo vaicājumu skaits pastāvīgi pieauga, un norēķinu cikli izraisīja CPU un atmiņas slodzes virsotnes, kas apdraudēja galvenās platformas stabilitāti.

• Vaicājumu slodzes virsotnes izsmeļ CPU un atmiņu
• Taimauti rēķinu ģenerēšanas laikā
• Nepareizi vai novēloti rēķini, kas ietekmē ieņēmumus
• Analītikas slodze destabilizē galveno platformu

• Auditējām norēķinu datu modeļus un agregācijas loģiku
• Uzlabojām laika bāzētu norēķinu datu sadalījumu (partitioning)
• Optimizējām smagos agregācijas vaicājumus un samazinājām pilnu tabulu skenēšanu
• Ieviesām slodžu izolāciju un vaicājumu limitus norēķinu virsotņu laikā

ClickHouse instance, kas nodrošināja reāllaika analītiku, sāka uzrādīt resursu izsīkuma pazīmes maksimālas slodzes brīžos — CPU tuvu piesātinājumam, augoša atmiņas noslodze un pieaugošas vaicājumu rindas. Sistēma vēl nebija atteikusies, taču atteice bija tuvu.

• Pilna ClickHouse dīkstāve, kas ietekmētu norēķinus un analītiku
• Datu neatbilstība nekontrolētas pārstartēšanas gadījumā
• Kaskādes ietekme uz norēķinu cikliem un ieņēmumu atskaitēm

• Noteicām pamatcēloni: neierobežoti vienlaicīgi vaicājumi izsmēla visus resursus
• Pārtraucām destruktīvākos vaicājumus un piemērojām tūlītēju slodzes ierobežošanu
• Optimizējām atmiņas konfigurāciju un materializētos skatus slodzes apstākļos
• Pievienojām reāllaika brīdinājumus par rindu dziļumu un resursu piesātinājumu

Datubāzu ekspluatācija bija pilnībā reaktīva. Inženieri pastāvīgi pārslēdzās starp jaunu funkciju izstrādi un reaģēšanu uz incidentiem, un nevienam nebija skaidras atbildības par PostgreSQL vai ClickHouse produkcijas vidē.

Izdegšana, lēna atgūšanās un atkārtoti incidenti, ko izraisīja tās pašas nenovērstās pamatproblēmas. Katra dežūru maiņa bija ugunsdzēšana.

Pārņēmām atbildību gan par PostgreSQL, gan ClickHouse produkcijas vidē. Pārorientējām fokusu no reaģēšanas uz prevenciju — ieviešot izmaiņu kontroli, paredzamus uzturēšanas logus un proaktīvu monitoringu abiem dzinējiem.

Platformas MySQL datubāze sasniedza savas robežas sarežģītiem analītiskiem vaicājumiem. Tika pieņemts lēmums migrēt uz PostgreSQL labākas vaicājumu plānošanas, natīvo replikācijas iespēju un ilgtermiņa uzturamības dēļ — bez jebkādiem pakalpojuma pārtraukumiem.

• Datu tipu nesaderība starp MySQL un PostgreSQL
• Lietojumprogrammas kļūmes shēmas pārveides laikā
• Dīkstāves risks pārslēgšanās laikā, kas ietekmētu aktīvos lietotājus
• Nemanāma datu novirze starp veco un jauno datubāzi

• Auditējām visas shēmas un novērsām nesaderības pirms migrācijas
• Veicām datu migrāciju ar reāllaika replikāciju, lai abas datubāzes būtu sinhronizētas
• Pārbaudījām vaicājumu ekvivalenci visos kritiskajos lietojumprogrammas ceļos
• Veicām pārslēgšanos zemas slodzes logā ar pārbaudītu atgriešanās iespēju

ClickHouse klasteris, kurā glabājās ~500 GB norēķinu datu (5+ gadu ieraksti), bija jāpārceļ no lokālās (bare-metal) infrastruktūras uz Kubernetes — pastāvīgas produkcijas slodzes apstākļos.

• Vēsturisko norēķinu ierakstu zudums
• Neatbilstoša analītika pārslēgšanās laikā
• Dīkstāve, kas ietekmē atskaites un ieņēmumus

• Uzbūvējām paralēlu ClickHouse klasteri Kubernetes vidē
• Izveidojām reāllaika datu replikāciju reālas slodzes apstākļos
• Veicām kontrolētu pārslēgšanos ar pilnu atgriešanās iespēju

MariaDB produkcijas sistēma (~200 GB), kas apstrādāja ~18 000 vaicājumu sekundē SaaS, spēļu un maksājumu slodzēs. Binlogi nekontrolēti pieauga, un bloķēšanas konflikti apturēja kritiskus rakstīšanas procesus — spiediens auga virzienā uz pilnu kļūmi.

• Nekontrolēta binlogu izaugsme → diska vietas izsīkums
• Bloķēšanas vētras, kas aptur kritiskos rakstīšanas ceļus
• Pilna datubāzes dīkstāve augstas slodzes apstākļos

• Identificējām un apturējām bloķējošos vaicājumus
• Stabilizējām binlogu uzvedību un rotāciju
• Samazinājām rakstīšanas slodzi ilgstošas noslodzes apstākļos
• Atjaunojām veselīgu replikāciju un sistēmas līdzsvaru

5 TB PostgreSQL klasteris (1 primārais + 2 replikas), kas apkalpo SaaS platformu. Dublējumkopijas tika veidotas pēc grafika — taču nekad nebija pārbaudītas. Neviens nezināja, vai tās patiešām atjaunotos.

• Bojātas vai nepilnīgas dublējumkopijas paliek nepamanītas
• Atjaunošanas process atsakās vissliktākajā brīdī
• Neatgriezenisks datu zudums bez atgūšanas iespējas

• Ieviesām automatizētu dublējumkopiju validāciju pēc regulāra grafika
• Veicām pilnus atjaunošanas testus, lai apstiprinātu atgūstamību
• Pievienojām monitoringu un brīdinājumus par dublējumkopiju integritāti

Produkcijas PostgreSQL sistēma pastāvīgas SaaS slodzes apstākļos. Standarta monitorings bija ieviests — taču problēmas tika atklātas tikai pēc tam, kad tās bija pamanījuši lietotāji. Brīdinājumi vai nu trūka, vai bija pārāk trokšņaini, lai uz tiem reaģētu.

• Slēpta veiktspējas pasliktināšanās paliek nepamanīta
• Pēkšņi incidenti bez brīdinājuma signāla
• Lēna reakcija uz kritiskām problēmām

• Izveidojām pielāgotus informācijas paneļus Grafana + Prometheus vidē
• Pievienojām redzamību lēniem vaicājumiem, bloķēšanas konfliktiem un replikācijas stāvoklim
• Ieviesām precīzus brīdinājumus — tikai nozīmīgi signāli, bez trokšņa

50 produkcijas datubāzes (katra no 10 GB līdz 32 TiB), kas darbojās pie 500–15 000 TPS slodzes, bija jāpārceļ no Google Cloud uz AWS. Jebkura dīkstāve tieši ietekmētu 300+ aktīvos partnerus un viņu galalietotājus.

• Platforma nepieejama migrācijas logā
• Datu bojāšanās vairākās lielās datubāzēs
• Replikācijas neatbilstība augstas TPS slodzes apstākļos
• Nav drošas atgriešanās iespējas, ja pārslēgšanās neizdodas

• Uzbūvējām pilnu AWS vidi no jauna
• Pārbaudījām replikāciju un failover katrai datubāzei reālas slodzes apstākļos
• Visu laiku uzturējām aktīvu momentānu atgriešanās iespēju
• Pabeidzām visas 50 pārslēgšanās bez neviena incidenta

Produkcijas datubāze, kas jau pārsniedza 2 TB, ar aktīvu darījumu datu un gadiem uzkrātu vēsturisko ierakstu (darījumi, žurnāli, norēķini) sajaukumu. Vaicājumu veiktspēja pasliktinājās, un dublējumkopiju veidošana kļuva nepanesami lēna.

• Turpmāka veiktspējas pasliktināšanās slodzes apstākļos
• Dublējumkopiju veidošana un atgūšana kļūst neuzticama šādā apjomā
• Pieaugošas glabāšanas un infrastruktūras izmaksas

• Arhivējām 1–1,5 TB vēsturisko datu, izmantojot pt-archiver
• Pārvietojām arhivētos datus uz S3 ar pilnu vaicājumu piekļuvi caur AWS Athena
• Produkcijas datubāzē atstājām tikai aktīvos datus

50 datubāzes, 30 lietotāji, vairākas vides (produkcija/izstrāde) un vairāki reģioni. Katra piekļuves izmaiņa tika veikta manuāli katrai datubāzei atsevišķi, bez centralizētas kontroles — sadrumstalots un kļūdām pakļauts process.

• Nepareizas vai pārmērīgas atļaujas paliek nepamanītas
• Drošības ievainojamības nekonsekventas piekļuves dēļ
• Lēna, manuāla lietotāju pievienošana un dzēšana

• Izveidojām centralizētu lietotāju pārvaldības sistēmu
• Automatizējām piekļuves piešķiršanu, izmantojot Ansible un AWS rīkus
• Standartizējām lomas un atļaujas visās vidēs un reģionos

Produkcijas MySQL sistēma pastāvīgas slodzes apstākļos. Standarta monitoringa paneļi bija ieviesti, taču tie sniedza pārāk maz redzamības par to, kas patiešām bija svarīgi — lēniem vaicājumiem, bloķēšanas konfliktiem un replikācijas stāvokli.

• Slēpta veiktspējas pasliktināšanās paliek nepamanīta
• Pēkšņi incidenti bez agrīna brīdinājuma
• Lēna reakcija uz kritiskām problēmām produkcijas vidē

• Izveidojām pielāgotus Grafana + Prometheus informācijas paneļus
• Pievienojām padziļinātu redzamību lēniem vaicājumiem, bloķēšanai un replikācijai
• Konfigurējām precīzus brīdinājumus bez trokšņa — tikai reālas problēmas

Uzņēmumam bija 10+ gadu vēsturisku darbības datu, taču nebija sistēmas, kas spētu tos izvaicāt mērogā. Novecojušas sistēmas nebija optimizētas analītikai, tāpēc lielu datu kopu vaicājumi bija lēni vai praktiski neiespējami.

• Vēsturiskie dati nav izmantojami biznesa lēmumu pieņemšanai
• Lēnas vai neizdevušās atskaites ietekmē darbību
• Zaudēti biznesa ieskati no gadiem uzkrātiem ierakstiem

• Izstrādājām un ieviesām ClickHouse datu noliktavu no jauna
• Strukturējām datus tieši analītiskām slodzēm
• Nodrošinājām efektīvu izvaicāšanu 10+ gadu ierakstiem
• Optimizējām glabāšanu un veiktspēju ilgtermiņa izaugsmei

Konkrētai nodaļai lielā globālā loģistikas uzņēmumā bija nepieciešamas neatkarīgas ekspertu konsultācijas par datubāzu arhitektūru. Iekšējās komandas bija augušas organiski, un datubāzu slānis bija uzkrājis tehnisko parādu — shēmas, kas bija veidotas agrākam mērogam, cīnījās ar pašreizējo caurlaidspēju.

• Novecojis shēmas dizains, kas neatbilst pašreizējiem datu apjomiem
• Vaicājumu veiktspēja pasliktinās, pieaugot darījumu caurlaidspējai
• Iekšējai komandai trūka specializētas DBA ekspertīzes

• Veicām pilnu nodaļas datubāzu slāņa arhitektūras pārskatu
• Identificējām indeksēšanas trūkumus, shēmas šaurās vietas un konfigurācijas problēmas
• Sagatavojām prioritizētu risinājumu plānu ar darba apjoma novērtējumiem
• Nodrošinājām praktisku atbalstu augstākās prioritātes labojumu ieviešanas laikā

Daudznomnieku ERP platformai ar vairāk nekā miljonu lietotāju bija nepieciešama konsekventa datubāzu uzticamība visiem nomniekiem. Jebkura veiktspējas pasliktināšanās datubāzu slānī izpaustos kā lēnas atbildes vai kļūdas plašai lietotāju bāzei, kas sadalīta pa desmitiem biznesa partneru.

• Daudznomnieku slodzes ar neparedzamiem vaicājumu modeļiem katram nomniekam
• Iekšējā komandā nebija specializētas DBA funkcijas
• Ierobežota redzamība lēniem vaicājumiem un bloķēšanas konfliktiem

• Ieviesām monitoringu, kas aptver lēno vaicājumu noteikšanu, bloķēšanas gaidīšanu un resursu izmantojumu
• Optimizējām ietekmīgākos lēnos vaicājumus lielākajiem nomniekiem
• Izveidojām uzturēšanas grafiku un izmaiņu kontroles procesu
• Nodrošinājām DBA dežūru pārklājumu produkcijas incidentiem

Fintech uzņēmumam bija jāmigrē MySQL datubāze uz jaunu vidi, nepārtraucot aktīvo darījumu apstrādi. Finanšu sistēmām ir nulles tolerance pret datu neatbilstībām, un jebkura dīkstāve migrācijas laikā tieši ietekmētu ieņēmumus un klientu uzticību.

• Darījumu datu zudums vai bojāšanās migrācijas laikā
• Dīkstāve, kas ietekmē aktīvās finanšu operācijas
• Replikācijas aizture, kas rada neatbilstību starp veco un jauno vidi

• Pielietojām to pašu migrācijas bez dīkstāves modeli, kas izmantots lielākām platformām
• Izveidojām reāllaika replikāciju starp veco un jauno MySQL vidi
• Pārbaudījām datu konsekvenci reālas darījumu slodzes apstākļos pirms pārslēgšanās
• Pabeidzām pārslēgšanos, visu laiku nodrošinot momentānu atgriešanās iespēju

Vairākus mēnešus ilgā patstāvīgā migrācijas mēģinājuma laikā komanda nejauši izdzēsa pusi no Oracle pamatpakalpojumiem. Datubāze pilnībā atteicās, atstājot uzņēmumu bezsaistē uz 2 dienām. AG Data tika pieaicināts glābt situāciju un pabeigt migrāciju.

• Turpinās biznesa darbības traucējumi bez atgūšanas termiņa
• Datu zudums no bojātajiem Oracle pakalpojumiem
• Nav skaidra ceļa uz plānoto mākoņa vidi

• Atjaunojām bojātos Oracle pakalpojumus un stabilizējām instanci
• Izveidojām mākoņa infrastruktūru un konfigurējām visus datubāzu pakalpojumus
• Izguvām veco datu izgāzumu (dump) un atjaunojām to jaunajā vidē
• Pabeidzām pilnu migrāciju un nodošanu nākamajā dienā