Мне легко, так как у клиентов видел, что в логах ошибки даже год(!) с хвостиком прут, а никто не чешется, так как пока кеширующая БД не грохнулась, все работает. Обычно кеш сбрасывают намного чаще, чем раз в сутки. А даже если тот же Redis рестартовать, то если он успешно рестартанет, загрузив данные с снапшота, никаких проблем не увидишь. Не факт. Не важно, на Redis она, или на чем-то другом, но непрерывная агрегация точно необходима. Слишком уж дорого обойдется мультимастер на реляционной СУБД, в которую отдельными транзакциями прилетают каждое использование расходников и каждый заработок опыта каждым игроком в битвах. Вы ничего не путаете? Redis вообще NoSQL БД. На диск он пишет снапшоты и WAL (в терминах Redis - AOF). А для реляционной СУБД он выступает просто клиентом, который периодически посылает ей DML предложения. Как раз судя по заявленному времени, необходимому на восстановление, очень похоже на то, что кто-то будет героически миллионы транзакций из WAL вливать в реляционную СУБД. И это действительно может потребовать несколько суток. Этак сутки-двое-трое за каждый ранее прощелканный месяц.

Не совсем так. Постоянно данные хранятся, обычно, в реляционной СУБД. А вот чтобы не грузить ее частыми мелкими транзакцими, такими как использование расходников, получение очков опыта в битвах, ловля контейнера в битве и т.п. - используется кеширующая и агрегирующая БД, работающая в оперативной памяти. Агрегированные данные (использовал N расходников, получил X очков опыта и т.п.) периодически записываются уже в реляционную СУБД на постоянное хранение. Поэтому, если такая кеширующая БД приказала долго жить, то часть подобных данных может быть утеряна, так как не была еще записана в реляционную СУБД. Если такая кеширующая БД (скорее всего - Redis) , из-за каких-то вовремя не обнаруженных проблеме, уже несколько месяцев как перестала сбрасывать данные в основную реляционную СУБД, то востановить эти несколько месяцев можно по WAL (журнал предварительной записи), но это значит повторить весь объем таких мелких транзакций за эти несколько месяцев, да еще руками выискивая точку, начиная с которой данные перестали сбрасываться на постоянное хранение. Хуже, если WAL был отключен или не архивировался, или старые, но необходимые для восстановления, архивы уже удалены. Вот тогда может возникнуть желание покусать локти.

Видел Тогда репа Ореха перестанет помещаться в кадр

Ну в Redis давно есть WAL (в терминах Redis - AOF). Так что, в принципе, все транзакции, кроме за последние секунды, сохранены (предполагаю, что WAL бекапились). Другое дело, что это миллионы, если не миллиарды, мелких транзакций вроде использования расходников и получения очков опыта в битвах. В любом случае, это лишь предположение. Все может быть как намного лучше, так и намного хуже...

Боюсь тут дело не в этом. Судя по неделе на восстановление и скриншотам в сети с состоянием аккаунтов два месяца назад, сломалось что-то давно. Например, данные из Redis, используемого в качестве кеша, перестали попадать на постоянное хранение в реляционную СУБД. А заметили это только когда в один прекрасный момент Redis навернулся.

Планета круглая. Например, в Кейптауне лето начинается

Какие папки? Логи уходят по сети в ClickHouse, ElasticSearch или даже реляционную БД. Может просто через syslog, может через Kafka, может еще как.

Я представляю это как отказустойчивый кластер СУБД, к которому обращаются игровые сервера. Так как нагрузка на СУБД тут невелика, то достаточно одного мастер-слейв. Но не исключена и мультимастер конфигурация, когда данные одного игрока модифицируются только на одном сервере кластера, а остальные сервера получают реплику с него, а данные другого игрока - модифицируются на другом сервере кластера.

Все в мире относительно. Может быть "большими трудностями" они считают тонну тротилового эквивалента взорванную в ЦОД? Больше умиляет обещание "держать вас в курсе событий" и при этом уже больше суток гробового молчания.

Это еще нарушение реляционности и потенциальная утеря целостности. Битовые маски хороши в процедурах, но никак не в хранении в полях БД. Намного проще иметь табличку вида UserID int NOT NULL, ItemID int NOT NULL, ItemLevel int NULL Где UserID и ItemID есть foreign key на соответствующие справочники ItemLevel NULL для устройств, красок и четвертого слота защиты; уровень прокачки для пушек, корпусов, модулей и дронов; количество для припасов. Итого 12 байт на каждый элемент в гараже. Пусть даже у игрока в среднем 200 таких записей. В основном, с красками. Получим 3К на пользователя, включая запись в справочнике пользователей. Итого даже 100 миллионов игроков - это 300 ГБ. Ну добавим на индексы еще 30%. 400 ГБ получится. Копейки. P.S. Естественно, упростил. Понятно, что при наличии NULL полей в записи, добавится байт на битовую маску NULL. Тогда для устройств, красок и четвертого слота защиты будет тратиться 9 байт, а на остальное - 13 байт. В среднем все равно меньше 12 байт получтся.

