— Ну, давай уже технические подробности!
— Журнал повторного выполнения Oracle реализован в виде кольцевого буфера. В «голову» процесс LGWR пишет новые изменения в БД, а «хвост» подчищается процессом CKPT по мере того, как изменения, записанные в «хвосте» будут записаны процессами DBWn в файлы данных. «Голова» — это текущий (current) файл журнала, хвост — активные (active) файлы. Подчистка хвоста заключается в том, что журналы помечаются как пригодные к повторному использованию (inactive). Проблема состояла в том, что «подчистка» прекратилась, т.е. все файлы оперативного журнала стали активными, и экземпляру БД стало некуда записывать новые изменения.
И это при том, что данный сбой был далеко не единственным у Сбера, однако по другим случаям – вообще тишина.
Я думаю у GitLab — это тоже не единственный сбой, но по остальных они документы не выкладывают.
Выложили данные для анализа, привлекли помощь сообщества и рассказали технические подробности. Да процесс восстановления не стримили и внутренние документы не выкладывали.
Помнить, что даже самое тяжелое поражение можно превратить в победу.
Я не понимаю, где тут победа? Они сейчас потеряли лояльность клиентов. Представьте например, на месте GitLab — Сбербанк и потерю данных за 3 часа? Я думаю мы бы речи о победе не вели.
от @Бобук
На волне всеобщего увлечения devops'изацией, в куче компаний решили что админы не нужны, и управлением серверами могут заниматься сами разработчики. Могут, но неплохо бы думать научиться, чтобы небыло как с GitLab: один разработчик случайно удаляет продакшн базу данных, перепутав сервера. И тут выясняется, что бэкапы есть, но восстановить из них ничего нельзя. В общем поучительная история.
Они думали что devops'изация избавит от раздолбайства.
YP (https://yorickpeterse.com) — software developer. Собственно это к вопросу о DevOPS, мне кажется что Системный Администратор с опытом такой ошибки не допустил бы.
Я думаю у GitLab — это тоже не единственный сбой, но по остальных они документы не выкладывают.
Они думали что devops'изация избавит от раздолбайства.
А можно уточнить как-именно решили проблему SYN flood в ядре Linux?