Комментарии 23
Это все последствия выбора "безобразно но однообразно" vs "большой зоопарк".
Первое приводит к проблемам как у автора. Второе к другим, но не менее сложным проблемам. Когда из-за зоопарка только одних видов субд в компании будет десятка два и бэкапить это будут каждый кто во что горазд, и 100% какие-то системы будут вообще без бэкапов жить.
Нет, это последствия вот этого:
Все процессы были спроектированы на основании идеи того, что [...] разработчики не понимают, что требуется, поэтому нельзя позволять им задавать требования.
ну если позволять им задавать все требования и выбирать инструменты, скорость разрастания зоопарка станет сверхсветовой и через год никто в компании даже представлять не будет что и где используется
Если вообще каждому дать выбрать инструмент — то да, но есть же и более адекватные способы.
адекватно, это продумывать это на уровне архитектуры, архитекторам
История странная со всех сторон. Автор статьи мог выбрать конкретную СУБД и конкретную технологию ее бекапа, но не мог выбрать бекапную хранилку и даже не мог узнать ее модель? Предположим, такая дурацкая система полномочий. Но если бекапная хранилка обеспечивает низкую скорость чтения, то надо снижать требования к RTO и отказываться от инкрементальных бекапов. Бекапьте фул и логи, какие вопросы? Восстанавливаться будет долго, ну так хранилка и так медленная, значит руководство считает это нормальным.
Или меняйте архитектуру базы и делайте защиту через отстающий стендбай, раз есть возможность самому крутить что угодно.
Data Domain - чудесная железка, но она действительно не для того предназначена, чтобы с нее читать и считать разницу на стороне клиента. Она на своей стороне это прекрасно делает сама.
За пару десятков лет работы я понял одно - документация по бекапам и по процедуре восстановления (что, откуда, куда, как и главное в какой последовательности), это редчайший документ во многих компаниях. Делать такую документацию, это нудятина ещё та, да и память у многих админов просто супердолговременная -). До первого жёсткого факапа.
Ладно документация, а вот регулярные тестовые восстановления с проверками логической целостности не делает примерно никто. Дорого, долго.
Единственный рабочий способ заставить людей это делать - это внедрить систему, при которой тестовые или отчетные базы регулярно пересоздаются именно из бекапа. Тогда прикладные проверки появятся естественным образом.
"The issue was caused by a malfunctioning server that couldn't synchronize character data correctly and corrupted them instead,"
Игровой сервер не может прочитать данные из (общей) базы корректно, но может их удалить?
База(ы) здесь как-бы совсем не причем. Бакап позволил восстановить потертое.
Имхо, основная проблема в архитектуре апи бакенда, или ее отсутствия.
Да простейшее решение типа soft-delete не привело-бы к таким громким последствиям.
Тут не soft delete нужен, тут нужно хранение версий.
Судя по симптомам, там было нетипизированное хранилище документов, в котором хранились либо персонажи, либо профили целиком. Игровой сервер тут и был бекендом, и работал с этим хранилищем он как с файлами — читал целиком данные и сохранял обновлённые.
Версионность, это было-бы хорошо, но в статье рассматривается Postgres vs MySQL а не хранилище документов, а в реляционой модели делать версионность немного сложнее.
"Хотя-бы сделали решение типа soft-delete."
Да, кстати игровой сервер как бекенд, тоже совсем не правильно. По нормальному надо делать отдельно, фасад апи с игровой логикои, и бэк с версионостью апи, кешем, распределением нагрузки итп.
Нет смысла. Основная нагрузка всё равно тут на самом игровом сервере и на стороне СУБД, бэкенд тут лишь почтальоном поработать может, он никак не распределит нагрузку. Версионировать тут тоже нечего, единственный клиент — это игровой сервер, и ему нужна конкретная версия api. Кешировать в таких сценариях тоже особо нечего.
И, главное, проблема "устаревшая программа запорола документ при редактировании" остаётся как компоненты не выноси, только вариантов "запарывания" от увеличения числа звеньев прибавляется.
статье рассматривается Postgres vs MySQL а не хранилище документов, а в реляционой модели делать версионность немного сложнее.
Без проблем, просто нужна отдельная таблица для истории изменений.
Я всё ещё уверен, что игровой сервер использовал Postgres как хранилище документов.
Спасибо как минимум за ностальгию: учился по этому направлению в ВУЗе, с теплотой вспоминаю, как мы на лабораторных работах похожий зоопарк собирали, а потом приходилось самому приходить после пар и делать, чтобы работало ???
Как мой менеджер потратил миллион долларов на сервер бэкапов, который я ни разу не использовал