Вчера, 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-часового бекапа
> Вот полный текст документа
Комментарии (162)
kemko
01.02.2017 17:50Кто-нибудь нашёл информацию о том, чем им не подошёл lvm-снапшот, который был случайно сделан руками примерно в то же время, что и тот staging, с которого сейчас сливается база (и, если я правильно понял, был сделан на боевой базе)? В снапшоте же небось и вебхуки есть, которых нет на staging.
RamusAkaRami
01.02.2017 18:03Как я понял они его сейчас и разворачивают, ведь других-то нет.
kemko
01.02.2017 18:14В документе, на который ссылается топикстартер сказано следующее: 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 ещё ответит.
RamusAkaRami
01.02.2017 18:38+2Скорей всего они сначала развернут его целиком и выдернут оттуда только базу, ведь наверное весь раздел возвращать не стоит, там же наверняка не только база лежит.
Rastishka
01.02.2017 18:05+11Кто то уже подсуетился и сделал 1 февраля
выходнымднем проверки бекапов: http://checkyourbackups.work/
Draug
01.02.2017 18:29+4Не ради рекламы, но AWS RDS PostgreSQL тут был бы в самый раз.
Доступа к файловой системе нет, т.е. ошибка такая исключена.
+ снимаются снэпшоты
+ можно снимать исторические данные и класть в S3, что конечно сложно при базе весом 300+ GiB. Можно снимать с read реплики.rPman
01.02.2017 22:09Без относительно этого продукта но про postgres — существует ли возможность получать дифф-снапшоты в виде выгружаемого файла (не важно — какой то внутренний бинарный формат или высокоуровневый sql-дамп), для выгрузки на сторонний сервер? А то 300Gb за раз выгрузить многовато и очень дорого… а конечная база могла бы быть восстановлена на основе одной из локальных старых копий и серии патчей-снапшотов.
Envek
01.02.2017 22:18+1Вы говорите про архивирование журнала транзакций, позволяет делать именно это. А так же позволяет откатывать базу на произвольные моменты времени, делать «параллельные вселенные» и прочее.
Документация: https://postgrespro.ru/docs/postgrespro/9.6/continuous-archiving.html
Draug
02.02.2017 01:49на заметку: AWS RDS PostrgeSQL пока это не умеет (нет возможности снимать WAL и редактировать pg_hba.conf)
т.е. итог — при базе данных свыше ~500 GiB — остаётся только надеяться на rds-снэпшоты
lev
02.02.2017 01:01Стоимость решения сильно выше, чем у dedicated hardware
Draug
02.02.2017 02:04Хороший инстанс+Multi-AZ+хотя бы одна read-replica+снэпшоты
Да, в итоге выходит дорого. «Чуть» дешевле если берёшь Reserved instance на год(или на 3).
Как плюс — Избавляешься от проблем с обновлением PostgreSQL и обслуживанием железа.
Из минусов — цена и то что роль rds_superuser(высшая доступная привилегия) «немного» кастрированная.lev
02.02.2017 09:28+5Мы недавно прикидывали, правда для mysql. Если взять вместо нашего сервера (2xXeon E5-2600 & 256Gb RAM) соответствующий инстанс в AWS, то стоимость возрастает почти в 10 раз, с 350 до 3000 евро в месяц (и это ещё не считая стоимости трафика)
click0
02.02.2017 21:33У вас ценник немного завышен. Посмотрите сервера в online.net :)
lev
02.02.2017 22:57+2И что же я там увижу?
Из сопоставимых только такой, но с хреновыми дисками, а у нас SAS
2x Intel® Xeon® E5 2660 v4 / 256 GB DDR4 — 319 EUR
Но и этого сервера нет в наличии. Так что давайте не будем умничать и раздавать непрошенные советы? Я не хуже вашего знаком с европейским и американским рынком dedicatedclick0
03.02.2017 00:39И что же я там увижу?
Из сопоставимых только такой, но с хреновыми дисками, а у нас 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 евро только вчера были
Америку не предлагаю, там все еще пичально.
lev
03.02.2017 01:01+1Зачем мне 3 диска? Собрать колченогий RAID5? Спасибо, но у нас 10-ый RAID, да и по стораджу маловато, на этих серверах по 8 дисков 600Gb SAS 15k.
Что вы мне пытаетесь доказать? Я не побегу сломя голову ставить db-сервера на другой площадке из-за призрачной экономии в пару десятков евроclick0
03.02.2017 01:31-3В следующий раз пишите более четко, какие сервера вы сравниваете с AWS.
Один из главных параметров упустили и все, получили сферического коня в вакууме.lev
03.02.2017 01:48-4В следующий раз пишите более четко
Простите, вы уху ели? Я вас вообще ни о чем не спрашивал, никаких расчётов вам не заказывал и в ваших пионерских советах «как сэкономить 20 евро» не нуждался. Я сравнивал ценник на сопоставимые серверные ресурсы. Разница почти в 10 раз, этого достаточно, чтобы не использовать AWS под эти задачи. И всё. Ступайте себе с миром и не морочьте голову. Dixiclick0
03.02.2017 02:13-1Я сравнивал ценник на сопоставимые серверные ресурсы. Разница почти в 10 раз
Простите, оценку надо делать полную, а не выдернутую из контекста.
Пока что я у вас вижу голословную конфигурацию
2xXeon E5-2600 & 256Gb RAM
и забытые — тип винтов, их кол-во и IOPS массива. А только потом сравнивать с аналогами AWS.
Серверу уже небось года два, хостер давно отбил стоимость железа, взяв еще вначале львиную долю за первоначальный сетап нестандартной конфигурации.
И теперь только радуется, что такой неповоротливый клиент платит лишние 100-150 евро каждый месяц :)
Сервер один? не страшно эксплуатировать?lev
03.02.2017 02:37-5Сервер один? не страшно эксплуатировать?
Не страшно. Серверов несколько стоек. Пожалуйста, пройдите нахуй со своими навязчивыми советами и прочими соображениями, что и как я должен сравнивать
f0rk
02.02.2017 13:57Хм, у нас RDS с multi-az mirroring, и трижды за последний год случались серьезные факапы с БД в которых failover не спас.
troyanskiy
01.02.2017 18:41+4Да, печалька, видимо отвлекся парень…
У меня как-то было похожий случай. Попросили обнулить цену в базе на один продукт, ну и в процессе обновления цены меня отвлекли и я забыл дописать where к запросу (UPDATE products SET price = 0)… Ну и улетели цены на ~1кк продуктов…
Бакап спас в итоге :)
varanio
01.02.2017 18:44+25На продакшене надо стартовать транзакцию, потом делать апдейт. Тогда, если увидишь «обновлено 100500 строк», то просто пишешь rollback
lightman
01.02.2017 22:08А насколько так лучше/хуже поступать чем сразу прописывать begin tran… изменения… rollback tran, смотреть результат, может даже несколько раз прогонять, проверяя результат селектами внутри транзаккции и если всё ок, менять rollback на commit и прогонять уже финально? А то я именно так всегда делаю, вроде множество быстрых транзакций — меньшее зло чем она длинная, или нет?
kamtec1
01.02.2017 23:36Селектами удобно проверять перед update ) Да и можно конечно на тест сервере\тест базе испробовать — тоже учился на своих и на чужих ошибокам
DJ-Glock
02.02.2017 06:06Целиком и полностью поддерживаю. Семь раз проверь, один раз закоммить.
Еще хорошо перед выполнением внимательно проверить к какой базе подключился, сделать select * from global_name, убедиться, что база точно та, и, лишь потом, выполнять-коммитить. Это, конечно, для совсем параноиков :)
Ну и обязательно автокоммит выключить, эта мера может спасти от многих ошибок, если первые пункты забыл сделать)
Alexeyslav
02.02.2017 18:18Не всегда это возможно. Во многих случаях в транзакции имеем блокировку строк/таблицы и клиенты стоят ждут когда транзакция закроется в ту или иную сторону… а мы тут 5 минут проверяем всё ли хорошо.
SlimShaggy
01.02.2017 20:57Такая ситуация с каждым разработчиком, наверное, случалась. Как правило, она случается только раз :) А SSMSBoost вообще подтверждение запрашивает перед выполнением подобных запросов без where.
workless
02.02.2017 09:46+1Любой апдейт начинать проверять с
begin tran
…
rollback
Потом внутри вставляем
1. Отбор записей по условию
2. Апдейт
3. Отбор записей по условию (обновленных)
Если все ок, то апдейт с коммитом
Ну а у Оракла понравилось то, что он по умолчанию транзакции не коммитит. Сначала удивился конечно
grieverrr
02.02.2017 12:54Аххаха точно такое же недавно было. Вышел в понедельник с бодуна называется.
mikkisse
01.02.2017 18:52+5Вроде как и забавная ситуация перепутать мастер и реплику, но на прошлой неделе была похожая ситуация, от того не смешно.
vlreshet
01.02.2017 20:11+12Извиняюсь за оффтоп. За сегодня уже раз шестой вижу это существо. Что это? Почему оно везде?
Envek
01.02.2017 22:20Прочитал внимательно, что произошло с GitLab’ом и почувствовал жгучее дежа вю. Ведь буквально две-три недели тому я подымал репликацию на рабочем проекте (с всего лишь в два раза меньшей базой) и у меня тоже с первой попытки
pg_basebackupне завёлся, я ругнулся, перезапустил его, теперь он ругнулся, что папка назначения не пустая, я снова ругнулся, сделалrm -rf /var/lib/postgresql/9.5/mainи снова его запустил. Всё отличие только в том, что мне повезло больше того парня и я не перепутал будущую реплику с мастером при этом.
taujavarob
01.02.2017 18:54-24Тут могла бы быть шутка про… э-э-э некоторых хакеров.
Но не буду — ибо и так всё печально.
raacer
02.02.2017 19:04+1Здесь мог быть ответ на Ваш комментарий. Но его, конечно же, тоже не будет по понятным причинам.
taujavarob
03.02.2017 15:36-5Здесь мог быть ответ на Ваш комментарий. Но его, конечно же, тоже не будет по понятным причинам.
Бают норвеги собираются считать бюллетени на ближайших своих выборов вручную. — Ибо они их бояться.
darkmind
01.02.2017 19:01Я вот не совсем понял. Есть мастер база, данные льются по реплике на стендбай, вроде все ок. Дальше мы берем и стопнув инстанс базы на мастере удаляем дб файлы там же. Но на стендбай же это никак не отразилось! Если б он не «rm -rf», а «drop database» сделал, тогда да, реплики не спасают, но сдесь то как?
andreymal
01.02.2017 19:19+3Со своими не ахти какими знаниями английского я так понял, что сильно глючащую реплику почистили для перезапуска, оставив пустой каталог, перезапуск зафейлился, решили удалить оставшийся пустой каталог, но ошиблись окошком и удалили непустой на мастере, по графику это видно (db2 реплика, db1 мастер)
Скрытый текст
w4r_dr1v3r
01.02.2017 19:34+2Пусть ломают. Лишь бы учились.
fishca
01.02.2017 22:11+2Лишь бы научились.
Anymorficus
02.02.2017 06:06Ломать уже научились
Даст бог и восстанавливать тоже научатся
не с первого, так с н-ного раза
как говорит бабушка: «лишь бы были здоровы» :D
fishca
01.02.2017 19:45+3Не оставляло чувство до конца прочтения всех комментов, что сегодня 1 апреля
ctacka
01.02.2017 19:52+11Я на проде использую mv вместо rm по возможности.
Dreyk
02.02.2017 12:24подозреваю, что у них не было лишних 300Гб свободного места
kvazimoda24
02.02.2017 14:53mv не копирует данные.
Dreyk
02.02.2017 14:56конечно не копирует. но после этого вы ведь наполните настоящую папку новыми данными, коих тоже 300Гб
kvazimoda24
02.02.2017 15:01+2Можно переименовать папку, проверить, что всё продолжает работать, а потом уже удалять и наполнять новыми данными.
ximaera
02.02.2017 15:09+5Свободных 300 Гб на сервере хранения данных не было? У компании, занимающейся хранением данных?
300 Гб — это что, в 2017 году для кого-то всё ещё много?
entze
01.02.2017 19:55+14А почему бы не называть хосты по-человечески? Master-db, Replica-db. В этой ситуации бы спасло. И сделать rm «медленным», откладывая реальное удаление на ощутимый для «одуматься» срок.
andreymal
01.02.2017 19:59+1Не спасло бы, потому что всё равно никто не читает PS1, проверено на себе))
vlreshet
01.02.2017 20:13+1А что за медленный rm? Скоростью удаления можно как-то управлять?
rPman
01.02.2017 20:19+1удаление перемещением в корзину
MasMaX
02.02.2017 09:45+2В linux нет корзинки
shadowgodness
02.02.2017 10:09-9а lost+found тогда что? или вы наверное не в курсе? :)
Germanets
02.02.2017 10:50+1lost+found это восстановленные файлы(зачастую их части), которые были найдены в результате проверки диска на ошибки.
Germanets
02.02.2017 10:48-5Ну как же нет, на Ubuntu точно встречал каталог «Trash», который работал так же, как виндовая корзина.
MasMaX
02.02.2017 10:52+2Это корзина для оконного интерфейса, если удаляешь через Nautilus или подобный файловый менеджер. В консоли нет корзины, rm удаляет сразу в /dev/null.
Germanets
02.02.2017 10:59-1Эта корзина ведёт себя точно также, как и виндовая, которая тоже по сути «корзина для оконного интерфейса». Можете убедиться, удалив файл в винде через командную строку «del -F test.txt».
MasMaX
02.02.2017 11:02+1Еще раз:
Консольная команда rm удаляет файлы напрямую без корзин. В MC удаление так же идет напрямую.
А оконным интерфейсом на серверах не пользуются.Germanets
02.02.2017 11:11-4Я лишь ответил на ваше утверждение «В linux нет корзинки», которое не верно — корзина там есть, такая же как и на винде. Как именно и кто удаляет файлы у себя на серверах — дело десятое.
instingt
01.02.2017 20:57+1Ставить задачу на удаление. Раз в n времени бежит воркер и выполняет задачи на удаление. Это канает, когда нужно удалить и уйти (старые бэкапы, ненужные файлы), но тут, как я понял, нужно было прибить каталог и запустить реплику, то есть по факту создать этот каталог заново и писать в него.
MasMaX
02.02.2017 09:50ммм… а как это сделать? подкинете рецепты? или это конкретно про postgres?
instingt
02.02.2017 14:12Это про что угодно. Самая простая реализация — подмена команды rm на запись пути в файл. По крону скрипт хватает эти пути и начинает удалять. Дальше навороты, как хотим (проверка прав на удаление и все, что придет в голову)
Dreyk
02.02.2017 15:03исходные файлы опять-же надо мувать из исходной папки, что может быть недопустимо из-за нехватки места
stranger777
01.02.2017 20:51+13сделал rm -rf на db1.cluster.gitlab.com вместо db2.cluster.gitlab.com
Из этого извлекаем урок: нельзя, нельзя, нельзя так похоже именовать продакшн с репликами, тестовыми машинами и пр…Envek
01.02.2017 22:22+2А как их тогда называть? А как их переименовывать при failover'е?
easyman
01.02.2017 22:41У них же в доке написаны планы!
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 rsyncEnvek
01.02.2017 23:40+4Вот судя из доков, они не собираются ничего переименовывать, только выводить полное имя хоста в заголовок окна с терминалом и подкрашивать заголовок окна терминалов с продакшеном в красный цвет.
ainoneko
02.02.2017 07:51подкрашивать заголовок окна терминалов с продакшеном в красный цвет.
Может, не только заголовок окна, но и саму «prompt-строчку»?bkotov
02.02.2017 10:25Скорее всего. Я так делал с этой целью. Просто насоздавал .terminal ярлычков. При нажатии запускается подключение к нужному серверу, окошко терминала окрашено красным для live и другими цветами для других инстансов. Сразу же можно задать какие-нибудь комманды для выполнения. Например сквозное подключение через несколько промежуточных серверов.
TimsTims
02.02.2017 11:29+1они не собираются ничего переименовывать
было: db2.cluster.gitlab.com
станет: db1.staging.gitlab.com
Deosis
02.02.2017 07:07+3По документу у них были ещё db1.staging.gitlab.com и db2.staging.gitlab.com, а в консоли выводилось >username@db1:
Так что перепутать окошко и написать не туда запросто. Лучше бы подключили дротики с транквилизатором, срабатывающим на «rm -rf»
Iqorek
02.02.2017 00:34+4Можно поздравить gitlab с присоединением к клубу тех, кто не только делает бекап, но и проверяет, что с него можно восстановиться.
p4s8x
02.02.2017 01:24-1А если по теме? Как все-таки мониторить бэкапы? После долгих скитаний в поисках софта — остановились мы на BareOS.
Заставить её проверять на «0 байт» можно, а вот как проверять, что «файл обновился» (актуально например для Redis- snapshot'ов)
teterkin
02.02.2017 12:42Для Veritas Cluster есть интересное решение, которое я внедрял несколько лет назад. Называется FireDrill.
Там на второй площадке (куда идет аппаратное зеркалирование), делается мгновенная копия данных, т. н. снапшот (предварительно переводя базу в режим горячего резервного копирования).
Этот снапшот монтируется на резервной площадке, в базе меняется IP на резервный, поднимается база, проверяется как нужно, хоть с привлечением операционисток. После проверки, база опускается, отмонтируется и удаляется автоматом. Таким образом мы можем быть уверены, что в случае чего, база нормально поднимется на резервной площадке.
le1ic
02.02.2017 06:07-10По-хорошему техническое руководство (не знаю, что у них там — CTO, VP of Engineering) должны быть уволены со сгоранием опционов, или как минимум сами уволиться.
SurfCalavera
02.02.2017 12:43+8Ага, и еще попросить всю поддержку рассчитаться по порядку и каждого десятого расстрелять. И CEO тоже пусть акционеры погонят поганой метлой. Что б все знали, что здесь не шутки, а серьезная компания.
Ну вот откуда такая любовь к монголо-татарским методам мотивации? Подобные инциденты случаются сплошь и рядом, и чаще всего по недосмотру или ошибке рядового сотрудника даже в организациях со строгими процессами. На каждый инцидент CTO не напасешься. Понятное дело за систематические проблемы и неспособность исправить ситуацию, но это не тот случай мне кажется. Отлично отреагировали, проблема решается, выводы вроде бы сделали (надеюсь в том числе и что не дело до полуночи ковырять на живую продакшн человеку после полного рабочего дня)
Ну и хорошая картинка из блога ГитЛаб
varanio
02.02.2017 13:13+1то, что не проверяли бекапы на восстанавливаемость — это как раз-таки системная ошибка.
SurfCalavera
02.02.2017 13:47с одной стороны вы правы — там много к чему есть вопросы (в том числе в первую очередь к недостаточно заметной индикации где работаем — в продакшн или в реплике, да и в первую очередь к режиму администрирования )
но это «стартап» все же, со всеми сопутствующими недостатками: команда небольшая, главное динамика, побыстрее выкатывать новые фичи. Одновременно идет maturity процессов и набор опыта поддержки в команде и руководстве, но это вообще не приоритет сам по себе.
А уж учитывая как отреагировали, построив на этом дополнительную рекламу и product awareness, так и совсем все неплохо по бизнес модели.
Если б такая история произошла на, скажем, нефтеперерабатывающем предпиятии, то другое дело, я б первый за покарать причастных был бы (да и то CTO все ж сильный заход), но здесь…
кстати вот вчера кто-то Instagram немножко уронил базы и у людей массово пропали профили, фоточки и лайки к фоточкам — представляете какое горе в мировом масштабе случилось.
Только сейчас начало все обратно восстанавливаться. Ну увольнять Instagram СТО и VP Engineering за это? не думаю.
ximaera
02.02.2017 15:14Нефтеперерабатывающий стартап — это такое себе, знаете ли.
SurfCalavera
02.02.2017 16:22не нефтепереабатывающий, а на нефтеперерабатывающем предпиятии. их не так много конечно как «Безопасных месснджеров», но вполне достаточно — SCADA, мониторинг и анализ и т.д.
Я думаю нефтеперерабатывающим стартапом компетентные органы заинтересуются прям на этапе гаражной хим.лаборатории, по сигналу соседей.
le1ic
02.02.2017 20:17+1При чем здесь поддержка? Я, заметьте, даже админа не предлагал уволить.
Почему вы называете это инцидентом? Инцидент это — админ порушил базу. А тут абсолютное наплевательство и халатность на протяжении продолжительного времени. Зачем иметь семь уровней бэкапов из которых ни один не работает? И как так получилось, что никто об этом не знал?
Есть такая вещь как ответственность. Если ты министр и превысил скорость — подаешь в отставку. Мне такое понятие о профессионализме и гордости гораздо ближе.
andreymal
02.02.2017 13:31И вместо них придут те, кто бэкапы «ещё не делает», ага
И вообще всё наоборот:
Только что мы отдали миллион за его учебу, за его ошибку, которую он, будучи адекватным и рациональным человеком, больше никогда не допустит! Эта трата была инвестицией в его учебу, и глупо будет увольнять этого человека, отдавать его другой компании, после такого дорогостоящего обучения.
sotnikdv
02.02.2017 07:05+2Одна из причин, почему я обычно не удаляю, а переименовываю или перемещаю, если место не жмет. И потом, если уже все точно хорошо, удаляю.
Также для ребят это знак, что с бекапами у них все плохо.
Shit happens, для такого сервиса это, конечно, не очень хорошо смотрится, но все случается.
MooNDeaR
02.02.2017 12:49Я вот так однажды случайно убил всю документацию по контрагентам за 5 лет, а бекапы не развертывались. В итоге спасла мега случайность — за несколько дней до этого я добавлял оперативки в сервер и чтобы на меня бухгалтерия не ругалась эти 20 минут, я сделал копию этих документов у себя на компе и сделал им доступ по локалке. Оттуда я их и восстановил, т.к. тупо забыл их удалить с компа.
MountyPiton
02.02.2017 13:12А почему они пользовали pg_dump то? У PostgreSQL есть же «Making a Base Backup Using the Low Level API» который обалденно работает.
kemko
02.02.2017 15:07Они использовали pg_dump наравне с некоторыми другими техниками создания резервных копий. Однако, в какой-то момент они перешли на Postgres 9.6, а на той виртуалке, с которой должен был запускаться pg_dump остался 9.2. В итоге из-за несовместимости версий дампы создавались длиной в несколько байт, но этого никто не замечал.
MountyPiton
02.02.2017 16:42Я это понял. Я скорее к тому что используя cron+ pg_start_bakcup->rsync базы->pg_stop_backup->rsync archivelogs на такие проблемы тяжелее нарваться. Вроде бы очевидное решение, которое рождается из прочтения документации по продукту. База не ложится в этот момент, все работает, нужно немного доп.пространства под archivelogs на месте куда льется бекап и на самом сервере с базой. И восстановление занимает намного меньше времени чем разворачивание дампа. Тупо время которое занимает копирование всего этого добра обратно на сервер и запуск служб.
Envek
02.02.2017 22:16Сейчас уже есть вместо этой связки pg_basebackup, который делает именно это (и ещё пару полезных фич), и он же используется при первичной настройке репликации.
Правда, гад, ругается, когда его просят в непустой каталог скопировать, после чего и происходит
rm -rf:-)MountyPiton
03.02.2017 09:44pg_basebackup собсно выполняет cp каталога базы куда скажут. Который /var/lib/psql/data (например). Но это потребует еще месте на серваке куда сложить этот бекап. А описанное мной выше позволяет сразу утаскивать базу куда надо. Если речь идет о размере в 300 GiB то еще куда не шло. Хотя есть такие места что и лишних 300 GiB нету. А если надо таких 5-10 баз бекапить или там база 1 TiB и выше то уже место экономить неплохо.
impwx
Ох не завидую я товарищу…
Бегемот.jpg
BigD
Он обрёл неоценимый опыт.
shifttstas
Ну как опыт…
stormit
Win332
Как сообщают представители GitLab, «кто-то просто совершил ошибку, и не будет уволен».
RussianNeuroMancer
Всё-таки это ошибка всей команды:
> из 5 бекапов/техник репликации ничего не сработало
hdfan2
polar11beer
У семи нянек дитя без глазу.
Каждая думает, что другие подстрахуют, случись чего.
DrLivesey
А у четрынрадцати без двух.
Недавно была статья про то, что бэкапы надо проверять. Интересно, кто-нибудь вообще понимает почему из 5 бэкапов/техник ничего не сработало?
evocatus
Так пишут когда этот кто-то — менеджер. На канале @addmeto писали, что кто-то увлекся devops'изацией и решил, что админа не нужны
ksenobayt
Этот «кто-то» — YP, упоминаемый в гуглодоксе, Yorick Peterse (https://yorickpeterse.com/)
Как сейчас гласит его профиль на Gitlab, он работает у них в качестве «Database (removal) Specialist». Так что несмотря на то, что отгребёт он абсолютно точно, да и сам, судя на его послужной список, он должен корить себя немало, отнеслись они с определённым юмором к ситуации.
Ну и увольнять человека действительно тут не за что. Всё могло закончиться гораздо хуже, если б он щёлкал клювом, а не немедленно выдернул всех и вся.
ximaera
Бедный Йорик.
MockBeard
poor Yorick )
Aingis
Yorick the Poor
MrShoor
Yorick of the Poor
PsyHaSTe
Ну так removal specialist, ничего удивительного.
ksenobayt
Надо было выделить курсивом «removal». Это добавили вчера, что должно говорить о том, с каким юмором они на всё это смотрят.
foxmuldercp
Ну человеческий фактор, с кем не бывает.
У меня еще во время работы в одном из операторов связи по адской жаре оракловод ошибся сервером и тоже дропнул базу боевого билинга, ничего не сломалось, данные собирались, ждали пока поднимется мастер из бекапов с ленточки. При грамотной инфраструктуре — это слабозаметный на потере данных факап.
SurfCalavera
За битого двух небитых дают. Плюс удобняя оказия научится на чужих ошибках.
я думаю мы увидим полезный выход из этой ситуации, с разборкой полетов и где стоит подстилать соломку.
yosemity
Да что тут смотреть-то? Так-то парни откровенно аццки зафейлили, если у них ни один бекап из 5 не делался и они не проверяли бекапы. Вывод один — проверяйте бекапы.
BlackRaven86
Старая шутка про 3 стадии системного администратора:
sumanai
Это суровая реальность.
kamtec1
На все 100% правы — проблема чтоб дойти до 3 надо пройти Крым, Рым и медные трубы — чтоб запомнилось .
Jokerjar
А также 3 типа системного администратора:
1) Делает бекапы;
2) Не делает бекапы;
3) Уже делает бекапы.
zorgzerg
Все же два:
1. Еще не делает
2. Уже делает
))
tgz
1. Еще не делает
2. Уже не делает
sborisov
3. Делает и проверяет, что они рабочие.
tgz
Зануды могут испортить любую шутку.
Vlad_2016
Вообще-то, когда сам был этаким ДБА/девелопером, всегда перед подобными действами РУКАМИ делал бэкап. «Если у вас не паранойи, то это не значит, что за вами не наблюдают»
lubezniy
А сколько времени делается бэкап на больших проектах?
Vlad_2016
Да когда как… Но всяко меньше, чем пляска с бубном под умершей базой. Рекорд — двое суток без сна… А бекап — до часа…
lubezniy
Везёт… у меня на проекте он часов 10 только делается. Хотя восстанавливать, конечно, долго.
Cubus
У меня хранилище в 50Тб бэкапилось 43 часа на ленточную библиотеку. Когда перешли на EMC DataDomain, стали укладываться в сутки. Это был кайф :)
Zolotoys
DataDomain + Rman + boost и жизнь становится прекрасной
Archon
При устранении сбоя удаление файлов вообще не должно производиться нигде и никогда (ну, кроме ситуации «кончилось место на дисках», которая в нормальном продакшене встречаться не должна). Всё, что по запаре кажется не нужным на боевом сервере, должно перемещаться во временный, специально созданный для данного случая каталог, и разгребаться уже после восстановления. А то в условиях стресса можно настолько хорошо всё поудалять, что потом половину удалённого придётся поднимать с ленты, а вторую половину переписывать руками.
Vlad_2016
Вообще-то мы вроде как говорим о классических СУБД, а флет-тэйбл системы — да как угодно хранить можно. Вот только со стрессом к активным мероприятим на базе лучше не приступать — череповато…
Archon
А что, классические СУБД не оставляют на диске файлы, которые можно удалить? Насколько я понял из статьи, инженер как раз не дропнул базу, а именно что остановил процесс и удалил файлы с данными (и как раз-таки не одну таблицу, а всё целиком).
Мой комментарий скорее был не про ДБА, а про админов в целом. Спору нет, без холодной головы ДБА долго в профессии не держится.
Vlad_2016
Гм… Как бы поточнее сказать… Пока база активна, то фих удалишь.
erge
«остановил процесс»