#java #spring-boot #spring-data #mongock
Вопрос:
У меня есть 2 экземпляра Java-сервера, запущенных в докере вместе с базой данных MongoDB. Мы используем mongock для переноса данных MongoDB, которые отлично работают. Я разработал функцию, с помощью которой пользователь может экспортировать определенные данные из MongoDB из одного экземпляра и импортировать их в другой экземпляр. Проблема возникает, когда вышеупомянутые экземпляры не находятся в одной и той же версии,
- Версия исходного экземпляра больше, чем экземпляр назначения: Импорт-экспорт невозможен, так как исходный экземпляр может иметь расширенные функции, с которыми экземпляр назначения еще не знаком
- Исходный экземпляр ниже, чем экземпляр назначения: эти импортированные данные должны быть автоматически перенесены в последнюю версию, чтобы экземпляр назначения мог извлечь из них смысл
Я хочу конкретно рассмотреть 2-й случай. Я попытался найти такой конкретный вариант использования, но не смог найти ни одного подходящего примера.
Комментарии:
1. Версия, которую вы имеете в виду, версия MongoDB или данные версии в MongoDB, которые вы импортируете ?
2. Версионные данные в MongoDB, которые я импортирую в конечный экземпляр
3. То, что вы делаете, — это что-то действительно плохое, в идеале вы должны использовать репликацию в MongoDB
4. Я думаю, что это имеет смысл: у вас есть версия X вашего приложения, запущенная на одном экземпляре, и версия Y вашего приложения на другом, и вы используете MongoCK для запуска сценариев миграции данных. Это работает при обновлении с версии X до версии Y на месте, но вы хотите запускать версии X и Y параллельно и постепенно переносить данные? Это более сложная проблема, я не думаю, что MongoCK поддерживает это.
5. @GreyFairer есть идеи, как этого добиться?
Ответ №1:
Я не совсем понимаю, что и почему вы это делаете. Можете ли вы предоставить больше контекста? Зачем вам нужно мигрировать из-в разные экземпляры? Почему они не синхронизированы(код и данные), на самом деле, это основная мотивация Монгока ?
Однако, если вы действительно вынуждены к этому, что я хотел бы понять, почему бы не запретить обратный импорт. Таким образом, пользователь может импортировать данные только из более обновленного источника данных, но не наоборот.
Если вы можете это сделать, вы можете исправить это, всегда обновляя свои данные таким образом, чтобы они были совместимы с обратной связью.
Сказав это, я действительно считаю, что полный подход неправильен, но у меня нет контекста ни для оценки сценария, ни для причин, которые побудили вас сделать это.
Комментарии:
1. Потребность/мотивация: У нас есть облако, а также автономные экземпляры, на которых работают наши серверы Java. Мы являемся платформой с низким уровнем кода, где пользователи могут создавать свои продукты с помощью наших служебных виджетов. Поэтому чаще всего мы получаем запрос, например, пользователь создал приложение в нашем облачном экземпляре, и теперь он хочет самостоятельно разместить его, но не хочет снова создавать полное приложение, в этом сценарии импорт-экспорт идеально подходит. Но в нашем цикле выпуска у нас есть поэтапные выпуски, которые мы сначала выпускаем в нашем облаке, чтобы проверить, есть ли в них какие-либо критические изменения, и если все в порядке, мы выпускаем другие экземпляры в течение следующих 48 часов.
2. Учитывая приведенный выше сценарий, мы хотим предоставить пользователям возможность импортировать приложение, версия которого ниже, чем у текущего экземпляра. Я думал о чем-то вроде выборочной миграции полезных данных JSON, которые мы используем для миграции, и сохраняем их в фактической коллекции после успешного переноса или путем предоставления документов для запуска миграции