Aurora Serverless Blue / Green развертывание
В настоящее время я изучаю стратегии для реализации синего / зеленого развертывания с использованием RDS Aurora Serverless для Mysql.
2 метода, о которых я думаю являются:
А. Создайте дубликат базы данных и перенесите дубликат в новую схему. По сути, я бы поддерживал две версии БД до завершения развертывания, а затем удалял бы оригинал.
B. Всегда сохраняйте одну и ту же базу данных и более или менее поддерживайте две схемы одновременно. Это означает, что я бы делал такие вещи, как сохранение повторяющихся столбцов, если бы я хотел изменить имя столбца, чтобы мои старые запросы продолжали работать как для старой, так и для новой версии моего приложения.
У меня есть несколько вопросов по поводу осуществимости из них обоих:
- Для метода A , есть ли разумный способ дублировать базу данных с помощью Aurora Serverless? Насколько я понимаю, моментальные снимки нельзя использовать для создания дублирующей базы данных.
- Для метода A , какие существуют варианты для сохранения синхронизации обеих баз данных. (Я думал, что использование Kinesis может сработать)
- Для метода B , какие существуют варианты для синхронизации повторяющихся столбцов / таблиц. Было бы довольно просто обновить оба столбца для пользователей в новой версии API, но я не уверен, как поступить со старой версией API, не зная, что новый столбец существует.
Я также открыт к предложениям о различных стратегиях.
Создание копии базы данных для каждого развертывания ( Метод A ) - довольно сложный подход .
Это работает, только если ваша база данных: довольно мала (копирование занимает время, хранение двух больших БД [синий и зеленый] стоит в 2 раза дороже и т. Д.), довольно статична с мало пишет (синхронизация этих двух данных может быть проблемой для загруженных БД) и когда вы не ожидаете отката (перенос обновлений из занятой новой зеленой БД обратно в старая синяя БД может быть сложной).
Это можно сделать, но это сложно. Такие инструменты, как AWS Database Migration Service (DMS) , которые могут выполнять как первоначальное копирование, так и впоследствии синхронизировать DBS, могут помочь с некоторыми из них.
Использование одной и той же БД для синего и зеленого ] (ваш Метод B ) обычно предпочтительнее , и с ним гораздо проще работать. Также на самом деле большую часть времени поля базы данных добавляются между выпусками кода, реже они удаляются или переименовываются . Но даже это можно сделать.
Допустим, вы хотите переименовать поле username в user_name по любой причине, например чтобы привести его в соответствие с новыми соглашениями об именах. Вот что вы можете сделать:
Версия кода 1 ожидает
имя пользователя, а в схеме базы данных есть полеимя пользователя.Добавить столбец
имя_пользователяпо умолчаниюNULLРазвернуть код версии 2 - он пытается аутентифицироваться по
user_name, и если обнаруживает, чтоuser_nameимеет значениеNULLон возвращается кимени пользователяи обновляетимя_пользователя. Если создается новый пользователь, он сохраняется вимя_пользователяи на отдельном шаге вимя пользователя.Если доступ к старому столбцу
имени пользователяне удается, потому что это больше не существующий столбец, это нормально.После того, как версия 2 полностью развернута и протестирована, запустите сценарий, который обновляет все оставшиеся
имя_пользователястроки изимя пользователя.Развернуть версию 3 , которая работает только с
имя_пользователя.Один раз версия 3 Развернут удалить старый столбец
имя пользователя, потому что и текущий (v3), и предыдущий (v2) могут работать без него.
Это может показаться сложным, но не так уж плохо.
Этот подход имеет ряд преимуществ:
это всего лишь проблема разработки программного обеспечения , ваш конвейер CI / CD не должен поддерживать копирование и синхронизацию баз данных и их откат.
в большинстве случаев. часто между выпусками программного обеспечения база данных не меняется, и если это происходит, обычно только добавляет новые столбцы , что является тривиальным и обратно совместимым.
вы можете использовать тот же подход, если решите использовать ] скользящее развертывание или канареечное развертывание вместо синего / зеленого в будущем.
Надеюсь, что это поможет :)