ഒരു എഞ്ചിനീയർ GitLab-ൻ്റെ പ്രൊഡക്ഷൻ ഡാറ്റാബേസ് ഇല്ലാതാക്കി. 300 ജിഗാബൈറ്റ്.
2017 ജനുവരി 31, 23:27 UTC: ഒരു GitLab എഞ്ചിനീയർ, ഒരു നീണ്ട രാത്രിയുടെ അവസാനം ഒരു തകർന്ന റെപ്ലിക്കയുമായി പോരാടുമ്പോൾ, db2-ന് പകരം db1-ൽ PostgreSQL ഡാറ്റാ ഡയറക്ടറി നീക്കം ചെയ്യുന്നു.
2017 ജനുവരി 31, 23:27 UTC: ഒരു GitLab എഞ്ചിനീയർ, ഒരു നീണ്ട രാത്രിയുടെ അവസാനം ഒരു തകർന്ന റെപ്ലിക്കയുമായി പോരാടുമ്പോൾ, db2-ന് പകരം db1-ൽ PostgreSQL ഡാറ്റാ ഡയറക്ടറി നീക്കം ചെയ്യുന്നു. db1 ആണ് പ്രൈമറി. GitLab.com-ൻ്റെ ഏകദേശം 300 GB ഡാറ്റാബേസ് ഒന്നോ രണ്ടോ നിമിഷങ്ങൾക്കുള്ളിൽ ഇല്ലാതായി, അഞ്ച് ബാക്കപ്പ്, റെപ്ലിക്കേഷൻ സംവിധാനങ്ങളിൽ ഒന്നും പ്രവർത്തിക്കുന്നില്ല. പോസ്റ്റ്‌മോർട്ടം: സ്പാം വർദ്ധനവ് മുതൽ തെറ്റായ ഹോസ്റ്റ്നാമം വരെയുള്ള ടൈംലൈൻ, pg_basebackup എന്തുകൊണ്ട് കുടുങ്ങിയതായി തോന്നി, pg_dump എന്തുകൊണ്ട് നിശബ്ദമായി പരാജയപ്പെടുന്നു (9.6 ഡാറ്റാബേസിൽ 9.2 ബൈനറികൾ, DMARC തടഞ്ഞ പരാജയ ഇമെയിലുകൾ), YouTube-ൽ തത്സമയം സ്ട്രീം ചെയ്ത 6 മണിക്കൂർ പഴക്കമുള്ള സ്റ്റേജിംഗ് സ്നാപ്പ്ഷോട്ടിൽ നിന്നുള്ള 18 മണിക്കൂർ റീസ്റ്റോർ, ആർക്കാണ് യഥാർത്ഥത്തിൽ കുറ്റം. പ്രതികരണത്തെക്കുറിച്ചുള്ള വിധി: SHIP IT.
എഴുതിയ പതിപ്പ് വായിക്കുക (ഇംഗ്ലീഷ്) ↗
ഈ വീഡിയോയിൽ ഉൾപ്പെടുന്ന കാര്യങ്ങൾ
- 2017 ജനുവരി 31: പ്രൈമറിയിലെ ഡാറ്റാ ഡയറക്ടറിയിൽ rm -Rvf; ~300 GB നീക്കം ചെയ്തു, 4.5 GB അവശേഷിക്കുന്നു
- 5 ബാക്കപ്പുകളിൽ 5-ഉം പരാജയപ്പെട്ടു: ഒഴിഞ്ഞ S3 ബക്കറ്റ് (pg_dump പതിപ്പ് പൊരുത്തക്കേട്), DB-യിൽ Azure സ്നാപ്പ്ഷോട്ടുകളില്ല, നശിപ്പിക്കപ്പെട്ട റെപ്ലിക്ക, വെബ്‌ഹൂക്കുകളില്ലാത്ത പ്രതിദിന LVM പകർപ്പ്
- ഫെബ്രുവരി 1, 18:00 UTC: 6 മണിക്കൂർ പഴക്കമുള്ള ഒരു മാനുവൽ സ്നാപ്പ്ഷോട്ടിൽ നിന്ന് GitLab.com തിരിച്ചെത്തി; ലൈവ് ഡോക്യുമെൻ്റ്, ലൈവ് സ്ട്രീം, പരിഹാര ലിസ്റ്റ് സഹിതമുള്ള കുറ്റപ്പെടുത്താത്ത പോസ്റ്റ്‌മോർട്ടം
വിവർത്തനം ചെയ്ത ട്രാൻസ്ക്രിപ്റ്റ്
യഥാർത്ഥ ഇംഗ്ലീഷ് ആഖ്യാനത്തിൽ നിന്ന് വിവർത്തനം ചെയ്തത്. ലഭ്യമായ ഓഡിയോയും അടിക്കുറിപ്പുകളും YouTube നിയന്ത്രിക്കുന്നു.
0:00 GitLab-ലെ ഒരു എഞ്ചിനീയർ തെറ്റായ ഡാറ്റാബേസ് സെർവറിൽ rm -rf പ്രവർത്തിപ്പിക്കുന്നു, അഞ്ഞൂറ് ജിഗാബൈറ്റ് GitLab ഡോട്ട് കോം ഒന്നോ രണ്ടോ നിമിഷങ്ങൾക്കുള്ളിൽ അപ്രത്യക്ഷമാകുന്നു, ഒരു ഹോസ്റ്റ്നാമം വായിക്കാൻ എടുക്കുന്ന സമയത്തോളം. 2017 ജനുവരി 31, രാത്രി 11:27. UTC. തങ്ങൾ അബദ്ധത്തിൽ പ്രൊഡക്ഷൻ ഡാറ്റ ഇല്ലാതാക്കിയെന്ന് GitLab ട്വീറ്റ് ചെയ്യുന്നു, അതിൻ്റെ ഇൻസിഡൻ്റ് കുറിപ്പുകൾ ഇൻ്റർനെറ്റിലേക്ക് തുറക്കുകയും YouTube-ൽ റിക്കവറി സ്ട്രീം ചെയ്യുകയും ചെയ്യുന്നു, പ്ലാറ്റ്‌ഫോമിലെ രണ്ടാമത്തെ തത്സമയ സ്ട്രീം. അടുത്ത ദിവസം, എഴുതിയത്: അഞ്ച് ബാക്കപ്പ് ടെക്നിക്കുകളിൽ,
0:25 ഒന്നും വിശ്വസനീയമായി പ്രവർത്തിക്കുന്നില്ല. അതെങ്ങനെ സംഭവിക്കുന്നു, അത് എന്തുകൊണ്ട് സാധ്യമാകുന്നു, യഥാർത്ഥത്തിൽ ആർക്കാണ് കുറ്റം. ഇതാണ് The Daily Diff, പോസ്റ്റ്‌മോർട്ടം. വൈകുന്നേരം 5:20: ഒരു എഞ്ചിനീയർ പ്രൊഡക്ഷൻ്റെ സ്നാപ്പ്ഷോട്ട് എടുക്കുന്നു സ്റ്റേജിംഗിൽ ഒരു ലോഡ് ബാലൻസർ പരിശോധിക്കാൻ. വൈകുന്നേരം 7: സ്പാം ഡാറ്റാബേസിനെ തകർക്കുന്നു, കൂടാതെ ഒരു GitLab ജീവനക്കാരനെ ദുരുപയോഗം ചെയ്തതിന് ഒരു ട്രോൾ റിപ്പോർട്ട് ചെയ്തതിനാൽ ഹാർഡ്-ഡിലീറ്റ് ചെയ്യുന്ന ഒരു ജോലി. രാത്രി 11: റെപ്ലിക്ക വളരെ പിന്നിലായി പോയതിനാൽ പ്രൈമറി ഇതിനകം
0:48 ആവശ്യമുള്ള ലോഗ് ഉപേക്ഷിച്ചു; റെപ്ലിക്ക നശിപ്പിച്ച് പ്രൈമറി വീണ്ടും പകർപ്പിയെടുക്കുക എന്നതാണ് ഏക പോംവഴി. pg_basebackup ഔട്ട്‌പുട്ടില്ലാതെ ഹാംഗ് ആകുന്നു. അത് യഥാർത്ഥത്തിൽ പ്രൈമറിക്കായി നിശബ്ദമായി കാത്തിരിക്കുകയാണ്; ആർക്കും അത് അറിയില്ല, റൺബുക്ക് അത് പറയുന്നില്ല. പതിനൊന്നുമണിക്ക് സൈൻ ഓഫ് ചെയ്യാൻ ഉദ്ദേശിച്ച എഞ്ചിനീയർ, ഒഴിഞ്ഞ ഡാറ്റാ ഡയറക്ടറിയാണ് പ്രശ്നമെന്ന് തീരുമാനിക്കുകയും അത് നീക്കം ചെയ്യുകയും ചെയ്യുന്നു. db1-ൽ. പ്രൈമറിയിൽ. ഒന്നോ രണ്ടോ നിമിഷങ്ങൾ കഴിഞ്ഞ് അവൻ ശ്രദ്ധിക്കുന്നു; ഏകദേശം മുന്നൂറ് ജിഗാബൈറ്റിൽ,
1:11 4.5 ബാക്കിയായി. ബാക്കപ്പുകൾ. ഒന്ന്: pg_dump S3-ലേക്ക്, ദിവസേന. ബക്കറ്റ് ശൂന്യമാണ്. ക്രോൺ ജോലി ഡാറ്റാബേസ് ഇല്ലാത്ത ഒരു ആപ്പ് സെർവറിലാണ് പ്രവർത്തിക്കുന്നത്, അതിനാൽ പാക്കേജ് ഒരു 9.6 ഡാറ്റാബേസിനായി PostgreSQL 9.2 ബൈനറികൾ തിരഞ്ഞെടുക്കുന്നു, പരാജയപ്പെടുന്നു, കൂടാതെ DMARC ഇല്ലാത്തതിനാൽ പരാജയം ഇമെയിൽ ബൗൺസ് ആകുന്നു. രണ്ട്: Azure ഡിസ്ക് സ്നാപ്പ്ഷോട്ടുകൾ, ഫയൽ സെർവറുകൾക്കായി പ്രവർത്തനക്ഷമമാക്കിയിരിക്കുന്നു, ഡാറ്റാബേസുകൾക്കല്ല.
1:32 മൂന്ന്: റെപ്ലിക്ക, ഒരു മണിക്കൂർ മുമ്പ് മനഃപൂർവം നശിപ്പിച്ചു. നാല്: പ്രതിദിന സ്നാപ്പ്ഷോട്ട്, 24 മണിക്കൂർ പഴക്കമുള്ളത്, എല്ലാ വെബ്‌ഹൂക്കുകളും സ്റ്റേജിംഗ് സമന്വയം വഴി നീക്കം ചെയ്യപ്പെട്ടു. അഞ്ച്: 5:20-ലെ മാനുവൽ സ്നാപ്പ്ഷോട്ട്, ബന്ധമില്ലാത്ത ഒരു പരിശോധനയ്ക്കായി. അതാണ് വിജയിച്ചത്. റീസ്റ്റോർ ചെയ്യുക എന്നാൽ സ്റ്റേജിംഗ് ഡിസ്ക് Azure-ൻ്റെ വിലകുറഞ്ഞ സ്റ്റോറേജിലൂടെ സെക്കൻഡിൽ അറുപത് മെഗാബിറ്റ് വേഗതയിൽ പ്രൊഡക്ഷനിലേക്ക് പകർത്തുക എന്നതാണ്: പതിനെട്ട് മണിക്കൂർ. GitLab ഡോട്ട് കോം ഫെബ്രുവരി 1-ന് വൈകുന്നേരം ആറിന് തിരിച്ചെത്തുന്നു. UTC, ആറ് മണിക്കൂർ പഴക്കമുള്ള ഡാറ്റയുമായി.
1:58 git blame: ഒരു ക്യാരക്ടർ വ്യത്യാസമുള്ള രണ്ട് ഹോസ്റ്റ്നാമങ്ങൾ, ആരും ഇതുവരെ റീസ്റ്റോർ ചെയ്യാത്ത അഞ്ച് ബാക്കപ്പ് സിസ്റ്റങ്ങൾ. എഞ്ചിനീയറല്ല. സിഇഒ ഒപ്പിട്ട പോസ്റ്റ്‌മോർട്ടം, അദ്ദേഹത്തെ അജ്ഞാതനായി നിലനിർത്തുന്നു, പ്രൊഡക്ഷൻ പ്രോംപ്റ്റ് ചുവപ്പ് നിറത്തിൽ ആക്കുന്നു, ഡാറ്റാ ഡ്യൂറബിലിറ്റിക്ക് ഒരു ഉടമയെ നൽകുന്നു, കാരണം അതുവരെ അതിന് ഉടമയുണ്ടായിരുന്നില്ല. ബ്ലാസ്റ്റ് റേഡിയസ്: പതിനെട്ട് മണിക്കൂർ ഡൗൺടൈം, ആറ് മണിക്കൂർ ഡാറ്റ നഷ്ടപ്പെട്ടു, ഏകദേശം അയ്യായിരം പ്രോജക്റ്റുകൾ, അയ്യായിരം കമൻ്റുകൾ,
2:18 എഴുന്നൂറ് പുതിയ ഉപയോക്താക്കൾ, ഒരു പ്രോഗ്രസ് ബാർ കാണുന്ന അയ്യായിരം ആളുകൾ. ഹാക്കർ ന്യൂസ് ലൈവ് ഡോക്കിന് 1,162 പോയിൻ്റുകൾ നൽകുകയും അവരോട് ഒരു വരി തിരികെ ഉദ്ധരിക്കുകയും ചെയ്യുന്നു: അഞ്ച് ബാക്കപ്പുകളിൽ ഒന്നും പ്രവർത്തിച്ചില്ല. വിധി, പോസ്റ്റ്‌മോർട്ടം: പ്രതികരണത്തിൽ, SHIP IT. അവർ സംഭവം പരസ്യമായി നടത്തുന്നു, പ്രോസസ്സിനെ കുറ്റപ്പെടുത്തുന്നു, കൂടാതെ ഇഷ്യു നമ്പറുകളോടുകൂടിയ പരിഹാര ലിസ്റ്റ് പ്രസിദ്ധീകരിക്കുന്നു. തിങ്കളാഴ്ചത്തെ നടപടി: ഒരു ബാക്കപ്പ് റീസ്റ്റോർ ചെയ്യുക. നിങ്ങൾ അത് ഇതുവരെ റീസ്റ്റോർ ചെയ്തിട്ടില്ലെങ്കിൽ, നിങ്ങൾക്ക് ഒന്നുണ്ടായിരുന്നില്ല.
2:42 നിങ്ങൾക്ക് ഇപ്പോഴും സംസാരിക്കാൻ അനുവാദമില്ലാത്ത സംഭവം എനിക്കയക്കുക, കമൻ്റുകളിൽ, അല്ലെങ്കിൽ the 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
