Как обращаться с миграцией DB с помощью средств развертывания AWS

Amazon Web Services предлагает ряд инструментов непрерывного развертывания и управления, таких как Elastic Beanstalk, OpsWorks, Cloud Formation и Code Deploy в зависимости от ваших потребностей. Основная идея заключается в том, чтобы облегчить развертывание и обновление кода с нулевым временем простоя. Они также помогают управлять лучшей архитектурной практикой с использованием ресурсов AWS.

Для простоты позволяет предположить базовую архитектуру, где у вас есть 2 структуры слез; набор серверов приложений за балансировщиком нагрузки, а затем уровень персистентности с использованием многозонной базы данных RDS.

Фактическое обновление кода во множестве экземпляров (серверов приложений) легко понять. Для очень упрощенного обзора служба AWS обновляет каждый node, в свою очередь, отбрасывая соединения, поэтому данный экземпляр не используется.

Однако я не понимаю, как управляются обновления БД. Предположим, что мы переходим от версии 1.0.0 к 2.0.0 приложения и что существует потребность в изменении структуры БД. Обычно вы должны использовать script или библиотеку, такую ​​как Flyway, для выполнения обновления. Тем не менее, если есть обновленный парк серверов, существует точка, в которой приложения 1.0.0 и 2.0.0 существуют во всем флоте, каждый из которых требует другую структуру БД.

Мне нужно понять, как это реально достигается (высокий уровень), чтобы узнать, какой лучший способ/время выполнения миграции БД. Я предполагаю, что есть несколько способов, которыми они могли бы достичь этого, но я изо всех сил пытаюсь понять, как они могут это сделать, и позволить как 1.0.0, так и 2.0.0 сохранять данные без потерь.

Если они перенести структуру БД с первым обновлением приложения node и в то же время создать кешированную версию 1.0.0. Пользователи, подключенные к версии 1.0.0, сохраняются с использованием кешированной версии БД, а пользователи, подключенные к приложению 2.0.0, сохраняются в новой перенесенной БД. После переноса всех узлов приложения кэшированные данные объединяются в БД.

Кажется маловероятным, что они могут это сделать, поскольку слияние будет довольно сложным, но я не вижу другого способа. Любые указатели/помощь будут оценены.

+8
источник поделиться
1 ответ

Это обычная проблема, с которой можно столкнуться, когда ваша инфраструктура приложений попадает в несколько узлов приложения. В прежние дни вы могли отключить свое приложение в автономном режиме для "окон технического обслуживания", в течение которых вы могли:

  • Замените приложение на странице "Обслуживание системы, обратно".
  • Выполнить миграцию базы данных (схему и/или данные)
  • Развернуть новый код приложения
  • Поставьте приложение обратно онлайн.

В 2015 году, и действительно в течение нескольких лет этот подход неприемлем. Ваши пользователи ожидают 24/7 операции, поэтому должен быть лучший способ. Конечно, есть ответ, это серия шаблонов для Рефакторинг баз данных.

Основная концепция, которая всегда должна иметь в виду, - предположить, что вы должны поддерживать две одновременные версии вашего приложения, и между этими двумя версиями может быть без прерывания изменений, Это означает, что в настоящее время у вас есть текущее приложение (v1.0.0) и (v2.0.0), которое планируется развернуть. Обе эти версии должны работать на одной и той же схеме. Как только v2.0.0 будет полностью развернут на всех серверах приложений, вы можете затем разработать v3.0.0, который позволит вам завершить любые окончательные изменения базы данных.

+3
источник

Посмотрите другие вопросы по меткам или Задайте вопрос