Gitlab «лежит», база уничтожена (восстанавливается)

    image Вчера, 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-часового бекапа

    Вот полный текст документа
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 164
    • +12
      Ох не завидую я товарищу…

      Бегемот.jpg
      • +5
        Он обрёл неоценимый опыт.
        • +40
          Ну как опыт…

          • +35
            image
            • +2
              Как сообщают представители GitLab, «кто-то просто совершил ошибку, и не будет уволен».
              • +11
                Всё-таки это ошибка всей команды:
                > из 5 бекапов/техник репликации ничего не сработало
                • +12
                  image
                  • +1
                    У семи нянек дитя без глазу.

                    Каждая думает, что другие подстрахуют, случись чего.
                    • +5
                      У семи нянек дитя без глазу.

                      А у четрынрадцати без двух.

                      Недавно была статья про то, что бэкапы надо проверять. Интересно, кто-нибудь вообще понимает почему из 5 бэкапов/техник ничего не сработало?
                      • –1
                        У семи нянек четырнадцать титек.
                    • +2

                      Так пишут когда этот кто-то — менеджер. На канале @addmeto писали, что кто-то увлекся devops'изацией и решил, что админа не нужны

                      • +11
                        Этот «кто-то» — YP, упоминаемый в гуглодоксе, Yorick Peterse (https://yorickpeterse.com/)
                        Как сейчас гласит его профиль на Gitlab, он работает у них в качестве «Database (removal) Specialist». Так что несмотря на то, что отгребёт он абсолютно точно, да и сам, судя на его послужной список, он должен корить себя немало, отнеслись они с определённым юмором к ситуации.

                        Ну и увольнять человека действительно тут не за что. Всё могло закончиться гораздо хуже, если б он щёлкал клювом, а не немедленно выдернул всех и вся.
                        • +15
                          Бедный Йорик.
                          • 0
                            poor Yorick )
                          • 0
                            Ну так removal specialist, ничего удивительного.
                            • +7
                              Надо было выделить курсивом «removal». Это добавили вчера, что должно говорить о том, с каким юмором они на всё это смотрят.
                        • 0

                          Ну человеческий фактор, с кем не бывает.
                          У меня еще во время работы в одном из операторов связи по адской жаре оракловод ошибся сервером и тоже дропнул базу боевого билинга, ничего не сломалось, данные собирались, ждали пока поднимется мастер из бекапов с ленточки. При грамотной инфраструктуре — это слабозаметный на потере данных факап.

                  • +1
                    За битого двух небитых дают. Плюс удобняя оказия научится на чужих ошибках.
                    я думаю мы увидим полезный выход из этой ситуации, с разборкой полетов и где стоит подстилать соломку.
                    • +5
                      Да что тут смотреть-то? Так-то парни откровенно аццки зафейлили, если у них ни один бекап из 5 не делался и они не проверяли бекапы. Вывод один — проверяйте бекапы.
                      • +20

                        Старая шутка про 3 стадии системного администратора:


                        1. Не делает бекапы.
                        2. Делает бекапы.
                        3. Делает бекапы и проверяет восстановление.
                        • 0
                          Это суровая реальность.
                          • –8

                            На все 100% правы — проблема чтоб дойти до 3 надо пройти Крым, Рым и медные трубы — чтоб запомнилось .

                            • +1
                              А также 3 типа системного администратора:

                              1) Делает бекапы;
                              2) Не делает бекапы;
                              3) Уже делает бекапы.
                              • +2
                                Все же два:
                                1. Еще не делает
                                2. Уже делает

                                ))
                                • +7
                                  1. Еще не делает
                                  2. Уже не делает
                                  • 0
                                    3. Делает и проверяет, что они рабочие.
                                    • +8
                                      Зануды могут испортить любую шутку.
                              • 0
                                Вообще-то, когда сам был этаким ДБА/девелопером, всегда перед подобными действами РУКАМИ делал бэкап. «Если у вас не паранойи, то это не значит, что за вами не наблюдают»
                                • +4
                                  А сколько времени делается бэкап на больших проектах?
                                  • +1
                                    Да когда как… Но всяко меньше, чем пляска с бубном под умершей базой. Рекорд — двое суток без сна… А бекап — до часа…
                                    • 0
                                      Везёт… у меня на проекте он часов 10 только делается. Хотя восстанавливать, конечно, долго.
                                    • 0
                                      У меня хранилище в 50Тб бэкапилось 43 часа на ленточную библиотеку. Когда перешли на EMC DataDomain, стали укладываться в сутки. Это был кайф :)
                                      • 0
                                        DataDomain + Rman + boost и жизнь становится прекрасной
                                    • +2
                                      При устранении сбоя удаление файлов вообще не должно производиться нигде и никогда (ну, кроме ситуации «кончилось место на дисках», которая в нормальном продакшене встречаться не должна). Всё, что по запаре кажется не нужным на боевом сервере, должно перемещаться во временный, специально созданный для данного случая каталог, и разгребаться уже после восстановления. А то в условиях стресса можно настолько хорошо всё поудалять, что потом половину удалённого придётся поднимать с ленты, а вторую половину переписывать руками.
                                      • 0
                                        Вообще-то мы вроде как говорим о классических СУБД, а флет-тэйбл системы — да как угодно хранить можно. Вот только со стрессом к активным мероприятим на базе лучше не приступать — череповато…
                                        • 0
                                          А что, классические СУБД не оставляют на диске файлы, которые можно удалить? Насколько я понял из статьи, инженер как раз не дропнул базу, а именно что остановил процесс и удалил файлы с данными (и как раз-таки не одну таблицу, а всё целиком).

                                          Мой комментарий скорее был не про ДБА, а про админов в целом. Спору нет, без холодной головы ДБА долго в профессии не держится.
                                          • 0
                                            Гм… Как бы поточнее сказать… Пока база активна, то фих удалишь.
                                            • 0
                                              «остановил процесс»
                            • 0

                              Кто-нибудь нашёл информацию о том, чем им не подошёл lvm-снапшот, который был случайно сделан руками примерно в то же время, что и тот staging, с которого сейчас сливается база (и, если я правильно понял, был сделан на боевой базе)? В снапшоте же небось и вебхуки есть, которых нет на staging.

                              • 0
                                Как я понял они его сейчас и разворачивают, ведь других-то нет.
                                • 0

                                  В документе, на который ссылается топикстартер сказано следующее: YP is working on setting up pgpool and replication in staging, creates an LVM snapshot to get up to date production data to staging, hoping he can re-use this for bootstrapping other replicas. This was done roughly 6 hours before data loss.


                                  Возможно, проблема том, что у меня температура 38.8 сейчас, но из отрывка "creates an LVM snapshot to get up to date production data to staging" у меня сложилось впечатление, что разработчик сделал снапшот на production-сервере и хотел передать его на staging сервер. В таком случае не очень понятно, зачем делать длительную процедуру с rsync-ом, когда можно на сервере с production-базой откатить состояние раздела на этот снапшот.


                                  Надеюсь, сейчас просто не до того, чтобы всё нормально документировать и на этот вопрос команда Gitlab ещё ответит.

                                  • +2
                                    Скорей всего они сначала развернут его целиком и выдернут оттуда только базу, ведь наверное весь раздел возвращать не стоит, там же наверняка не только база лежит.
                              • +11

                                Кто то уже подсуетился и сделал 1 февраля выходным днем проверки бекапов: http://checkyourbackups.work/

                                • +23
                                  стримят процесс восстановления
                                  • +21
                                    Парни молодцы, что вот такой мегафейл не скрыли да еще и трансляцию замутили. Сообщество такое любит, им простят.
                                    • +10
                                      Очень нравится открытость компании. Как мы сегодня узнали, даже в таких случаях.
                                    • +17
                                      есть шанс превратить мегафейл в хорошую рекламу
                                      типа, мы облажались, но сделали выводы, и теперь у нас всё с 20-кратным резервированием и перед сном админы обязаны петь отче наш регламент резервного копирования
                                      • –8
                                        >> * The audio is too low, can you fix it?
                                        >No, we're sorry.

                                        Я правильно понимаю, что они не смогли включить усилок микрофона?

                                        • +3
                                          Как будто им больше нечем там заняться
                                      • –9
                                        во всем виноват постгре! ;)
                                        • +6
                                          это все уборщица…
                                          • +3
                                            Красиво однако.
                                            • +4
                                              Не ради рекламы, но AWS RDS PostgreSQL тут был бы в самый раз.
                                              Доступа к файловой системе нет, т.е. ошибка такая исключена.
                                              + снимаются снэпшоты
                                              + можно снимать исторические данные и класть в S3, что конечно сложно при базе весом 300+ GiB. Можно снимать с read реплики.
                                              • 0
                                                Без относительно этого продукта но про postgres — существует ли возможность получать дифф-снапшоты в виде выгружаемого файла (не важно — какой то внутренний бинарный формат или высокоуровневый sql-дамп), для выгрузки на сторонний сервер? А то 300Gb за раз выгрузить многовато и очень дорого… а конечная база могла бы быть восстановлена на основе одной из локальных старых копий и серии патчей-снапшотов.
                                                • 0
                                                  Конечно, можно архивировать WAL и потом его накатывать.
                                                  • +1

                                                    Вы говорите про архивирование журнала транзакций, позволяет делать именно это. А так же позволяет откатывать базу на произвольные моменты времени, делать «параллельные вселенные» и прочее.


                                                    Документация: https://postgrespro.ru/docs/postgrespro/9.6/continuous-archiving.html

                                                    • 0
                                                      на заметку: AWS RDS PostrgeSQL пока это не умеет (нет возможности снимать WAL и редактировать pg_hba.conf)

                                                      т.е. итог — при базе данных свыше ~500 GiB — остаётся только надеяться на rds-снэпшоты
                                                      • 0

                                                        Нам недоступны «облака», поэтому мы всё сами настраиваем, как хотим :-)

                                                  • 0
                                                    Стоимость решения сильно выше, чем у dedicated hardware
                                                    • 0
                                                      Хороший инстанс+Multi-AZ+хотя бы одна read-replica+снэпшоты
                                                      Да, в итоге выходит дорого. «Чуть» дешевле если берёшь Reserved instance на год(или на 3).
                                                      Как плюс — Избавляешься от проблем с обновлением PostgreSQL и обслуживанием железа.
                                                      Из минусов — цена и то что роль rds_superuser(высшая доступная привилегия) «немного» кастрированная.
                                                      • +5
                                                        Мы недавно прикидывали, правда для mysql. Если взять вместо нашего сервера (2xXeon E5-2600 & 256Gb RAM) соответствующий инстанс в AWS, то стоимость возрастает почти в 10 раз, с 350 до 3000 евро в месяц (и это ещё не считая стоимости трафика)
                                                        • 0
                                                          У вас ценник немного завышен. Посмотрите сервера в online.net :)
                                                          • +2
                                                            И что же я там увижу?
                                                            Из сопоставимых только такой, но с хреновыми дисками, а у нас SAS

                                                            2x Intel® Xeon® E5 2660 v4 / 256 GB DDR4 — 319 EUR

                                                            Но и этого сервера нет в наличии. Так что давайте не будем умничать и раздавать непрошенные советы? Я не хуже вашего знаком с европейским и американским рынком dedicated
                                                            • 0
                                                              И что же я там увижу?
                                                              Из сопоставимых только такой, но с хреновыми дисками, а у нас SAS

                                                              Кто же вам доктор, что вы не внимательны?

                                                              2 x Intel® Xeon® E5 2670 / 256 GB / 3 X 600 GB SAS за 150 евро доступны
                                                              2 x Intel® Xeon® E5 2670v2 / 256 GB / 3 X 500 GB SSD за 203 евро только вчера были

                                                              Америку не предлагаю, там все еще пичально.

                                                              • +1
                                                                Зачем мне 3 диска? Собрать колченогий RAID5? Спасибо, но у нас 10-ый RAID, да и по стораджу маловато, на этих серверах по 8 дисков 600Gb SAS 15k.

                                                                Что вы мне пытаетесь доказать? Я не побегу сломя голову ставить db-сервера на другой площадке из-за призрачной экономии в пару десятков евро
                                                                • –3
                                                                  В следующий раз пишите более четко, какие сервера вы сравниваете с AWS.
                                                                  Один из главных параметров упустили и все, получили сферического коня в вакууме.
                                                                  • –4
                                                                    В следующий раз пишите более четко


                                                                    Простите, вы уху ели? Я вас вообще ни о чем не спрашивал, никаких расчётов вам не заказывал и в ваших пионерских советах «как сэкономить 20 евро» не нуждался. Я сравнивал ценник на сопоставимые серверные ресурсы. Разница почти в 10 раз, этого достаточно, чтобы не использовать AWS под эти задачи. И всё. Ступайте себе с миром и не морочьте голову. Dixi
                                                                    • –1
                                                                      Я сравнивал ценник на сопоставимые серверные ресурсы. Разница почти в 10 раз

                                                                      Простите, оценку надо делать полную, а не выдернутую из контекста.
                                                                      Пока что я у вас вижу голословную конфигурацию
                                                                      2xXeon E5-2600 & 256Gb RAM
                                                                      и забытые — тип винтов, их кол-во и IOPS массива. А только потом сравнивать с аналогами AWS.
                                                                      Серверу уже небось года два, хостер давно отбил стоимость железа, взяв еще вначале львиную долю за первоначальный сетап нестандартной конфигурации.
                                                                      И теперь только радуется, что такой неповоротливый клиент платит лишние 100-150 евро каждый месяц :)
                                                                      Сервер один? не страшно эксплуатировать?
                                                                      • –5
                                                                        Сервер один? не страшно эксплуатировать?

                                                                        Не страшно. Серверов несколько стоек. Пожалуйста, пройдите нахуй со своими навязчивыми советами и прочими соображениями, что и как я должен сравнивать
                                                    • 0

                                                      Хм, у нас RDS с multi-az mirroring, и трижды за последний год случались серьезные факапы с БД в которых failover не спас.

                                                      • 0
                                                        Какая субд?
                                                        И какого рода факапы?
                                                        • 0

                                                          MSSQL. Например, в последний раз кривой запрос скушал весь диск на инстансе, точных деталей не знаю, но failover не сработал.

                                                    • –3
                                                      лайв стрим гитлаба https://www.youtube.com/watch?v=nc0hPGerSd4
                                                      • +4
                                                        Да, печалька, видимо отвлекся парень…
                                                        У меня как-то было похожий случай. Попросили обнулить цену в базе на один продукт, ну и в процессе обновления цены меня отвлекли и я забыл дописать where к запросу (UPDATE products SET price = 0)… Ну и улетели цены на ~1кк продуктов…
                                                        Бакап спас в итоге :)
                                                        • +25
                                                          На продакшене надо стартовать транзакцию, потом делать апдейт. Тогда, если увидишь «обновлено 100500 строк», то просто пишешь rollback
                                                          • +2
                                                            Ага… Зеленый был я тогда…
                                                            • 0
                                                              А насколько так лучше/хуже поступать чем сразу прописывать begin tran… изменения… rollback tran, смотреть результат, может даже несколько раз прогонять, проверяя результат селектами внутри транзаккции и если всё ок, менять rollback на commit и прогонять уже финально? А то я именно так всегда делаю, вроде множество быстрых транзакций — меньшее зло чем она длинная, или нет?
                                                              • 0

                                                                Селектами удобно проверять перед update ) Да и можно конечно на тест сервере\тест базе испробовать — тоже учился на своих и на чужих ошибокам

                                                                • 0
                                                                  Целиком и полностью поддерживаю. Семь раз проверь, один раз закоммить.
                                                                  Еще хорошо перед выполнением внимательно проверить к какой базе подключился, сделать select * from global_name, убедиться, что база точно та, и, лишь потом, выполнять-коммитить. Это, конечно, для совсем параноиков :)

                                                                  Ну и обязательно автокоммит выключить, эта мера может спасти от многих ошибок, если первые пункты забыл сделать)
                                                                • 0
                                                                  Не всегда это возможно. Во многих случаях в транзакции имеем блокировку строк/таблицы и клиенты стоят ждут когда транзакция закроется в ту или иную сторону… а мы тут 5 минут проверяем всё ли хорошо.
                                                              • 0
                                                                Такая ситуация с каждым разработчиком, наверное, случалась. Как правило, она случается только раз :) А SSMSBoost вообще подтверждение запрашивает перед выполнением подобных запросов без where.
                                                                • +1
                                                                  Любой апдейт начинать проверять с
                                                                  begin tran

                                                                  rollback

                                                                  Потом внутри вставляем
                                                                  1. Отбор записей по условию
                                                                  2. Апдейт
                                                                  3. Отбор записей по условию (обновленных)

                                                                  Если все ок, то апдейт с коммитом

                                                                  Ну а у Оракла понравилось то, что он по умолчанию транзакции не коммитит. Сначала удивился конечно
                                                                  • 0
                                                                    Аххаха точно такое же недавно было. Вышел в понедельник с бодуна называется.
                                                                  • +5
                                                                    Вроде как и забавная ситуация перепутать мастер и реплику, но на прошлой неделе была похожая ситуация, от того не смешно.
                                                                    image
                                                                    • +12
                                                                      Извиняюсь за оффтоп. За сегодня уже раз шестой вижу это существо. Что это? Почему оно везде?
                                                                    • 0

                                                                      Прочитал внимательно, что произошло с GitLab’ом и почувствовал жгучее дежа вю. Ведь буквально две-три недели тому я подымал репликацию на рабочем проекте (с всего лишь в два раза меньшей базой) и у меня тоже с первой попытки pg_basebackup не завёлся, я ругнулся, перезапустил его, теперь он ругнулся, что папка назначения не пустая, я снова ругнулся, сделал rm -rf /var/lib/postgresql/9.5/main и снова его запустил. Всё отличие только в том, что мне повезло больше того парня и я не перепутал будущую реплику с мастером при этом.

                                                                    • –24
                                                                      Тут могла бы быть шутка про… э-э-э некоторых хакеров.

                                                                      Но не буду — ибо и так всё печально.
                                                                      • –16
                                                                        Мой комент о нешутке «оценили»! — Есть ещё гики на хабре (С) :-)
                                                                        • +1
                                                                          Здесь мог быть ответ на Ваш комментарий. Но его, конечно же, тоже не будет по понятным причинам.
                                                                          • –5
                                                                            raacer:
                                                                            Здесь мог быть ответ на Ваш комментарий. Но его, конечно же, тоже не будет по понятным причинам.

                                                                            Бают норвеги собираются считать бюллетени на ближайших своих выборов вручную. — Ибо они их бояться.
                                                                        • 0
                                                                          Я вот не совсем понял. Есть мастер база, данные льются по реплике на стендбай, вроде все ок. Дальше мы берем и стопнув инстанс базы на мастере удаляем дб файлы там же. Но на стендбай же это никак не отразилось! Если б он не «rm -rf», а «drop database» сделал, тогда да, реплики не спасают, но сдесь то как?
                                                                          • +4
                                                                            Реплика была одна и очень сильно глючила (отставала), насколько я понял
                                                                            • +3
                                                                              Со своими не ахти какими знаниями английского я так понял, что сильно глючащую реплику почистили для перезапуска, оставив пустой каталог, перезапуск зафейлился, решили удалить оставшийся пустой каталог, но ошиблись окошком и удалили непустой на мастере, по графику это видно (db2 реплика, db1 мастер)

                                                                              Скрытый текст
                                                                            • 0
                                                                              http://checkyourbackups.work/
                                                                              уже есть, не заметил (
                                                                              • 0
                                                                                Они всего лишь обычные люди.
                                                                                • +2
                                                                                  Пусть ломают. Лишь бы учились.
                                                                                  • +2

                                                                                    Лишь бы научились.

                                                                                    • 0
                                                                                      Ломать уже научились
                                                                                      Даст бог и восстанавливать тоже научатся

                                                                                      не с первого, так с н-ного раза
                                                                                      как говорит бабушка: «лишь бы были здоровы» :D
                                                                                  • +3

                                                                                    Не оставляло чувство до конца прочтения всех комментов, что сегодня 1 апреля

                                                                                    • +11

                                                                                      Я на проде использую mv вместо rm по возможности.

                                                                                      • 0

                                                                                        подозреваю, что у них не было лишних 300Гб свободного места

                                                                                        • 0
                                                                                          mv не копирует данные.
                                                                                          • 0

                                                                                            конечно не копирует. но после этого вы ведь наполните настоящую папку новыми данными, коих тоже 300Гб

                                                                                            • +2
                                                                                              Можно переименовать папку, проверить, что всё продолжает работать, а потом уже удалять и наполнять новыми данными.
                                                                                          • +5
                                                                                            Свободных 300 Гб на сервере хранения данных не было? У компании, занимающейся хранением данных?

                                                                                            300 Гб — это что, в 2017 году для кого-то всё ещё много?
                                                                                        • +14
                                                                                          А почему бы не называть хосты по-человечески? Master-db, Replica-db. В этой ситуации бы спасло. И сделать rm «медленным», откладывая реальное удаление на ощутимый для «одуматься» срок.
                                                                                          • +1
                                                                                            Не спасло бы, потому что всё равно никто не читает PS1, проверено на себе))
                                                                                            • +1
                                                                                              А что за медленный rm? Скоростью удаления можно как-то управлять?
                                                                                              • +1
                                                                                                удаление перемещением в корзину
                                                                                                • +2
                                                                                                  В linux нет корзинки
                                                                                                  • –9
                                                                                                    а lost+found тогда что? или вы наверное не в курсе? :)
                                                                                                    • +1
                                                                                                      lost+found это восстановленные файлы(зачастую их части), которые были найдены в результате проверки диска на ошибки.
                                                                                                    • –5
                                                                                                      Ну как же нет, на Ubuntu точно встречал каталог «Trash», который работал так же, как виндовая корзина.
                                                                                                      • +2
                                                                                                        Это корзина для оконного интерфейса, если удаляешь через Nautilus или подобный файловый менеджер. В консоли нет корзины, rm удаляет сразу в /dev/null.
                                                                                                        • –1
                                                                                                          Эта корзина ведёт себя точно также, как и виндовая, которая тоже по сути «корзина для оконного интерфейса». Можете убедиться, удалив файл в винде через командную строку «del -F test.txt».
                                                                                                          • +1
                                                                                                            Еще раз:
                                                                                                            Консольная команда rm удаляет файлы напрямую без корзин. В MC удаление так же идет напрямую.
                                                                                                            А оконным интерфейсом на серверах не пользуются.
                                                                                                            • –4
                                                                                                              Я лишь ответил на ваше утверждение «В linux нет корзинки», которое не верно — корзина там есть, такая же как и на винде. Как именно и кто удаляет файлы у себя на серверах — дело десятое.
                                                                                                              • +7
                                                                                                                Но в linux нет корзины. Она есть в дистрибутивах с GUI
                                                                                                                • –1
                                                                                                                  У Вас с предыдущим комментатором рассинхронизация:
                                                                                                                  Germanets имел в виду что и в винде корзина только для GUI.
                                                                                                                  А консольные команды точно так же удаляют всё подчистую
                                                                                                  • +1
                                                                                                    Ставить задачу на удаление. Раз в n времени бежит воркер и выполняет задачи на удаление. Это канает, когда нужно удалить и уйти (старые бэкапы, ненужные файлы), но тут, как я понял, нужно было прибить каталог и запустить реплику, то есть по факту создать этот каталог заново и писать в него.
                                                                                                    • 0
                                                                                                      ммм… а как это сделать? подкинете рецепты? или это конкретно про postgres?
                                                                                                      • 0
                                                                                                        Это про что угодно. Самая простая реализация — подмена команды rm на запись пути в файл. По крону скрипт хватает эти пути и начинает удалять. Дальше навороты, как хотим (проверка прав на удаление и все, что придет в голову)
                                                                                                        • 0

                                                                                                          исходные файлы опять-же надо мувать из исходной папки, что может быть недопустимо из-за нехватки места

                                                                                                  • +2
                                                                                                    Мастер-реплика видимо не называли, так как они иногда менялись ролями
                                                                                                    • 0
                                                                                                      Можно было бы назвать чем-нибудь нейтральным, типа названий планет, типа если при работе над юпитером вдруг вылез сатурн, то кажется что-то пошло не так
                                                                                                  • 0
                                                                                                    Перфоратор не в ту розетку воткнули.
                                                                                                  • –1
                                                                                                    https://youtu.be/nc0hPGerSd4 — livestream процесса восстановления.
                                                                                                    • +13
                                                                                                      сделал rm -rf на db1.cluster.gitlab.com вместо db2.cluster.gitlab.com

                                                                                                      Из этого извлекаем урок: нельзя, нельзя, нельзя так похоже именовать продакшн с репликами, тестовыми машинами и пр…
                                                                                                      • +2

                                                                                                        А как их тогда называть? А как их переименовывать при failover'е?

                                                                                                        • 0
                                                                                                          У них же в доке написаны планы!

                                                                                                          TODO after data restored:
                                                                                                          Create issue to change terminal PS1 format/colours to make it clear whether you’re using production or staging (red production, yellow staging)
                                                                                                          Show the full hostname in the bash prompt for all users by default (e.g., “db1.staging.gitlab.com” instead of just “db1”)
                                                                                                          Somehow disallow rm -rf for the PostgreSQL data directory? Unsure if this is feasible, or necessary once we have proper backups
                                                                                                          Add alerting for backups: check S3 storage etc.
                                                                                                          Add a graph with the size of the backups over time, page when it goes down by more than 10%.
                                                                                                          Consider adding a last successful backup time in DB so admins can see this easily (suggested by customer in https://gitlab.zendesk.com/agent/tickets/58274)
                                                                                                          Figure out why PostgreSQL suddenly had problems with max_connections being set to 8000, despite it having been set to that since 2016-05-13. A large portion of frustration arose because of this suddenly becoming a problem.
                                                                                                          Add server hostname to bash PS1 (avoid running commands on the wrong host)
                                                                                                          Look into increasing replication thresholds via WAL archiving
                                                                                                          Create troubleshooting guide for problems users might encounter after we go online
                                                                                                          PITR — also will be useful after failed upgrades
                                                                                                          Experiment with moving data from one datacenter to another via AzCopy: Microsoft says this should be faster than rsync
                                                                                                          • +4

                                                                                                            Вот судя из доков, они не собираются ничего переименовывать, только выводить полное имя хоста в заголовок окна с терминалом и подкрашивать заголовок окна терминалов с продакшеном в красный цвет.

                                                                                                            • 0
                                                                                                              подкрашивать заголовок окна терминалов с продакшеном в красный цвет.

                                                                                                              Может, не только заголовок окна, но и саму «prompt-строчку»?
                                                                                                              • 0
                                                                                                                Скорее всего. Я так делал с этой целью. Просто насоздавал .terminal ярлычков. При нажатии запускается подключение к нужному серверу, окошко терминала окрашено красным для live и другими цветами для других инстансов. Сразу же можно задать какие-нибудь комманды для выполнения. Например сквозное подключение через несколько промежуточных серверов.
                                                                                                              • +1
                                                                                                                они не собираются ничего переименовывать

                                                                                                                было: db2.cluster.gitlab.com
                                                                                                                станет: db1.staging.gitlab.com
                                                                                                          • +3
                                                                                                            По документу у них были ещё db1.staging.gitlab.com и db2.staging.gitlab.com, а в консоли выводилось >username@db1:

                                                                                                            Так что перепутать окошко и написать не туда запросто. Лучше бы подключили дротики с транквилизатором, срабатывающим на «rm -rf»
                                                                                                          • 0
                                                                                                            Ожил.
                                                                                                            • +4

                                                                                                              Можно поздравить gitlab с присоединением к клубу тех, кто не только делает бекап, но и проверяет, что с него можно восстановиться.

                                                                                                              • –1
                                                                                                                А если по теме? Как все-таки мониторить бэкапы? После долгих скитаний в поисках софта — остановились мы на BareOS.
                                                                                                                Заставить её проверять на «0 байт» можно, а вот как проверять, что «файл обновился» (актуально например для Redis- snapshot'ов)
                                                                                                                • 0
                                                                                                                  Для Veritas Cluster есть интересное решение, которое я внедрял несколько лет назад. Называется FireDrill.
                                                                                                                  Там на второй площадке (куда идет аппаратное зеркалирование), делается мгновенная копия данных, т. н. снапшот (предварительно переводя базу в режим горячего резервного копирования).
                                                                                                                  Этот снапшот монтируется на резервной площадке, в базе меняется IP на резервный, поднимается база, проверяется как нужно, хоть с привлечением операционисток. После проверки, база опускается, отмонтируется и удаляется автоматом. Таким образом мы можем быть уверены, что в случае чего, база нормально поднимется на резервной площадке.
                                                                                                                  • 0
                                                                                                                    ZFS и штук 5 строчек кода в скрипте помогут это реализовать на коленке :)
                                                                                                                    • 0
                                                                                                                      Конечно. Я просто опытом поделился, с мыслю, что подобное можно реализовать другими средствами.
                                                                                                                    • 0
                                                                                                                      Возможно я скажу что-то очевидное но… проверка такая например — штатная фича Veeam Backup & Replication.
                                                                                                                      Виртуалки поднимаются прямо из бекапа (можно настроить чтобы они не жрали столько памяти) в изолированной среде (а можно и не совсем изолированной), проверяется прописанные админом вещи (по умолчанию — что оно вообще отвечает по сети и vmware tools запускаются + что файл бекапа реально читается. в условиях когда и этого нет — это преимущество а можно сделать сложные скрипты проверки + сразу поднимать группы виртуалок).
                                                                                                                      На хабре были статьи даже как эта штука настраивается в базовом варианте.
                                                                                                                      При этом не нужно ничего кроме VMware/Hyper-V кластера (хотя завести на посмотреть можно и на одном хосте) ну и Veeam'а с платной лицензией.
                                                                                                                      Снапшоты разумеется Veeam умеет делать, несколькими разными способами (сильно зависит от того — что мы понимаем под снапшотом и что умеет делать хранилище)
                                                                                                                  • –10
                                                                                                                    По-хорошему техническое руководство (не знаю, что у них там — CTO, VP of Engineering) должны быть уволены со сгоранием опционов, или как минимум сами уволиться.
                                                                                                                    • +8
                                                                                                                      Ага, и еще попросить всю поддержку рассчитаться по порядку и каждого десятого расстрелять. И CEO тоже пусть акционеры погонят поганой метлой. Что б все знали, что здесь не шутки, а серьезная компания.

                                                                                                                      Ну вот откуда такая любовь к монголо-татарским методам мотивации? Подобные инциденты случаются сплошь и рядом, и чаще всего по недосмотру или ошибке рядового сотрудника даже в организациях со строгими процессами. На каждый инцидент CTO не напасешься. Понятное дело за систематические проблемы и неспособность исправить ситуацию, но это не тот случай мне кажется. Отлично отреагировали, проблема решается, выводы вроде бы сделали (надеюсь в том числе и что не дело до полуночи ковырять на живую продакшн человеку после полного рабочего дня)
                                                                                                                      Ну и хорошая картинка из блога ГитЛаб
                                                                                                                      image

                                                                                                                      • +1
                                                                                                                        то, что не проверяли бекапы на восстанавливаемость — это как раз-таки системная ошибка.
                                                                                                                        • 0
                                                                                                                          с одной стороны вы правы — там много к чему есть вопросы (в том числе в первую очередь к недостаточно заметной индикации где работаем — в продакшн или в реплике, да и в первую очередь к режиму администрирования )
                                                                                                                          но это «стартап» все же, со всеми сопутствующими недостатками: команда небольшая, главное динамика, побыстрее выкатывать новые фичи. Одновременно идет maturity процессов и набор опыта поддержки в команде и руководстве, но это вообще не приоритет сам по себе.
                                                                                                                          А уж учитывая как отреагировали, построив на этом дополнительную рекламу и product awareness, так и совсем все неплохо по бизнес модели.

                                                                                                                          Если б такая история произошла на, скажем, нефтеперерабатывающем предпиятии, то другое дело, я б первый за покарать причастных был бы (да и то CTO все ж сильный заход), но здесь…

                                                                                                                          кстати вот вчера кто-то Instagram немножко уронил базы и у людей массово пропали профили, фоточки и лайки к фоточкам — представляете какое горе в мировом масштабе случилось.
                                                                                                                          Только сейчас начало все обратно восстанавливаться. Ну увольнять Instagram СТО и VP Engineering за это? не думаю.

                                                                                                                          • 0
                                                                                                                            Нефтеперерабатывающий стартап — это такое себе, знаете ли.
                                                                                                                            • 0
                                                                                                                              не нефтепереабатывающий, а на нефтеперерабатывающем предпиятии. их не так много конечно как «Безопасных месснджеров», но вполне достаточно — SCADA, мониторинг и анализ и т.д.

                                                                                                                              Я думаю нефтеперерабатывающим стартапом компетентные органы заинтересуются прям на этапе гаражной хим.лаборатории, по сигналу соседей.

                                                                                                                        • +1
                                                                                                                          При чем здесь поддержка? Я, заметьте, даже админа не предлагал уволить.

                                                                                                                          Почему вы называете это инцидентом? Инцидент это — админ порушил базу. А тут абсолютное наплевательство и халатность на протяжении продолжительного времени. Зачем иметь семь уровней бэкапов из которых ни один не работает? И как так получилось, что никто об этом не знал?

                                                                                                                          Есть такая вещь как ответственность. Если ты министр и превысил скорость — подаешь в отставку. Мне такое понятие о профессионализме и гордости гораздо ближе.
                                                                                                                        • +2
                                                                                                                          Одна из причин, почему я обычно не удаляю, а переименовываю или перемещаю, если место не жмет. И потом, если уже все точно хорошо, удаляю.

                                                                                                                          Также для ребят это знак, что с бекапами у них все плохо.

                                                                                                                          Shit happens, для такого сервиса это, конечно, не очень хорошо смотрится, но все случается.
                                                                                                                          • 0
                                                                                                                            Вот это «день не задался», столько неудачных обстоятельств:
                                                                                                                            и терминал перепутал и 5 бэкапов не восстали.
                                                                                                                            • 0
                                                                                                                              Восстание бэкапов :D
                                                                                                                            • 0
                                                                                                                              Я вот так однажды случайно убил всю документацию по контрагентам за 5 лет, а бекапы не развертывались. В итоге спасла мега случайность — за несколько дней до этого я добавлял оперативки в сервер и чтобы на меня бухгалтерия не ругалась эти 20 минут, я сделал копию этих документов у себя на компе и сделал им доступ по локалке. Оттуда я их и восстановил, т.к. тупо забыл их удалить с компа.