Dublējuma atjaunošanas gadījuma izpēte: atgriežoties 6 stundas atpakaļ
Publicēts 2026. gada 10. jūlijā
02:14 UTC interneta veikals pārtrauca ierakstīt pasūtījumus datubāzē. Līdz 02:19 vietne joprojām apkalpoja kešatmiņā saglabātās lapas, taču norēķināšanās jau bija kļuvusi par fikciju. Šī dublējuma atjaunošanas gadījuma izpēte apraksta, kas notika tālāk produkcijas VPS mazam e-komercijas uzņēmumam, ko mēs atjaunojām, ko mēs neatjaunojām akli un kāpēc pakalpojums atkal bija stabils vēl pirms saullēkta.
Klientam bija samērā standarta steks augošam tiešsaistes veikalam - Nginx, PHP-FPM, MariaDB, Redis un vadības panelis, ko izmantoja divi darbinieki bez sistēmadministratora pieredzes. Datplūsma nebija milzīga, taču laiks bija sāpīgs. Izpārdošanas kampaņa bija palielinājusi pasūtījumu apjomu, datubāzes ieraksti sasniedza maksimumu, un glabātuves problēma failu sistēmas līmenī sāka bojāt aktīvās datubāzes tabulas. Ne gluži Holivudas stila drāma, bet pietiekami nopietni, lai katra minūte būtu svarīga.
Pirmais uzdevums nebija atjaunošana. Pirmais uzdevums bija apturēt bojājumu izplatīšanos. Mēs ieslēdzām lietotni apkopes režīmā, saglabājām pašreizējo diska stāvokli pārskatīšanai un pārbaudījām, vai replikācija, momentuzņēmumi vai loģiskie izmetumi mums sniedz tīrāko atjaunošanas punktu. Tas ir svarīgāk, nekā cilvēkiem patīk atzīt. Ātra atjaunošana ir laba. Ātra atjaunošana uz bojātiem datiem ir tikai ātra vilšanās.
