yopp
Если операции связанные или не индемпотентные
Dmitriy
В транзакции?
yopp
Если они не связанные и их легко можно повторно применить, то можно и без транзакции
yopp
В транзакции?
Да, https://docs.mongodb.com/manual/core/transactions/ 4.0+
Dmitriy
Спс. Буду пробовать.
Алексей
Коллеги скажите, интересует вомзожность монги работать в реплеке, т.е задача такая: надо на одном облачном сервере развернуть монгу и класть в нее данные после обработки, и потом что бы эти данные уходили в монгу которая у меня в локальной сети, ну или скажем локальная монга сам в како-то период синхронизировала данные
Алексей
ну в ней хранится основной поток данных. просто есть старые данные которые надо по новой обработать
Алексей
их много
Алексей
вот и думаю есть смысл обрабатывать в облаке на более мощных ресурсах
Алексей
суть в том что бы наные синхронизировались скажем будут обрабатываться данные за 18 год, но в локальной они уже есть
inqfen
А у меня тут тоже вопрос по репликации - делаю пайплайн для автоматического поднятия монги с репликами
inqfen
Вопрос такой - что будет, если реплики в конфиге по доменному имени и за каким-то именем поднялась новая монга? (инстанс помер, для него создана та же запись, там поднялась монга)
inqfen
Включится ли он в репликацию или она останется с недоступным старым болтаться?
Artem
@yatoba @dd_bb реклама?
Hallo
Да.
Nick
Включится ли он в репликацию или она останется с недоступным старым болтаться?
Вроде как реплики идентифицируются просто по хостпорт, поэтому новая реплика будет обнаружена и пройдет стадии синхронизации чтобы влиться в нормальную работу
inqfen
спс
inqfen
надо будет проверить
inqfen
все равно модуль для ансибла похоже велосипедить
inqfen
а нет, не придется
yopp
Вопрос такой - что будет, если реплики в конфиге по доменному имени и за каким-то именем поднялась новая монга? (инстанс помер, для него создана та же запись, там поднялась монга)
Это очень плохая идея, так как даёт возможность потерять данные при сценарии когда у вас все полы в кластере окажутся «новыми»
yopp
Хотите добавить новую ноду, добавляйте новую ноду. После того как убедитесь что кластер в здоровом состоянии, можно почистить конфиг
inqfen
Хотите добавить новую ноду, добавляйте новую ноду. После того как убедитесь что кластер в здоровом состоянии, можно почистить конфиг
у приложения отдельная конфигурация в отдельной репе и оно не узнает, что там есть новый инстанс
inqfen
поэтому есть mongo1.example.com, mongo2.example.com, mongo3.example.com
inqfen
dns запись заполняет терраформ
inqfen
И если он там изменил инстанс - значит он создал новый
yopp
поэтому есть mongo1.example.com, mongo2.example.com, mongo3.example.com
https://www.mongodb.com/blog/post/mongodb-3-6-here-to-SRV-you-with-easier-replica-set-connections
yopp
И если он там изменил инстанс - значит он создал новый
Вы делаете небезопасную архитектуру, которая позволяет из-за ошибок в инфраструктурной автоматизации потерять кластер
yopp
Зачем это делать, если можно этого не делать
inqfen
инфраструктура должна подминаться без ручным проверок и прочего, как раз таки полностью автоматически
inqfen
ну и там бэкапы раз в 15 минут
inqfen
И как бы в любом случае, если кто-то ошибается - может ошибиться по другому и данные так же потеряются
inqfen
Можно и коллекцию по ошибке удалить
yopp
инфраструктура должна подминаться без ручным проверок и прочего, как раз таки полностью автоматически
Я вам объяснил что есть другой подход с меньшими рисками. Автомаизировать cleanup конфигурации тоже можно, добавив safeguards перед деструктивными действиями. Проблему с discovery решили ещё в 3.6
yopp
И как бы в любом случае, если кто-то ошибается - может ошибиться по другому и данные так же потеряются
Ошибки в инфраструктурной автоматизации всегда несут больше рисков, так как позволяют ломать вещи on scale
yopp
Но это ваше право, хотите игнорировать чужой опыт — игнорируйте
inqfen
Я вам объяснил что есть другой подход с меньшими рисками. Автомаизировать cleanup конфигурации тоже можно, добавив safeguards перед деструктивными действиями. Проблему с discovery решили ещё в 3.6
Тогда проще сначала запускать создание в check_mode и выходить если что-то пошло не так и не указано запускающим, что все ноды действительно должны быть новые
inqfen
А это должно быть 1 раз - при создании кластера
yopp
Вы меня не убеждайте, у меня есть опыт как такими скриптами наносили бизнесу огромный ущерб. Вы не видитие кучу нюансов, которые есть в таких сценариях. Потому что уже даже вопрос что такое «новая» нода это _очень_ сложно.
yopp
Bootstrap вообще должен быть отдельным сценарием
inqfen
Ну у вас вариант конечно надежнее, посмотрю, что проще решаемо
yopp
Автоматическое добавление нод в кластер это так себе идея
inqfen
Bootstrap вообще должен быть отдельным сценарием
идемподентность же, если уже запустстраплено и нет изменений - ничего не произойдеет, если пусто - все поднимется
yopp
бесполезно
inqfen
А вообще будут регулярные бэкапы (как уже писал, раз в 15 минут) и если кто-то сломал все, небольшой простой - нехорошо, но не критично
Max
должен же быть какой-то выход. "давайте монгу засунем в spot instance, а то дорого. Всё равно новые поднимутся, если упадёт, да и диски можно двигать. то есть данные не потеряются, а мы сэкономим кучу денег"
inqfen
надо, надо писать доку по поводу того, чем люди рискуют, засовывая кластер в такие автоматические конфигурации.
как раз таки требование бизнеса - все должно быть автоматически и если например лег регион aws - мы должны быстро поднять все в новом
inqfen
и не руками
Max
А вообще будут регулярные бэкапы (как уже писал, раз в 15 минут) и если кто-то сломал все, небольшой простой - нехорошо, но не критично
простите, что вклиниваюсь, но если идет речь про реплики (а потом и шардирование), то вам бекапы не помогут
inqfen
а прецедент уже был, когда из-за урагонов шатался регион в us
yopp
нормальная автоматизация это миллионов 50 долларов и лет 5 работы
yopp
вопрос сколько вы данных потеряете и насколько хорошие у вас бекапы
yopp
возьмите атлас
inqfen
будет
нет, данные из внешних источников заполняются приложением, а не генерируются в нем
yopp
у вас есть data inventory?
yopp
с оценкой восстановимости данных, стоимость восстановления, окон, глубины?
inqfen
неа
yopp
тогда будет
yopp
потому что выяснится что из внешних источников ретроспективно можно достать посление 10 дней, например
yopp
или что там rate limit такой, что вы никогда ничего не восстановите
yopp
или что это ToS запрещает
inqfen
потому что выяснится что из внешних источников ретроспективно можно достать посление 10 дней, например
ну и если у нас есть бэкап даже за вчера, то мы должны 9 дней прожить без базы
inqfen
yopp
:)
inqfen
вкратце - это общая БД всякх ггоночных событий
inqfen
во-первых они производятся не без перерыва
yopp
вы не сюда пишите, вы создайте файлик с инвентарём и туда пишите
inqfen
и rate limit станет такой, если каждый житель земли станет учавствовать и паре гонок в час)
yopp
но если у вас aws, то я в третий раз посоветую взять atlas и не морочить себе голову, с бэкапами и этим всем