А ты пофантазируй. Расскажешь, когда допустимо запрещать на индексах блокировки на уровне страниц, а когда нет. И какие плюсы и минусы такого решения P.S. Одной своей фразой ты показал, что даже не удосужился прочитать, то что я писал. Так как про трафик страницы фраза была для общего понимания, а главное было в том, что в TLS Hello клиента на порядок короче, чем Hello сервера.

Я думаю, что там все намного проще. Например. Сначала какая-то умная душа решила обновлять в БД запись игрока временем входа при каждой авторизации. Другая умная душа решила это время проиндексировать, чтобы быстрее какой-то запрос шел. А модификация индексированного поля из параллельных потоков - уже потенциальный источник дидлоков. Чем больше таких модификаций в единицу времени - тем выше вероятность дидлока. А дидлок снимается только по таймауту убиванием одного из потоков. В итоге имеем просто висящую в прекрестных блокировках БД в моменты пиковой загрузки. Я ни в коем случае не утверждаю что все именно так. Я даже не утверждаю, что проблема именно в дидлоках. Но, по косвенным признакам, вероятность этого довольно высока.

И что мешает по WAL откатиться на точку до взлома?

В ММ нубье - атрибут обязательный ( Не неудачно, а нуб даже не понимет, что при атаке без смещения с линии огня, он не только сдохнет сам быстрее, но еще и не дает другим стрелять по атакуемому. Да и вообще, с изидой, фризом или жигой в лоб есть смысл переть только если нужно тормознуть противника (несет флаг, преследует флаг, везет мяч). Во всех остальных случаях проход со смещением и атака сбоку и сзади - намного эффективней. А уже с теслой и более дальнобойными пушками, атака в лоб тем более смысла не имеет.

На многих картах можно держать точку, находясь за укрытием и оттуда уже доставая сплешем. Но тут с громом действительно плохо, так как обязательно найдется нубло, влезшее тебе перед носом. Тут скорп выиграет именно за счет того, что сам он под свой сплеш уж точно не попадет и его ракетам не мешают нубы, лезущие на линию огня перед носом.

Я же писал выше, что, обычно, на кассете данные актуальные только на прошлые сутки. А для крупной компании потеря суток, да еще неизвестно сколько времени на восстановление (восстановление с ленты намного медленней, чем запись на нее), может вылится действительно в многомиллионные убытки. А если еще шифровальщик не был выявлен сразу и зашифрован один-два предыдущих бекапа, то может быть еще больней. К тому же, если уж речь про ТО, то взломать Linux для размещения там шифровальщика очень не просто. Сами то сервисы игровых серверов не под рутовыми правами и много они они не зашифруют.

Которая тоже в Нидерландах и записывается в том же ЦОД. После чего курьером отвозится на хранение в указанное место (хранилище или банковскую ячейку). Ну 99% резервных копий и выполняются по сети. Стриммер, даже если он не сетевой, только не бекап-сервере стоит. Но в ЦОД то по любому стриммер сетевой и с автоматической сменой кассет. Там уж точно никто руками их втыкать не станет.

Вообще то судиться следует по месту регистрации ответчика.

Как зашифровать данные, которые уже на кассете? А на кассету резервные копии пишутся ежедневно. Сутки можно потерять. Но не более того.

Слабо верится. Даже в начале 90-х мелкие предприниматели не скупились на стриммер, понимая, что экономия сотни баксов обойдется потом намного в большие затраты.

Опять таки, за более чем 30 лет работы в IT, я других вариантов не встречал. Малый бизнес обходится банковской ячейкой, которая все равно нужна и стоит совсем недорого. Крупный - пользуется услугами специализированных хранилищ.

Кассеты то ежедневно увозятся из ЦОД в хранилище или банковскую ячейку. Поэтому и их потерять - уже из области фантастики

Я за более чем три десятка лет своей работы еще ни разу не встречал организацию, где бы не относились к резервному копированию с ответственностью. А тут уж точно необходима непрерывная архивация и PITR (востановление на точку времени)

То что можно потерять данные в БД, например, за последний час - представляю, хоть и с трудом. То что можно при этом еще потерять последную резервную копию или одну из резевных копий журнала транзакций - тоже представляю, если DBA абсолютно некомпетентен. Но чтобы еще и предыдущий бекап потерять - уже не представляю.

Ну была бы смекалка. Пока сервера лежат: https://youtu.be/MKSWxsFZJyI