એક એન્જિનિયરે ગિટલેબનો પ્રોડક્શન ડેટાબેઝ ડિલીટ કર્યો. 300 ગીગાબાઇટ્સ.
31 જાન્યુઆરી, 2017, 23:27 UTC: ગિટલેબના એક એન્જિનિયરે, લાંબી રાત પૂરી થતાં એક તૂટેલા રેપ્લિકાને સુધારતી વખતે, db2 ને બદલે db1 પર PostgreSQL ડેટા ડિરેક્ટરી કાઢી નાખી.
31 જાન્યુઆરી, 2017, 23:27 UTC: ગિટલેબના એક એન્જિનિયરે, લાંબી રાત પૂરી થતાં એક તૂટેલા રેપ્લિકાને સુધારતી વખતે, db2 ને બદલે db1 પર PostgreSQL ડેટા ડિરેક્ટરી કાઢી નાખી. db1 એ પ્રાથમિક છે. GitLab.com નો લગભગ 300 GB ડેટાબેઝ એક કે બે સેકન્ડમાં ગાયબ થઈ ગયો, અને પાંચ બેકઅપ અને રેપ્લિકેશન મિકેનિઝમ્સમાંથી, એક પણ કામ કરતું ન હતું. પોસ્ટમોર્ટમ: સ્પામ સ્પાઇકથી ખોટા હોસ્ટનામ સુધીની સમયરેખા, pg_basebackup શા માટે અટકેલું લાગતું હતું, pg_dump શા માટે શાંતિપૂર્વક નિષ્ફળ થઈ રહ્યું હતું (9.6 ડેટાબેઝ પર 9.2 બાઈનરીઝ, DMARC દ્વારા બાઉન્સ થયેલ નિષ્ફળતાના ઇમેઇલ્સ), YouTube પર લાઇવ સ્ટ્રીમ થયેલ 6 કલાક જૂના સ્ટેજીંગ સ્નેપશોટમાંથી 18 કલાકનો રીસ્ટોર, અને ખરેખર કોને દોષ મળે છે. પ્રતિસાદ પરનો નિર્ણય: SHIP IT.
લખેલી આવૃત્તિ વાંચો (અંગ્રેજી) ↗
આ વીડિયોમાં શું આવરી લેવામાં આવ્યું છે
- 31 જાન્યુઆરી, 2017: પ્રાથમિક ડેટા ડિરેક્ટરી પર rm -Rvf; ~300 GB કાઢી નાખવામાં આવ્યા, 4.5 GB બાકી રહ્યા
- 5 માંથી 5 બેકઅપ નિષ્ફળ: ખાલી S3 બકેટ (pg_dump વર્ઝન મેળ ખાતું નથી), DB પર કોઈ Azure સ્નેપશોટ્સ નથી, વાઇપ થયેલ રેપ્લિકા, વેબહૂક્સ વિના દૈનિક LVM કોપી
- 1 ફેબ્રુઆરી, 18:00 UTC: GitLab.com 6 કલાક જૂના મેન્યુઅલ સ્નેપશોટમાંથી પાછું આવ્યું; લાઇવ ડોક, લાઇવ સ્ટ્રીમ, ફિક્સ લિસ્ટ સાથે દોષરહિત પોસ્ટમોર્ટમ
અનુવાદિત ટ્રાન્સક્રિપ્ટ
મૂળ અંગ્રેજી કથામાંથી અનુવાદિત. ઉપલબ્ધ ઑડિઓ અને કૅપ્શન્સ YouTube દ્વારા નિયંત્રિત થાય છે.
0:00 GitLab માં એક એન્જિનિયર ખોટા ડેટાબેઝ સર્વર પર rm -rf ચલાવે છે, અને GitLab ડોટ કોમના ત્રણસો ગીગાબાઇટ્સ એક કે બે સેકન્ડમાં અદૃશ્ય થઈ જાય છે, લગભગ જેટલો સમય હોસ્ટનામ વાંચવામાં લાગે છે. 31 જાન્યુઆરી, 2017, રાત્રે 11:27. UTC. GitLab ટ્વીટ કરે છે કે તેણે ભૂલથી પ્રોડક્શન ડેટા ડિલીટ કર્યો છે, તેની ઘટનાની નોંધો ઇન્ટરનેટ પર ખોલે છે, અને YouTube પર રિકવરી સ્ટ્રીમ કરે છે, પ્લેટફોર્મ પર નંબર બે લાઇવ સ્ટ્રીમ. બીજા દિવસે, લેખિતમાં: પાંચ બેકઅપ તકનીકોમાંથી,
0:25 એક પણ વિશ્વસનીય રીતે કામ કરી રહ્યું નથી. તે કેવી રીતે થાય છે, શા માટે શક્ય છે, અને ખરેખર કોને દોષ મળે છે. આ ધ ડેઇલી ડિફ છે, પોસ્ટમોર્ટમ. સાંજે 5:20: એક એન્જિનિયર પ્રોડક્શનનો સ્નેપશોટ લે છે સ્ટેજીંગમાં લોડ બેલેન્સરનું પરીક્ષણ કરવા માટે. સાંજે 7:00: સ્પામ ડેટાબેઝ પર હુમલો કરે છે, ઉપરાંત GitLab કર્મચારીને હાર્ડ-ડિલીટ કરતું એક કાર્ય દુર્વ્યવહાર માટે એક ટ્રોલ દ્વારા જાણ કરવામાં આવી. રાત્રે 11:00: રેપ્લિકા એટલું પાછળ રહી જાય છે કે પ્રાથમિકે પહેલેથી જ કાઢી નાખ્યું છે
0:48 તેને જોઈતો લોગ; એકમાત્ર ઉપાય એ છે કે રેપ્લિકાને વાઇપ કરો અને પ્રાથમિકની નકલ કરો ફરીથી. pg_basebackup કોઈ આઉટપુટ વિના અટકી જાય છે. તે ખરેખર, શાંતિપૂર્વક, પ્રાથમિકની રાહ જોઈ રહ્યું છે; કોઈને તે ખબર નથી, અને રનબુકમાં તે કહેવામાં આવ્યું નથી. એન્જિનિયર, જે અગિયાર વાગ્યે સાઇન ઓફ કરવાનો હતો, તે નક્કી કરે છે કે ખાલી ડેટા ડિરેક્ટરી સમસ્યા છે અને તેને દૂર કરે છે. db1 પર. પ્રાથમિક. તે એક કે બે સેકન્ડ પછી ધ્યાન આપે છે; લગભગ ત્રણસો ગીગાબાઇટ્સમાંથી,
1:11 4.5 બાકી રહે છે. બેકઅપ્સ. એક: S3 પર pg_dump, દૈનિક. બકેટ ખાલી છે. ક્ર્રોન જોબ કોઈ ડેટાબેઝ વિના એપ સર્વર પર ચાલે છે, તેથી પેકેજ પસંદ કરે છે 9.6 ડેટાબેઝ માટે PostgreSQL 9.2 બાઈનરીઝ, નિષ્ફળ જાય છે, અને ઇમેઇલ કરે છે નિષ્ફળતા, જે DMARC ખૂટવાના કારણે બાઉન્સ થાય છે. બે: Azure ડિસ્ક સ્નેપશોટ્સ, ફાઇલ સર્વર્સ માટે સક્ષમ, ડેટાબેઝ માટે નહીં.
1:32 ત્રણ: રેપ્લિકા, એક કલાક પહેલા હેતુપૂર્વક વાઇપ કરવામાં આવ્યું. ચાર: દૈનિક સ્નેપશોટ, 24 કલાક જૂનો, દરેક વેબહૂક દ્વારા કાઢી નાખવામાં આવ્યું સ્ટેજીંગ સિંક. પાંચ: 5:20 નો મેન્યુઅલ સ્નેપશોટ, એક અસંબંધિત પરીક્ષણ માટે. તે એક જીતે છે. રીસ્ટોર કરવાનો અર્થ એ છે કે સ્ટેજીંગ ડિસ્કને Azure ના સસ્તા પર પ્રોડક્શનમાં પાછું કોપી કરવું સાઠ મેગાબિટ પ્રતિ સેકન્ડ પર સ્ટોરેજ: અઢાર કલાક. GitLab ડોટ કોમ 1 ફેબ્રુઆરીએ સાંજે છ વાગ્યે પાછું આવે છે UTC, છ કલાકનો ડેટા જૂનો.
1:58 ગીટ બ્લેમ: બે હોસ્ટનામ એક અક્ષરના અંતરે, અને પાંચ બેકઅપ સિસ્ટમ્સ કોઈએ ક્યારેય તેમાંથી રીસ્ટોર કર્યું નથી. એન્જિનિયર નહીં. સીઈઓ દ્વારા સહી કરાયેલ પોસ્ટમોર્ટમ, તેને અનામી રાખે છે, પ્રોડક્શન પ્રોમ્પ્ટને લાલ રંગ આપે છે, અને ડેટાની ટકાઉપણુંનો માલિક આપે છે, કારણ કે અત્યાર સુધી તેની પાસે કોઈ નહોતું. બ્લાસ્ટ ત્રિજ્યા: અઢાર કલાક ડાઉન, છ કલાકનો ડેટા ગાયબ, આશરે પાંચ હજાર પ્રોજેક્ટ્સ, પાંચ હજાર ટિપ્પણીઓ,
2:18 સાતસો નવા વપરાશકર્તાઓ, અને પાંચ હજાર લોકો પ્રોગ્રેસ બાર જોઈ રહ્યા છે. હેકર ન્યૂઝ લાઇવ ડોકને 1,162 પોઈન્ટ આપે છે અને એકને ટાંકવામાં આવ્યું છે તેમને પાછળની લાઇન: પાંચ બેકઅપમાંથી, એક પણ નહીં. ચુકાદો, પોસ્ટમોર્ટમ: પ્રતિસાદ પર, ship it. તેઓ ઘટનાને જાહેરમાં ચલાવે છે, પ્રક્રિયાને દોષ આપે છે, અને ફિક્સ લિસ્ટ પ્રકાશિત કરે છે ઇશ્યૂ નંબરો સાથે. સોમવારની કાર્યવાહી: બેકઅપ રીસ્ટોર કરો. જો તમે તેને ક્યારેય રીસ્ટોર કર્યું નથી, તો તમારી પાસે એક નથી.
2:42 મને તે ઘટના મોકલો જેના વિશે તમને હજી પણ વાત કરવાની મંજૂરી નથી, ટિપ્પણીઓમાં, અથવા daily diff dot dev પર. અને આજનો તફાવત આ છે. હું Axrisi થી નિકો છું. જવાબદારીપૂર્વક મર્જ કરો.
સ્ત્રોતો
- GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
- GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
- @gitlabstatus, "We accidentally deleted production data…"twitter.com
- @gitlabstatus, emergency maintenance noticetwitter.com
- Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
- Hacker News, the postmortem thread (377 points)news.ycombinator.com



