ಒಬ್ಬ ಇಂಜಿನಿಯರ್ GitLab ನ ಉತ್ಪಾದನಾ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಳಿಸಿದ್ದಾರೆ. 300 ಗಿಗಾಬೈಟ್ಗಳು.
ಜನವರಿ 31, 2017, 23:27 UTC: GitLab ಇಂಜಿನಿಯರ್, ಸುದೀರ್ಘ ರಾತ್ರಿ ಕೊನೆಯಲ್ಲಿ ಮುರಿದ ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ಹೋರಾಡುತ್ತಾ, db2 ಬದಲಿಗೆ db1 ನಲ್ಲಿ PostgreSQL ಡೇಟಾ ಡೈರೆಕ್ಟರಿಯನ್ನು ತೆಗೆದುಹಾಕಿದ್ದಾರೆ.
ಜನವರಿ 31, 2017, 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.
ಲಿಖಿತ ಆವೃತ್ತಿಯನ್ನು ಓದಿ (ಇಂಗ್ಲಿಷ್) ↗
ಈ ವೀಡಿಯೊ ಏನನ್ನು ಒಳಗೊಂಡಿದೆ
- ಜನ 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.com ಒಂದೆರಡು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ, ಹೋಸ್ಟ್ಹೆಸರನ್ನು ಓದಲು ಬೇಕಾದ ಸಮಯದ ಬಗ್ಗೆ. ಜನವರಿ 31, 2017, ರಾತ್ರಿ 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.com ಫೆಬ್ರವರಿ 1 ರಂದು ಸಂಜೆ ಆರು ಗಂಟೆಗೆ ಮರಳಿದೆ. UTC, ಆರು ಗಂಟೆಗಳ ಹಳೆಯ ಡೇಟಾ.
1:58 git blame: ಒಂದು ಅಕ್ಷರ ಅಂತರವಿರುವ ಎರಡು ಹೋಸ್ಟ್ಹೆಸರ್ಗಳು, ಮತ್ತು ಐದು ಬ್ಯಾಕಪ್ ವ್ಯವಸ್ಥೆಗಳು ಯಾರೂ ಎಂದಿಗೂ ಮರುಸ್ಥಾಪಿಸಿಲ್ಲ. ಇಂಜಿನಿಯರ್ ಅಲ್ಲ. CEO ಸಹಿ ಮಾಡಿದ ಪೋಸ್ಟ್ಮಾರ್ಟಮ್, ಅವರನ್ನು ಅನಾಮಧೇಯರಾಗಿರಿಸುತ್ತದೆ, ಉತ್ಪಾದನಾ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಕೆಂಪು ಬಣ್ಣದಲ್ಲಿರಿಸುತ್ತದೆ, ಮತ್ತು ಡೇಟಾ ಬಾಳಿಕೆಗೆ ಮಾಲೀಕರನ್ನು ನೀಡುತ್ತದೆ, ಏಕೆಂದರೆ ಇಲ್ಲಿಯವರೆಗೆ ಅದಕ್ಕೆ ಯಾರೂ ಇರಲಿಲ್ಲ. ಬ್ಲಾಸ್ಟ್ ತ್ರಿಜ್ಯ: ಹದಿನೆಂಟು ಗಂಟೆಗಳ ಡೌನ್, ಆರು ಗಂಟೆಗಳ ಡೇಟಾ ಇಲ್ಲವಾಗಿದೆ, ಸುಮಾರು ಐದು ಸಾವಿರ ಯೋಜನೆಗಳು, ಐದು ಸಾವಿರ ಕಾಮೆಂಟ್ಗಳು,
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



