Comments 165
Ох не завидую я товарищу…
Бегемот.jpg
Бегемот.jpg
Он обрёл неоценимый опыт.
Ну как опыт…
Как сообщают представители GitLab, «кто-то просто совершил ошибку, и не будет уволен».
Всё-таки это ошибка всей команды:
> из 5 бекапов/техник репликации ничего не сработало
> из 5 бекапов/техник репликации ничего не сработало
Так пишут когда этот кто-то — менеджер. На канале @addmeto писали, что кто-то увлекся devops'изацией и решил, что админа не нужны
Этот «кто-то» — YP, упоминаемый в гуглодоксе, Yorick Peterse (https://yorickpeterse.com/)
Как сейчас гласит его профиль на Gitlab, он работает у них в качестве «Database (removal) Specialist». Так что несмотря на то, что отгребёт он абсолютно точно, да и сам, судя на его послужной список, он должен корить себя немало, отнеслись они с определённым юмором к ситуации.
Ну и увольнять человека действительно тут не за что. Всё могло закончиться гораздо хуже, если б он щёлкал клювом, а не немедленно выдернул всех и вся.
Как сейчас гласит его профиль на Gitlab, он работает у них в качестве «Database (removal) Specialist». Так что несмотря на то, что отгребёт он абсолютно точно, да и сам, судя на его послужной список, он должен корить себя немало, отнеслись они с определённым юмором к ситуации.
Ну и увольнять человека действительно тут не за что. Всё могло закончиться гораздо хуже, если б он щёлкал клювом, а не немедленно выдернул всех и вся.
Ну человеческий фактор, с кем не бывает.
У меня еще во время работы в одном из операторов связи по адской жаре оракловод ошибся сервером и тоже дропнул базу боевого билинга, ничего не сломалось, данные собирались, ждали пока поднимется мастер из бекапов с ленточки. При грамотной инфраструктуре — это слабозаметный на потере данных факап.
За битого двух небитых дают. Плюс удобняя оказия научится на чужих ошибках.
я думаю мы увидим полезный выход из этой ситуации, с разборкой полетов и где стоит подстилать соломку.
я думаю мы увидим полезный выход из этой ситуации, с разборкой полетов и где стоит подстилать соломку.
Да что тут смотреть-то? Так-то парни откровенно аццки зафейлили, если у них ни один бекап из 5 не делался и они не проверяли бекапы. Вывод один — проверяйте бекапы.
Старая шутка про 3 стадии системного администратора:
- Не делает бекапы.
- Делает бекапы.
- Делает бекапы и проверяет восстановление.
UFO just landed and posted this here
На все 100% правы — проблема чтоб дойти до 3 надо пройти Крым, Рым и медные трубы — чтоб запомнилось .
А также 3 типа системного администратора:
1) Делает бекапы;
2) Не делает бекапы;
3) Уже делает бекапы.
1) Делает бекапы;
2) Не делает бекапы;
3) Уже делает бекапы.
Вообще-то, когда сам был этаким ДБА/девелопером, всегда перед подобными действами РУКАМИ делал бэкап. «Если у вас не паранойи, то это не значит, что за вами не наблюдают»
А сколько времени делается бэкап на больших проектах?
При устранении сбоя удаление файлов вообще не должно производиться нигде и никогда (ну, кроме ситуации «кончилось место на дисках», которая в нормальном продакшене встречаться не должна). Всё, что по запаре кажется не нужным на боевом сервере, должно перемещаться во временный, специально созданный для данного случая каталог, и разгребаться уже после восстановления. А то в условиях стресса можно настолько хорошо всё поудалять, что потом половину удалённого придётся поднимать с ленты, а вторую половину переписывать руками.
Вообще-то мы вроде как говорим о классических СУБД, а флет-тэйбл системы — да как угодно хранить можно. Вот только со стрессом к активным мероприятим на базе лучше не приступать — череповато…
А что, классические СУБД не оставляют на диске файлы, которые можно удалить? Насколько я понял из статьи, инженер как раз не дропнул базу, а именно что остановил процесс и удалил файлы с данными (и как раз-таки не одну таблицу, а всё целиком).
Мой комментарий скорее был не про ДБА, а про админов в целом. Спору нет, без холодной головы ДБА долго в профессии не держится.
Мой комментарий скорее был не про ДБА, а про админов в целом. Спору нет, без холодной головы ДБА долго в профессии не держится.
Кто-нибудь нашёл информацию о том, чем им не подошёл lvm-снапшот, который был случайно сделан руками примерно в то же время, что и тот staging, с которого сейчас сливается база (и, если я правильно понял, был сделан на боевой базе)? В снапшоте же небось и вебхуки есть, которых нет на staging.
Как я понял они его сейчас и разворачивают, ведь других-то нет.
В документе, на который ссылается топикстартер сказано следующее: 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 ещё ответит.
Кто то уже подсуетился и сделал 1 февраля выходным днем проверки бекапов: http://checkyourbackups.work/
стримят процесс восстановления
Парни молодцы, что вот такой мегафейл не скрыли да еще и трансляцию замутили. Сообщество такое любит, им простят.
есть шанс превратить мегафейл в хорошую рекламу
типа, мы облажались, но сделали выводы, и теперь у нас всё с 20-кратным резервированием и перед сном админы обязаны петьотче наш регламент резервного копирования
типа, мы облажались, но сделали выводы, и теперь у нас всё с 20-кратным резервированием и перед сном админы обязаны петь
>> * The audio is too low, can you fix it?
>No, we're sorry.
Я правильно понимаю, что они не смогли включить усилок микрофона?
>No, we're sorry.
Я правильно понимаю, что они не смогли включить усилок микрофона?
во всем виноват постгре! ;)
UFO just landed and posted this here
Красиво однако.
Не ради рекламы, но AWS RDS PostgreSQL тут был бы в самый раз.
Доступа к файловой системе нет, т.е. ошибка такая исключена.
+ снимаются снэпшоты
+ можно снимать исторические данные и класть в S3, что конечно сложно при базе весом 300+ GiB. Можно снимать с read реплики.
Доступа к файловой системе нет, т.е. ошибка такая исключена.
+ снимаются снэпшоты
+ можно снимать исторические данные и класть в S3, что конечно сложно при базе весом 300+ GiB. Можно снимать с read реплики.
Без относительно этого продукта но про postgres — существует ли возможность получать дифф-снапшоты в виде выгружаемого файла (не важно — какой то внутренний бинарный формат или высокоуровневый sql-дамп), для выгрузки на сторонний сервер? А то 300Gb за раз выгрузить многовато и очень дорого… а конечная база могла бы быть восстановлена на основе одной из локальных старых копий и серии патчей-снапшотов.
Конечно, можно архивировать WAL и потом его накатывать.
Вы говорите про архивирование журнала транзакций, позволяет делать именно это. А так же позволяет откатывать базу на произвольные моменты времени, делать «параллельные вселенные» и прочее.
Документация: https://postgrespro.ru/docs/postgrespro/9.6/continuous-archiving.html
Стоимость решения сильно выше, чем у dedicated hardware
Хороший инстанс+Multi-AZ+хотя бы одна read-replica+снэпшоты
Да, в итоге выходит дорого. «Чуть» дешевле если берёшь Reserved instance на год(или на 3).
Как плюс — Избавляешься от проблем с обновлением PostgreSQL и обслуживанием железа.
Из минусов — цена и то что роль rds_superuser(высшая доступная привилегия) «немного» кастрированная.
Да, в итоге выходит дорого. «Чуть» дешевле если берёшь Reserved instance на год(или на 3).
Как плюс — Избавляешься от проблем с обновлением PostgreSQL и обслуживанием железа.
Из минусов — цена и то что роль rds_superuser(высшая доступная привилегия) «немного» кастрированная.
Мы недавно прикидывали, правда для mysql. Если взять вместо нашего сервера (2xXeon E5-2600 & 256Gb RAM) соответствующий инстанс в AWS, то стоимость возрастает почти в 10 раз, с 350 до 3000 евро в месяц (и это ещё не считая стоимости трафика)
У вас ценник немного завышен. Посмотрите сервера в online.net :)
И что же я там увижу?
Из сопоставимых только такой, но с хреновыми дисками, а у нас SAS
2x Intel® Xeon® E5 2660 v4 / 256 GB DDR4 — 319 EUR
Но и этого сервера нет в наличии. Так что давайте не будем умничать и раздавать непрошенные советы? Я не хуже вашего знаком с европейским и американским рынком dedicated
Из сопоставимых только такой, но с хреновыми дисками, а у нас SAS
2x Intel® Xeon® E5 2660 v4 / 256 GB DDR4 — 319 EUR
Но и этого сервера нет в наличии. Так что давайте не будем умничать и раздавать непрошенные советы? Я не хуже вашего знаком с европейским и американским рынком dedicated
И что же я там увижу?
Из сопоставимых только такой, но с хреновыми дисками, а у нас 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 евро только вчера были
Америку не предлагаю, там все еще пичально.
Зачем мне 3 диска? Собрать колченогий RAID5? Спасибо, но у нас 10-ый RAID, да и по стораджу маловато, на этих серверах по 8 дисков 600Gb SAS 15k.
Что вы мне пытаетесь доказать? Я не побегу сломя голову ставить db-сервера на другой площадке из-за призрачной экономии в пару десятков евро
Что вы мне пытаетесь доказать? Я не побегу сломя голову ставить db-сервера на другой площадке из-за призрачной экономии в пару десятков евро
В следующий раз пишите более четко, какие сервера вы сравниваете с AWS.
Один из главных параметров упустили и все, получили сферического коня в вакууме.
Один из главных параметров упустили и все, получили сферического коня в вакууме.
В следующий раз пишите более четко
Простите, вы уху ели? Я вас вообще ни о чем не спрашивал, никаких расчётов вам не заказывал и в ваших пионерских советах «как сэкономить 20 евро» не нуждался. Я сравнивал ценник на сопоставимые серверные ресурсы. Разница почти в 10 раз, этого достаточно, чтобы не использовать AWS под эти задачи. И всё. Ступайте себе с миром и не морочьте голову. Dixi
Я сравнивал ценник на сопоставимые серверные ресурсы. Разница почти в 10 раз
Простите, оценку надо делать полную, а не выдернутую из контекста.
Пока что я у вас вижу голословную конфигурацию
2xXeon E5-2600 & 256Gb RAMи забытые — тип винтов, их кол-во и IOPS массива. А только потом сравнивать с аналогами AWS.
Серверу уже небось года два, хостер давно отбил стоимость железа, взяв еще вначале львиную долю за первоначальный сетап нестандартной конфигурации.
И теперь только радуется, что такой неповоротливый клиент платит лишние 100-150 евро каждый месяц :)
Сервер один? не страшно эксплуатировать?
Хм, у нас RDS с multi-az mirroring, и трижды за последний год случались серьезные факапы с БД в которых failover не спас.
лайв стрим гитлаба https://www.youtube.com/watch?v=nc0hPGerSd4
Да, печалька, видимо отвлекся парень…
У меня как-то было похожий случай. Попросили обнулить цену в базе на один продукт, ну и в процессе обновления цены меня отвлекли и я забыл дописать where к запросу (UPDATE products SET price = 0)… Ну и улетели цены на ~1кк продуктов…
Бакап спас в итоге :)
У меня как-то было похожий случай. Попросили обнулить цену в базе на один продукт, ну и в процессе обновления цены меня отвлекли и я забыл дописать where к запросу (UPDATE products SET price = 0)… Ну и улетели цены на ~1кк продуктов…
Бакап спас в итоге :)
На продакшене надо стартовать транзакцию, потом делать апдейт. Тогда, если увидишь «обновлено 100500 строк», то просто пишешь rollback
Ага… Зеленый был я тогда…
А насколько так лучше/хуже поступать чем сразу прописывать begin tran… изменения… rollback tran, смотреть результат, может даже несколько раз прогонять, проверяя результат селектами внутри транзаккции и если всё ок, менять rollback на commit и прогонять уже финально? А то я именно так всегда делаю, вроде множество быстрых транзакций — меньшее зло чем она длинная, или нет?
Селектами удобно проверять перед update ) Да и можно конечно на тест сервере\тест базе испробовать — тоже учился на своих и на чужих ошибокам
Целиком и полностью поддерживаю. Семь раз проверь, один раз закоммить.
Еще хорошо перед выполнением внимательно проверить к какой базе подключился, сделать select * from global_name, убедиться, что база точно та, и, лишь потом, выполнять-коммитить. Это, конечно, для совсем параноиков :)
Ну и обязательно автокоммит выключить, эта мера может спасти от многих ошибок, если первые пункты забыл сделать)
Еще хорошо перед выполнением внимательно проверить к какой базе подключился, сделать select * from global_name, убедиться, что база точно та, и, лишь потом, выполнять-коммитить. Это, конечно, для совсем параноиков :)
Ну и обязательно автокоммит выключить, эта мера может спасти от многих ошибок, если первые пункты забыл сделать)
Не всегда это возможно. Во многих случаях в транзакции имеем блокировку строк/таблицы и клиенты стоят ждут когда транзакция закроется в ту или иную сторону… а мы тут 5 минут проверяем всё ли хорошо.
а в это время этой же базой пользуются клиенты
и запросы по таймауту валятся
в конце концов ловишь что-то вроде дедлока и запрос проваливается
либо просто бесконечно долго делается — а всё это время сайт лежит
я недавно пытался индексы перевесить после неудачной миграции — пришлось положить сайт дважды…
в общем, это всегда печально(
и запросы по таймауту валятся
в конце концов ловишь что-то вроде дедлока и запрос проваливается
либо просто бесконечно долго делается — а всё это время сайт лежит
я недавно пытался индексы перевесить после неудачной миграции — пришлось положить сайт дважды…
в общем, это всегда печально(
Такая ситуация с каждым разработчиком, наверное, случалась. Как правило, она случается только раз :) А SSMSBoost вообще подтверждение запрашивает перед выполнением подобных запросов без where.
Любой апдейт начинать проверять с
begin tran
…
rollback
Потом внутри вставляем
1. Отбор записей по условию
2. Апдейт
3. Отбор записей по условию (обновленных)
Если все ок, то апдейт с коммитом
Ну а у Оракла понравилось то, что он по умолчанию транзакции не коммитит. Сначала удивился конечно
begin tran
…
rollback
Потом внутри вставляем
1. Отбор записей по условию
2. Апдейт
3. Отбор записей по условию (обновленных)
Если все ок, то апдейт с коммитом
Ну а у Оракла понравилось то, что он по умолчанию транзакции не коммитит. Сначала удивился конечно
Аххаха точно такое же недавно было. Вышел в понедельник с бодуна называется.
Вроде как и забавная ситуация перепутать мастер и реплику, но на прошлой неделе была похожая ситуация, от того не смешно.
UFO just landed and posted this here
Очередной мем — Ждун.
Первоисточник вроде бы здесь: Ожидание врача
Прочитал внимательно, что произошло с GitLab’ом и почувствовал жгучее дежа вю. Ведь буквально две-три недели тому я подымал репликацию на рабочем проекте (с всего лишь в два раза меньшей базой) и у меня тоже с первой попытки pg_basebackup не завёлся, я ругнулся, перезапустил его, теперь он ругнулся, что папка назначения не пустая, я снова ругнулся, сделал rm -rf /var/lib/postgresql/9.5/main и снова его запустил. Всё отличие только в том, что мне повезло больше того парня и я не перепутал будущую реплику с мастером при этом.
Тут могла бы быть шутка про… э-э-э некоторых хакеров.
Но не буду — ибо и так всё печально.
Но не буду — ибо и так всё печально.
Мой комент о нешутке «оценили»! — Есть ещё гики на хабре (С) :-)
UFO just landed and posted this here
raacer:
Бают норвеги собираются считать бюллетени на ближайших своих выборов вручную. — Ибо они их бояться.
Здесь мог быть ответ на Ваш комментарий. Но его, конечно же, тоже не будет по понятным причинам.
Бают норвеги собираются считать бюллетени на ближайших своих выборов вручную. — Ибо они их бояться.
Я вот не совсем понял. Есть мастер база, данные льются по реплике на стендбай, вроде все ок. Дальше мы берем и стопнув инстанс базы на мастере удаляем дб файлы там же. Но на стендбай же это никак не отразилось! Если б он не «rm -rf», а «drop database» сделал, тогда да, реплики не спасают, но сдесь то как?
Реплика была одна и очень сильно глючила (отставала), насколько я понял
Со своими не ахти какими знаниями английского я так понял, что сильно глючащую реплику почистили для перезапуска, оставив пустой каталог, перезапуск зафейлился, решили удалить оставшийся пустой каталог, но ошиблись окошком и удалили непустой на мастере, по графику это видно (db2 реплика, db1 мастер)
Скрытый текст
уже есть, не заметил (
Они всего лишь обычные люди.
Пусть ломают. Лишь бы учились.
Не оставляло чувство до конца прочтения всех комментов, что сегодня 1 апреля
Я на проде использую mv вместо rm по возможности.
А почему бы не называть хосты по-человечески? Master-db, Replica-db. В этой ситуации бы спасло. И сделать rm «медленным», откладывая реальное удаление на ощутимый для «одуматься» срок.
Не спасло бы, потому что всё равно никто не читает PS1, проверено на себе))
UFO just landed and posted this here
удаление перемещением в корзину
В linux нет корзинки
а lost+found тогда что? или вы наверное не в курсе? :)
Ну как же нет, на Ubuntu точно встречал каталог «Trash», который работал так же, как виндовая корзина.
Это корзина для оконного интерфейса, если удаляешь через Nautilus или подобный файловый менеджер. В консоли нет корзины, rm удаляет сразу в /dev/null.
Эта корзина ведёт себя точно также, как и виндовая, которая тоже по сути «корзина для оконного интерфейса». Можете убедиться, удалив файл в винде через командную строку «del -F test.txt».
Еще раз:
Консольная команда rm удаляет файлы напрямую без корзин. В MC удаление так же идет напрямую.
А оконным интерфейсом на серверах не пользуются.
Консольная команда rm удаляет файлы напрямую без корзин. В MC удаление так же идет напрямую.
А оконным интерфейсом на серверах не пользуются.
Я лишь ответил на ваше утверждение «В linux нет корзинки», которое не верно — корзина там есть, такая же как и на винде. Как именно и кто удаляет файлы у себя на серверах — дело десятое.
Но в linux нет корзины. Она есть в дистрибутивах с GUI
У Вас с предыдущим комментатором рассинхронизация:
Germanets имел в виду что и в винде корзина только для GUI.
А консольные команды точно так же удаляют всё подчистую
Germanets имел в виду что и в винде корзина только для GUI.
А консольные команды точно так же удаляют всё подчистую
Ставить задачу на удаление. Раз в n времени бежит воркер и выполняет задачи на удаление. Это канает, когда нужно удалить и уйти (старые бэкапы, ненужные файлы), но тут, как я понял, нужно было прибить каталог и запустить реплику, то есть по факту создать этот каталог заново и писать в него.
Мастер-реплика видимо не называли, так как они иногда менялись ролями
Перфоратор не в ту розетку воткнули.
https://youtu.be/nc0hPGerSd4 — livestream процесса восстановления.
сделал rm -rf на db1.cluster.gitlab.com вместо db2.cluster.gitlab.com
Из этого извлекаем урок: нельзя, нельзя, нельзя так похоже именовать продакшн с репликами, тестовыми машинами и пр…
А как их тогда называть? А как их переименовывать при failover'е?
У них же в доке написаны планы!
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
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
Вот судя из доков, они не собираются ничего переименовывать, только выводить полное имя хоста в заголовок окна с терминалом и подкрашивать заголовок окна терминалов с продакшеном в красный цвет.
подкрашивать заголовок окна терминалов с продакшеном в красный цвет.
Может, не только заголовок окна, но и саму «prompt-строчку»?
Скорее всего. Я так делал с этой целью. Просто насоздавал .terminal ярлычков. При нажатии запускается подключение к нужному серверу, окошко терминала окрашено красным для live и другими цветами для других инстансов. Сразу же можно задать какие-нибудь комманды для выполнения. Например сквозное подключение через несколько промежуточных серверов.
они не собираются ничего переименовывать
было: db2.cluster.gitlab.com
станет: db1.staging.gitlab.com
По документу у них были ещё db1.staging.gitlab.com и db2.staging.gitlab.com, а в консоли выводилось >username@db1:
Так что перепутать окошко и написать не туда запросто. Лучше бы подключили дротики с транквилизатором, срабатывающим на «rm -rf»
Так что перепутать окошко и написать не туда запросто. Лучше бы подключили дротики с транквилизатором, срабатывающим на «rm -rf»
Ожил.
Можно поздравить gitlab с присоединением к клубу тех, кто не только делает бекап, но и проверяет, что с него можно восстановиться.
А если по теме? Как все-таки мониторить бэкапы? После долгих скитаний в поисках софта — остановились мы на BareOS.
Заставить её проверять на «0 байт» можно, а вот как проверять, что «файл обновился» (актуально например для Redis- snapshot'ов)
Заставить её проверять на «0 байт» можно, а вот как проверять, что «файл обновился» (актуально например для Redis- snapshot'ов)
Для Veritas Cluster есть интересное решение, которое я внедрял несколько лет назад. Называется FireDrill.
Там на второй площадке (куда идет аппаратное зеркалирование), делается мгновенная копия данных, т. н. снапшот (предварительно переводя базу в режим горячего резервного копирования).
Этот снапшот монтируется на резервной площадке, в базе меняется IP на резервный, поднимается база, проверяется как нужно, хоть с привлечением операционисток. После проверки, база опускается, отмонтируется и удаляется автоматом. Таким образом мы можем быть уверены, что в случае чего, база нормально поднимется на резервной площадке.
Там на второй площадке (куда идет аппаратное зеркалирование), делается мгновенная копия данных, т. н. снапшот (предварительно переводя базу в режим горячего резервного копирования).
Этот снапшот монтируется на резервной площадке, в базе меняется IP на резервный, поднимается база, проверяется как нужно, хоть с привлечением операционисток. После проверки, база опускается, отмонтируется и удаляется автоматом. Таким образом мы можем быть уверены, что в случае чего, база нормально поднимется на резервной площадке.
ZFS и штук 5 строчек кода в скрипте помогут это реализовать на коленке :)
Возможно я скажу что-то очевидное но… проверка такая например — штатная фича Veeam Backup & Replication.
Виртуалки поднимаются прямо из бекапа (можно настроить чтобы они не жрали столько памяти) в изолированной среде (а можно и не совсем изолированной), проверяется прописанные админом вещи (по умолчанию — что оно вообще отвечает по сети и vmware tools запускаются + что файл бекапа реально читается. в условиях когда и этого нет — это преимущество а можно сделать сложные скрипты проверки + сразу поднимать группы виртуалок).
На хабре были статьи даже как эта штука настраивается в базовом варианте.
При этом не нужно ничего кроме VMware/Hyper-V кластера (хотя завести на посмотреть можно и на одном хосте) ну и Veeam'а с платной лицензией.
Снапшоты разумеется Veeam умеет делать, несколькими разными способами (сильно зависит от того — что мы понимаем под снапшотом и что умеет делать хранилище)
Виртуалки поднимаются прямо из бекапа (можно настроить чтобы они не жрали столько памяти) в изолированной среде (а можно и не совсем изолированной), проверяется прописанные админом вещи (по умолчанию — что оно вообще отвечает по сети и vmware tools запускаются + что файл бекапа реально читается. в условиях когда и этого нет — это преимущество а можно сделать сложные скрипты проверки + сразу поднимать группы виртуалок).
На хабре были статьи даже как эта штука настраивается в базовом варианте.
При этом не нужно ничего кроме VMware/Hyper-V кластера (хотя завести на посмотреть можно и на одном хосте) ну и Veeam'а с платной лицензией.
Снапшоты разумеется Veeam умеет делать, несколькими разными способами (сильно зависит от того — что мы понимаем под снапшотом и что умеет делать хранилище)
UFO just landed and posted this here
Ага, и еще попросить всю поддержку рассчитаться по порядку и каждого десятого расстрелять. И CEO тоже пусть акционеры погонят поганой метлой. Что б все знали, что здесь не шутки, а серьезная компания.
Ну вот откуда такая любовь к монголо-татарским методам мотивации? Подобные инциденты случаются сплошь и рядом, и чаще всего по недосмотру или ошибке рядового сотрудника даже в организациях со строгими процессами. На каждый инцидент CTO не напасешься. Понятное дело за систематические проблемы и неспособность исправить ситуацию, но это не тот случай мне кажется. Отлично отреагировали, проблема решается, выводы вроде бы сделали (надеюсь в том числе и что не дело до полуночи ковырять на живую продакшн человеку после полного рабочего дня)
Ну и хорошая картинка из блога ГитЛаб
Ну вот откуда такая любовь к монголо-татарским методам мотивации? Подобные инциденты случаются сплошь и рядом, и чаще всего по недосмотру или ошибке рядового сотрудника даже в организациях со строгими процессами. На каждый инцидент CTO не напасешься. Понятное дело за систематические проблемы и неспособность исправить ситуацию, но это не тот случай мне кажется. Отлично отреагировали, проблема решается, выводы вроде бы сделали (надеюсь в том числе и что не дело до полуночи ковырять на живую продакшн человеку после полного рабочего дня)
Ну и хорошая картинка из блога ГитЛаб
то, что не проверяли бекапы на восстанавливаемость — это как раз-таки системная ошибка.
с одной стороны вы правы — там много к чему есть вопросы (в том числе в первую очередь к недостаточно заметной индикации где работаем — в продакшн или в реплике, да и в первую очередь к режиму администрирования )
но это «стартап» все же, со всеми сопутствующими недостатками: команда небольшая, главное динамика, побыстрее выкатывать новые фичи. Одновременно идет maturity процессов и набор опыта поддержки в команде и руководстве, но это вообще не приоритет сам по себе.
А уж учитывая как отреагировали, построив на этом дополнительную рекламу и product awareness, так и совсем все неплохо по бизнес модели.
Если б такая история произошла на, скажем, нефтеперерабатывающем предпиятии, то другое дело, я б первый за покарать причастных был бы (да и то CTO все ж сильный заход), но здесь…
кстати вот вчера кто-то Instagram немножко уронил базы и у людей массово пропали профили, фоточки и лайки к фоточкам — представляете какое горе в мировом масштабе случилось.
Только сейчас начало все обратно восстанавливаться. Ну увольнять Instagram СТО и VP Engineering за это? не думаю.
но это «стартап» все же, со всеми сопутствующими недостатками: команда небольшая, главное динамика, побыстрее выкатывать новые фичи. Одновременно идет maturity процессов и набор опыта поддержки в команде и руководстве, но это вообще не приоритет сам по себе.
А уж учитывая как отреагировали, построив на этом дополнительную рекламу и product awareness, так и совсем все неплохо по бизнес модели.
Если б такая история произошла на, скажем, нефтеперерабатывающем предпиятии, то другое дело, я б первый за покарать причастных был бы (да и то CTO все ж сильный заход), но здесь…
кстати вот вчера кто-то Instagram немножко уронил базы и у людей массово пропали профили, фоточки и лайки к фоточкам — представляете какое горе в мировом масштабе случилось.
Только сейчас начало все обратно восстанавливаться. Ну увольнять Instagram СТО и VP Engineering за это? не думаю.
Нефтеперерабатывающий стартап — это такое себе, знаете ли.
не нефтепереабатывающий, а на нефтеперерабатывающем предпиятии. их не так много конечно как «Безопасных месснджеров», но вполне достаточно — SCADA, мониторинг и анализ и т.д.
Я думаю нефтеперерабатывающим стартапом компетентные органы заинтересуются прям на этапе гаражной хим.лаборатории, по сигналу соседей.
Я думаю нефтеперерабатывающим стартапом компетентные органы заинтересуются прям на этапе гаражной хим.лаборатории, по сигналу соседей.
UFO just landed and posted this here
И вместо них придут те, кто бэкапы «ещё не делает», ага
И вообще всё наоборот:
И вообще всё наоборот:
Только что мы отдали миллион за его учебу, за его ошибку, которую он, будучи адекватным и рациональным человеком, больше никогда не допустит! Эта трата была инвестицией в его учебу, и глупо будет увольнять этого человека, отдавать его другой компании, после такого дорогостоящего обучения.
UFO just landed and posted this here
Вот это «день не задался», столько неудачных обстоятельств:
и терминал перепутал и 5 бэкапов не восстали.
и терминал перепутал и 5 бэкапов не восстали.
Я вот так однажды случайно убил всю документацию по контрагентам за 5 лет, а бекапы не развертывались. В итоге спасла мега случайность — за несколько дней до этого я добавлял оперативки в сервер и чтобы на меня бухгалтерия не ругалась эти 20 минут, я сделал копию этих документов у себя на компе и сделал им доступ по локалке. Оттуда я их и восстановил, т.к. тупо забыл их удалить с компа.
А почему они пользовали pg_dump то? У PostgreSQL есть же «Making a Base Backup Using the Low Level API» который обалденно работает.
Они использовали pg_dump наравне с некоторыми другими техниками создания резервных копий. Однако, в какой-то момент они перешли на Postgres 9.6, а на той виртуалке, с которой должен был запускаться pg_dump остался 9.2. В итоге из-за несовместимости версий дампы создавались длиной в несколько байт, но этого никто не замечал.
Я это понял. Я скорее к тому что используя cron+ pg_start_bakcup->rsync базы->pg_stop_backup->rsync archivelogs на такие проблемы тяжелее нарваться. Вроде бы очевидное решение, которое рождается из прочтения документации по продукту. База не ложится в этот момент, все работает, нужно немного доп.пространства под archivelogs на месте куда льется бекап и на самом сервере с базой. И восстановление занимает намного меньше времени чем разворачивание дампа. Тупо время которое занимает копирование всего этого добра обратно на сервер и запуск служб.
Сейчас уже есть вместо этой связки pg_basebackup, который делает именно это (и ещё пару полезных фич), и он же используется при первичной настройке репликации.
Правда, гад, ругается, когда его просят в непустой каталог скопировать, после чего и происходит rm -rf :-)
pg_basebackup собсно выполняет cp каталога базы куда скажут. Который /var/lib/psql/data (например). Но это потребует еще месте на серваке куда сложить этот бекап. А описанное мной выше позволяет сразу утаскивать базу куда надо. Если речь идет о размере в 300 GiB то еще куда не шло. Хотя есть такие места что и лишних 300 GiB нету. А если надо таких 5-10 баз бекапить или там база 1 TiB и выше то уже место экономить неплохо.
Sign up to leave a comment.
Gitlab «лежит», база уничтожена (восстанавливается)