Комментарии 165
Бегемот.jpg
> из 5 бекапов/техник репликации ничего не сработало
Так пишут когда этот кто-то — менеджер. На канале @addmeto писали, что кто-то увлекся devops'изацией и решил, что админа не нужны
Как сейчас гласит его профиль на Gitlab, он работает у них в качестве «Database (removal) Specialist». Так что несмотря на то, что отгребёт он абсолютно точно, да и сам, судя на его послужной список, он должен корить себя немало, отнеслись они с определённым юмором к ситуации.
Ну и увольнять человека действительно тут не за что. Всё могло закончиться гораздо хуже, если б он щёлкал клювом, а не немедленно выдернул всех и вся.
Ну человеческий фактор, с кем не бывает.
У меня еще во время работы в одном из операторов связи по адской жаре оракловод ошибся сервером и тоже дропнул базу боевого билинга, ничего не сломалось, данные собирались, ждали пока поднимется мастер из бекапов с ленточки. При грамотной инфраструктуре — это слабозаметный на потере данных факап.
я думаю мы увидим полезный выход из этой ситуации, с разборкой полетов и где стоит подстилать соломку.
Старая шутка про 3 стадии системного администратора:
- Не делает бекапы.
- Делает бекапы.
- Делает бекапы и проверяет восстановление.
На все 100% правы — проблема чтоб дойти до 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-кратным резервированием и перед сном админы обязаны петь
>No, we're sorry.
Я правильно понимаю, что они не смогли включить усилок микрофона?
Доступа к файловой системе нет, т.е. ошибка такая исключена.
+ снимаются снэпшоты
+ можно снимать исторические данные и класть в S3, что конечно сложно при базе весом 300+ GiB. Можно снимать с read реплики.
Вы говорите про архивирование журнала транзакций, позволяет делать именно это. А так же позволяет откатывать базу на произвольные моменты времени, делать «параллельные вселенные» и прочее.
Документация: https://postgrespro.ru/docs/postgrespro/9.6/continuous-archiving.html
Да, в итоге выходит дорого. «Чуть» дешевле если берёшь Reserved instance на год(или на 3).
Как плюс — Избавляешься от проблем с обновлением PostgreSQL и обслуживанием железа.
Из минусов — цена и то что роль rds_superuser(высшая доступная привилегия) «немного» кастрированная.
Из сопоставимых только такой, но с хреновыми дисками, а у нас 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 евро только вчера были
Америку не предлагаю, там все еще пичально.
Что вы мне пытаетесь доказать? Я не побегу сломя голову ставить db-сервера на другой площадке из-за призрачной экономии в пару десятков евро
Один из главных параметров упустили и все, получили сферического коня в вакууме.
В следующий раз пишите более четко
Простите, вы уху ели? Я вас вообще ни о чем не спрашивал, никаких расчётов вам не заказывал и в ваших пионерских советах «как сэкономить 20 евро» не нуждался. Я сравнивал ценник на сопоставимые серверные ресурсы. Разница почти в 10 раз, этого достаточно, чтобы не использовать AWS под эти задачи. И всё. Ступайте себе с миром и не морочьте голову. Dixi
Я сравнивал ценник на сопоставимые серверные ресурсы. Разница почти в 10 раз
Простите, оценку надо делать полную, а не выдернутую из контекста.
Пока что я у вас вижу голословную конфигурацию
2xXeon E5-2600 & 256Gb RAMи забытые — тип винтов, их кол-во и IOPS массива. А только потом сравнивать с аналогами AWS.
Серверу уже небось года два, хостер давно отбил стоимость железа, взяв еще вначале львиную долю за первоначальный сетап нестандартной конфигурации.
И теперь только радуется, что такой неповоротливый клиент платит лишние 100-150 евро каждый месяц :)
Сервер один? не страшно эксплуатировать?
Хм, у нас RDS с multi-az mirroring, и трижды за последний год случались серьезные факапы с БД в которых failover не спас.
У меня как-то было похожий случай. Попросили обнулить цену в базе на один продукт, ну и в процессе обновления цены меня отвлекли и я забыл дописать where к запросу (UPDATE products SET price = 0)… Ну и улетели цены на ~1кк продуктов…
Бакап спас в итоге :)
Селектами удобно проверять перед update ) Да и можно конечно на тест сервере\тест базе испробовать — тоже учился на своих и на чужих ошибокам
Еще хорошо перед выполнением внимательно проверить к какой базе подключился, сделать select * from global_name, убедиться, что база точно та, и, лишь потом, выполнять-коммитить. Это, конечно, для совсем параноиков :)
Ну и обязательно автокоммит выключить, эта мера может спасти от многих ошибок, если первые пункты забыл сделать)
и запросы по таймауту валятся
в конце концов ловишь что-то вроде дедлока и запрос проваливается
либо просто бесконечно долго делается — а всё это время сайт лежит
я недавно пытался индексы перевесить после неудачной миграции — пришлось положить сайт дважды…
в общем, это всегда печально(
begin tran
…
rollback
Потом внутри вставляем
1. Отбор записей по условию
2. Апдейт
3. Отбор записей по условию (обновленных)
Если все ок, то апдейт с коммитом
Ну а у Оракла понравилось то, что он по умолчанию транзакции не коммитит. Сначала удивился конечно
Прочитал внимательно, что произошло с GitLab’ом и почувствовал жгучее дежа вю. Ведь буквально две-три недели тому я подымал репликацию на рабочем проекте (с всего лишь в два раза меньшей базой) и у меня тоже с первой попытки pg_basebackup
не завёлся, я ругнулся, перезапустил его, теперь он ругнулся, что папка назначения не пустая, я снова ругнулся, сделал rm -rf /var/lib/postgresql/9.5/main
и снова его запустил. Всё отличие только в том, что мне повезло больше того парня и я не перепутал будущую реплику с мастером при этом.
Но не буду — ибо и так всё печально.
Здесь мог быть ответ на Ваш комментарий. Но его, конечно же, тоже не будет по понятным причинам.
Бают норвеги собираются считать бюллетени на ближайших своих выборов вручную. — Ибо они их бояться.
уже есть, не заметил (
Не оставляло чувство до конца прочтения всех комментов, что сегодня 1 апреля
Я на проде использую mv вместо rm по возможности.
подозреваю, что у них не было лишних 300Гб свободного места
300 Гб — это что, в 2017 году для кого-то всё ещё много?
Консольная команда rm удаляет файлы напрямую без корзин. В MC удаление так же идет напрямую.
А оконным интерфейсом на серверах не пользуются.
сделал 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
Вот судя из доков, они не собираются ничего переименовывать, только выводить полное имя хоста в заголовок окна с терминалом и подкрашивать заголовок окна терминалов с продакшеном в красный цвет.
подкрашивать заголовок окна терминалов с продакшеном в красный цвет.
Может, не только заголовок окна, но и саму «prompt-строчку»?
они не собираются ничего переименовывать
было: db2.cluster.gitlab.com
станет: db1.staging.gitlab.com
Так что перепутать окошко и написать не туда запросто. Лучше бы подключили дротики с транквилизатором, срабатывающим на «rm -rf»
Можно поздравить gitlab с присоединением к клубу тех, кто не только делает бекап, но и проверяет, что с него можно восстановиться.
Там на второй площадке (куда идет аппаратное зеркалирование), делается мгновенная копия данных, т. н. снапшот (предварительно переводя базу в режим горячего резервного копирования).
Этот снапшот монтируется на резервной площадке, в базе меняется IP на резервный, поднимается база, проверяется как нужно, хоть с привлечением операционисток. После проверки, база опускается, отмонтируется и удаляется автоматом. Таким образом мы можем быть уверены, что в случае чего, база нормально поднимется на резервной площадке.
Виртуалки поднимаются прямо из бекапа (можно настроить чтобы они не жрали столько памяти) в изолированной среде (а можно и не совсем изолированной), проверяется прописанные админом вещи (по умолчанию — что оно вообще отвечает по сети и vmware tools запускаются + что файл бекапа реально читается. в условиях когда и этого нет — это преимущество а можно сделать сложные скрипты проверки + сразу поднимать группы виртуалок).
На хабре были статьи даже как эта штука настраивается в базовом варианте.
При этом не нужно ничего кроме VMware/Hyper-V кластера (хотя завести на посмотреть можно и на одном хосте) ну и Veeam'а с платной лицензией.
Снапшоты разумеется Veeam умеет делать, несколькими разными способами (сильно зависит от того — что мы понимаем под снапшотом и что умеет делать хранилище)
Ну вот откуда такая любовь к монголо-татарским методам мотивации? Подобные инциденты случаются сплошь и рядом, и чаще всего по недосмотру или ошибке рядового сотрудника даже в организациях со строгими процессами. На каждый инцидент CTO не напасешься. Понятное дело за систематические проблемы и неспособность исправить ситуацию, но это не тот случай мне кажется. Отлично отреагировали, проблема решается, выводы вроде бы сделали (надеюсь в том числе и что не дело до полуночи ковырять на живую продакшн человеку после полного рабочего дня)
Ну и хорошая картинка из блога ГитЛаб
но это «стартап» все же, со всеми сопутствующими недостатками: команда небольшая, главное динамика, побыстрее выкатывать новые фичи. Одновременно идет maturity процессов и набор опыта поддержки в команде и руководстве, но это вообще не приоритет сам по себе.
А уж учитывая как отреагировали, построив на этом дополнительную рекламу и product awareness, так и совсем все неплохо по бизнес модели.
Если б такая история произошла на, скажем, нефтеперерабатывающем предпиятии, то другое дело, я б первый за покарать причастных был бы (да и то CTO все ж сильный заход), но здесь…
кстати вот вчера кто-то Instagram немножко уронил базы и у людей массово пропали профили, фоточки и лайки к фоточкам — представляете какое горе в мировом масштабе случилось.
Только сейчас начало все обратно восстанавливаться. Ну увольнять Instagram СТО и VP Engineering за это? не думаю.
Я думаю нефтеперерабатывающим стартапом компетентные органы заинтересуются прям на этапе гаражной хим.лаборатории, по сигналу соседей.
И вообще всё наоборот:
Только что мы отдали миллион за его учебу, за его ошибку, которую он, будучи адекватным и рациональным человеком, больше никогда не допустит! Эта трата была инвестицией в его учебу, и глупо будет увольнять этого человека, отдавать его другой компании, после такого дорогостоящего обучения.
и терминал перепутал и 5 бэкапов не восстали.
Они использовали pg_dump наравне с некоторыми другими техниками создания резервных копий. Однако, в какой-то момент они перешли на Postgres 9.6, а на той виртуалке, с которой должен был запускаться pg_dump остался 9.2. В итоге из-за несовместимости версий дампы создавались длиной в несколько байт, но этого никто не замечал.
Сейчас уже есть вместо этой связки pg_basebackup, который делает именно это (и ещё пару полезных фич), и он же используется при первичной настройке репликации.
Правда, гад, ругается, когда его просят в непустой каталог скопировать, после чего и происходит rm -rf
:-)
Gitlab «лежит», база уничтожена (восстанавливается)