VL
оно разве не через write concern делается?
Size: a a a
2021 April 07
AS
вы про то как записать правильно, я про то как понять, записано ли правильно
AS
ну и не покрывает восстановление из бекапа
SH
вообще у меня основное - replication lag на нашем большом кластере. когда он выходит за размер оплога - почки отлетели, бэкап будет очень хреновый.
тебе надо что-то более детальное возможно.
тебе надо что-то более детальное возможно.
SH
восстановление из бэкапа - что ты тут опять же имеешь в виду?
AS
при востановлении из бекапа будет ситуация когда клиент уже закомитил данные и считает что они дюрабл, но часть данных потерялась от восстановления. ибо RPO. или во время восстановления если данные при восстановлении частично доступны
VL
Я могу еще вкинуть. Я что-то не нахожу как монга проверяет уже записанную дату в репликасетах. Ну т.е. оно с мастера реплицировалось на два слейва, а потом на одном слейве дата покорраптилась. Как монга это спалит?
VL
Насколько я понимаю по поводу бекапа:
- используем write concern и репликасет. Дату можно считать дюрабл пока живет репликасет.
- при полноценном восстановлении из бекапа часть даты просирается, ну потому что RPO.
Но я не специалист.
- используем write concern и репликасет. Дату можно считать дюрабл пока живет репликасет.
- при полноценном восстановлении из бекапа часть даты просирается, ну потому что RPO.
Но я не специалист.
2021 April 08
T
Так, ещё один бот....
EG
VL
Оо, посиба
AK
Как я понимаю явно такой возможности нет. Если я правильно понял вопрос и надо знать на сколько сильно разъехались реплики в сете, то можно наверное смотреть на:
Но это именно движок и уже ниже, на мерже и коммите в диск, как я понимаю.
db.serverStatus().wiredTiger.transaction Но это именно движок и уже ниже, на мерже и коммите в диск, как я понимаю.
AK
Хотя не выйдет, оно же будет коммитеть в бекграунде на праймори и под большим кол-вом операций просто разъедится все.
2021 April 09
PR
@liubov_nazarova вакансии согласовываются с администрацией (@upovod ) и пожалуйста в следующий раз - больше технических деталей и меньше "текста-заполнителя". Спасибо
E
Отличный вопрос, кстати. Я вообще не знаю стораджей, которые бы в бекграунде проверяли консистентность.
EG
На постоянной основе нету наверн, но с ручкой что-то было
AS
AS
Repairing read концепция?
E
Одно дело read repair при чтении, другое дело самостоятельно находить проблемы. И я не знаю что именно это значит в терминологии riak, но в классической это "если в процессе запроса на ноде N нет записи, потому что репликация ещё не успела, то произвести репликацию одной записи в процессе чтения".
E
Read repair действительно вышеописанное, но у них такой функционал есть, просто называется по-другому
Active Anti-Entropy
Riak’s active anti-entropy (AAE) subsystem is a continuous background process that compares and repairs any divergent or missing object replicas
https://docs.riak.com/riak/kv/2.2.3/learn/concepts/active-anti-entropy/#read-repair-vs-active-anti-entropy
Оче клёво!
Active Anti-Entropy
Riak’s active anti-entropy (AAE) subsystem is a continuous background process that compares and repairs any divergent or missing object replicas
https://docs.riak.com/riak/kv/2.2.3/learn/concepts/active-anti-entropy/#read-repair-vs-active-anti-entropy
Оче клёво!