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