Steidzami vajag DBA? Izlasiet šo, pirms kaut ko aiztiekat

Ja lasāt šo, jo Google ierakstījāt "steidzami vajag DBA" vai "urgent DBA", datubāze, visticamāk, deg tieši tagad. Tāpēc ievadu izlaidīsim. Ārkārtas DBA atbalstu ir vērts saukt, kad jūsu komanda vairs netiek uz priekšu, un vislielākā vērtība tam ir tad, ja līdz palīdzības ierašanās brīdim situācija nav padarīta sliktāka. Par šo otro daļu ir šī lapa.

Vispirms: apstājieties. Nedariet šīs lietas

Datubāzes dīkstāve ir slikti. Daudz sliktāk kļūst tad, ja stundā pirms palīdzības ierašanās kāds spiediena apstākļos izmēģina forumā izlasītu padomu. PostgreSQL kopienas wiki to saka tieši: "People often destroy potentially recoverable data by trying to repair it" (cilvēki bieži iznīcina atgūstamus datus, mēģinot tos salabot). Pirms jebko darāt, izslēdziet šo:

• Nedzēsiet failus no datu direktorijas, lai atbrīvotu vietu diskā. Ne pg_wal, ne pg_xact, ne "veci izskatīgus" failus. PostgreSQL šie faili ir pati datubāze. MySQL nekad nedzēsiet bināros žurnālus ar rm; izmantojiet PURGE BINARY LOGS un tikai pēc tam, kad pārbaudīts, kuri žurnāli vēl vajadzīgi replikām (MySQL dokumentācija).
• Nepalaidiet pg_resetwal tikai tāpēc, ka to ieteica kāds blogs. Oficiālā dokumentācija to sauc par pēdējo līdzekli un brīdina, ka pēc tam datubāzē var būt nekonsekventi dati. Tas var palīdzēt serverim startēt. Tas var arī klusi pazaudēt apstiprinātas transakcijas.
• Nepārstartējiet serveri atkal un atkal cerībā, ka nākamreiz tas startēs. Katrs mēģinājums var pārrakstīt vajadzīgos žurnālus, un pilna diska gadījumā stāvoklis var pasliktināties.
• Nepārslēdzieties uz repliku akli. Ja paaugstina repliku, kas atpaliek par stundām, vai to dara, kamēr vecais primārais vēl pieņem ierakstus, rodas divas atšķirīgas datubāzes. Vēlāk tās apvienot ir sāpīgi.
• Neatjaunojiet rezerves kopiju virsū vienīgajai bojātās datubāzes kopijai. Atjaunojiet citur. Bojātajā datubāzē var būt pēdējo stundu dati, kuru rezerves kopijā nav.
• Nepalaidiet VACUUM FULL, REPAIR TABLE vai masveida DELETE kā veiktspējas labojumu incidenta vidū. Tie ņem smagas slēdzenes vai rada daudz ierakstu, un tas ir pretējais tam, kas vajadzīgs pārslogotam serverim.

Nākamās 30 minūtes: kas patiešām palīdz

1. Apturiet asiņošanu, nevis datubāzi. Apturiet pakešuzdevumus, cron uzdevumus, ETL un visu pārējo, kas nav būtisks. Ja iespējams, ieslēdziet lietotnē apkopes režīmu. Mazāka slodze nopērk laiku.
2. Ja ir aizdomas par bojājumu, vispirms nokopējiet failus. PostgreSQL wiki iesaka apturēt serveri un pirms jebkāda labošanas mēģinājuma izveidot visas datu direktorijas kopiju failu sistēmas līmenī (PostgreSQL wiki: Corruption). Tā pati loģika attiecas uz jebkuru dzinēju. Der arī diska vai mākoņa sējuma momentuzņēmums. Šī kopija ir jūsu "atsaukt" poga.
3. Pierakstiet notikumu hronoloģiju. Kad tas sākās? Kas mainījās pēdējās 24 stundās: izvietošana, migrācija, konfigurācijas izmaiņas, jauns indekss, OS atjauninājums, mākoņa apkope? Ļoti bieži cēlonis ir kaut kur šajā sarakstā.
4. Saglabājiet pierādījumus. Datubāzes kļūdu žurnālu, pēdējos monitoringa ekrānuzņēmumus (CPU, disks, savienojumi, replikācijas nobīde), precīzu kļūdas tekstu, ko redz lietotāji vai lietotne. Kopējiet, nepārstāstiet.
5. Izvēlieties vienu cilvēku saziņai ar ārpasauli. Inženieriem, kas labo problēmu, nevajadzētu ik pēc piecām minūtēm atbildēt uz jautājumu "vai jau strādā?".

Situācijas, kad DBA tiešām vajag nekavējoties

Ne katram incidentam vajag ārēju palīdzību. Izvietošanu, kas salauza vienu vaicājumu, izstrādātāji parasti var atritināt paši. Šie ir gadījumi, kad gaidīšana parasti izmaksā vairāk nekā zvans:

