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

Question

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

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

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

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

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

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

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

Answer 1

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

• Заменить приложение на страницу «Обслуживание системы, назад в ближайшее время».
• Выполнение миграции базы данных (схемы и/или данных)
• Deploy код нового приложения
• Put приложение назад онлайн

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

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