У меня есть веб-приложение, которое зависит от базы данных MongoDB, доступной только для чтения. Путем проб и ошибок я обнаружил, что самый быстрый способ запустить конвейер ETL, заполняющий базу данных, - это запустить локальную копию MongoDB, заполнить базу данных, остановить базу данных и архивировать каталог состояний.
Чтобы развернуть «кластер» высокой доступности, я создаю несколько экземпляров (или контейнеров), запускающих приложение, каждый из которых имеет доступ к копии состояния в локально подключенном хранилище. Поместив их за балансировщиком нагрузки с регулярными проверками работоспособности и автомасштабированием (или в кластере Kubernetes как ReplicaSet), я получаю изоляцию, избыточность, легкий откат (с использованием версионного хранилища) и простую настройку практически в любой среде.
Ключевая идея здесь состоит в том, что, поскольку база данных доступна только для чтения, это в некотором смысле приложение без состояния. Таким образом, я могу относиться к нему как к любому другому c поставщику информации
У этой настройки есть много очевидных преимуществ. Тем не менее, меня всегда мучило чувство, будто я чего-то упускаю. Учитывая контекст только для чтения, есть ли еще какая-то причина, по которой может быть лучше запустить «правильный» кластер MongoDB?