Gitlab «лежит», база уничтожена (восстанавливается)
Вчера, 31 января, сервис Gitlab случайно уничтожил свою продакшн базу данных (сами гит-репозитории не пострадали).
Дело было примерно так.
По какой-то причине стала отставать hot-standby реплика базы (PostgreSQL) (реплика была единственная). Сотрудник gitlab какое-то время пытался повлиять на ситуацию различными настройками и т.д, потом решил всё стереть и налить реплику заново. Пытался стереть папку с данными на реплике, но перепутал сервера и стёр на мастере (сделал rm -rf на db1.cluster.gitlab.com вместо db2.cluster.gitlab.com)
Интересно, что в системе было 5 разных видов бекапов/реплик, и ничего из этого не сработало. Был лишь LVM snapshot, сделанный случайно за 6 часов до падения.
Вот, привожу сокращенную цитату из их документа:
Обнаруженные проблемы:
1) LVM snapshots are by default only taken once every 24 hours.
2) Regular backups seem to also only be taken once per 24 hours, though YP has not yet been able to figure out where they are stored.
3) Disk snapshots in Azure are enabled for the NFS server, but not for the DB servers.
4) The synchronisation process removes webhooks once it has synchronised data to staging. Unless we can pull these from a regular backup from the past 24 hours they will be lost
5) The replication procedure is super fragile, prone to error, relies on a handful of random shell scripts, and is badly documented
6) Our backups to S3 apparently don«t work either: the bucket is empty
7) We don«t have solid alerting/paging for when backups fails, we are seeing this in the dev host too now.
Таким образом, делают вывод gitlab, из 5 бекапов/техник репликации ничего не сработало надежно и как надо => поэтому идет восстановление из случайно сделанного 6-часового бекапа
Вот полный текст документа:
docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
Комментарии (1)
impwx
1 февраля 2017 в 17:46
0↑
↓
Ох не завидую я товарищу…Бегемот.jpg