• primārais serveris nestartē vai startē un atkal avarē;
• kļūdas, kurās minēts bojājums, nederīgas lapas, kontrolsummas vai "could not read block";
• datubāzes serverim pilns disks, un neviens nav pārliecināts, ko drīkst dzēst;
• replikācija salauzta un automātiskā pārslēgšanās neizdevās, vai nav skaidrs, kurā mezglā ir jaunākie dati;
• PostgreSQL atsakās pieņemt ierakstus ar transakciju ID pārpildes (wraparound) paziņojumu;
• jāatjauno dati, bet rezerves kopijas neviens nekad nav pārbaudījis;
• drošības incidenta pazīmes: nezināmi konti, dzēstas tabulas, izspiešanas ziņojumi.

Par rezerves kopijām jābūt godīgiem. Ja atjaunošana nekad nav izmēģināta, jūs īsti nezināt, vai jums ir rezerves kopija. Par to rakstījām rakstā datubāzu rezerves kopiju un atjaunošanas testēšana, bet dīkstāves laikā noderīgais jautājums ir vienkāršāks: kur ir rezerves kopijas, cik veca ir jaunākā un vai kāds kādreiz ir no tās atjaunojis?

Kā nodot situāciju steidzamam DBA, nezaudējot stundu

Kad ārējs DBA pievienojas incidenta vidū, pirmais laiks aiziet piekļuves un konteksta iegūšanai. To var ievērojami saīsināt, ja līdz sarunas beigām ir sagatavots šis:

• Dzinējs un versija (PostgreSQL 16.4, MySQL 8.0, MariaDB, SQL Server, Oracle...) un kur tas darbojas: savā aparatūrā, VM, RDS, Aurora, Cloud SQL, Kubernetes.
• Topoloģija: primārais, replikas, savienojumu pūli, slodzes līdzsvarotāji, pārslēgšanās rīki (Patroni, Orchestrator, mākoņa pārvaldīta).
• Piekļuve: pagaidu konts, VPN vai bastion hosta dati un kas to apstiprina. Kur iespējams, izmantojiet MFA un pēc tam piekļuvi atsauciet.
• Hronoloģija un pierādījumi no iepriekšējās sadaļas.
• Rezerves kopiju atrašanās vieta un vecums.
• Cilvēks, kas var pieņemt lēmumus: "vai drīkstam zaudēt pēdējo 10 minūšu datus, lai būtu tiešsaistē tagad?" ir biznesa lēmums, nevis DBA lēmums. Kādam ar pilnvarām jābūt sasniedzamam.

Kā izvēlēties ārkārtas DBA atbalstu (ideālā gadījumā pirms tas vajadzīgs)

Meklēšanas rezultāti pēc "emergency DBA" ir pilni ar aģentūrām, kas jūsu pieteikumu pieņems trijos naktī un nodos kādam deviņos no rīta. Uzdodiet šos jautājumus tieši:

1. Kas atbild uz zvanu? Pieredzējis DBA vai dispečers, kas atver pieteikumu?
2. Kāds ir reālais reakcijas laiks kritiskam incidentam naktī un brīvdienās? Saņemiet to rakstiski.
3. Kurus dzinējus viņi tiešām uztur produkcijā? "Mēs atbalstām visas datubāzes" parasti nozīmē "vienu mēs atbalstām labi".
4. Kā tiek apmaksāts ārkārtas darbs? Pa stundām, fiksēta maksa par incidentu vai iekļauts abonementā? Izvairieties no pārsteigumiem brīdī, kad visgrūtāk vienoties.
5. Vai pēc tam saņemsiet rakstisku atskaiti: pamatcēlonis, kas tika mainīts, kas jāizlabo, lai tas neatkārtotos?

Labākais ārkārtas DBA ir tas, kurš jau pazīst jūsu sistēmu. Pakalpojumu sniedzējs, kuram jūsu topoloģija ir dokumentēta un piekļuve saskaņota iepriekš, var sākt labot dažu minūšu laikā, nevis sākt ar jautājumu "ko jūs izmantojat?". Kā tas izskatās no iekšpuses, aprakstīts rakstā kā patiesībā izskatās 15 minūšu reaģēšana uz datubāzes incidentu.

Pēc ugunsgrēka

Kad datubāze atkal darbojas, kārdinājums ir doties tālāk. Nedariet to, vismaz ne uzreiz. Pierakstiet hronoloģiju, kamēr cilvēki to vēl atceras. Novērsiet monitoringa robu, kura dēļ problēma auga nepamanīta. Pārbaudiet atjaunošanu. Un izlemiet, vai nākamreiz atkal gribat divos naktī meklēt DBA. Kādam ražošanas uzņēmumam mēs no avarējuša lokālā Oracle servera bez skaidra atkopšanas ceļa nonācām līdz atkoptai sistēmai mākoņa infrastruktūrā 24 stundu laikā kopš pirmā kontakta (pieredzes stāsts). Tas bija iespējams, jo komanda sazinājās laikus un nebija vispirms mēģinājusi neko "salabot".