да, там как раз все вокруг базы крутится

но галера в докере - психушка

А можно пожалуйста подробнее?

http://michaeljswart.com/2018/01/100-percent-online-deployments-blue-green-deployment/

почитал - в моем кейсе не сработает, сейчас миграции идут по 2-3 часа (записей много), и даже aqua state тут не поможет сделать zero downtime. Все равно придется делать green сервис так, чтобы он мог и со старой схемой

работать, и с новой

почитал - в моем кейсе не сработает, сейчас миграции идут по 2-3 часа (записей много), и даже aqua state тут не поможет сделать zero downtime. Все равно придется делать green сервис так, чтобы он мог и со старой схемой

А что за бд?

про blue-green знаю, тут вся проблема с центральной бд... а так за ссылку спасибо, почитаю :-)

Есть вариант поставить мастер-слейв и в sql прокси завернуть все запросы к бд. Потом обновить схему бд если требуется на слейве. Новую версию приложения развернуть параллельно и на sql прокси все запросы от нового приложения маршрутизировать в слейв. Все запросы на изменение данных в бд записывать в прокси. Дальше часть трафика пустить только на новое приложение, если всё ок, постепенно увеличивать трафик нового приложения. Все юзеры должны привязаться к версии приложения по сессии или какому нибудь уникальному значению.

потом миграцию данных из старой в новую в параллели с работой грин сервиса, причем т.к.данных много это растянется надолго

А что за бд?

банк

Ну и чтобы консистентность данных была, в слейв все запросы на изменение должны тоже идти. Про это надо не забыть.

Так можно и откатить без потери данных и обновить без простоя.

Готового инструмента для такого я не знаю, наверно и нет из-за того что у всех свой софт специфичен

ок

Для отката будет необходимо все залогированные запросы на изменение к слейву проверить, что они валидны для старой схемы. Если не валидны, они будут всё равно однотипны и можно будет через прокси сконвертить или скриптом. Потом накатить на мастер бд

Вот это интересная задача, не то что нджинкс на убунту поставить

почитал - в моем кейсе не сработает, сейчас миграции идут по 2-3 часа (записей много), и даже aqua state тут не поможет сделать zero downtime. Все равно придется делать green сервис так, чтобы он мог и со старой схемой

уменьшать время миграций. так не должно быть

Готового инструмента для такого я не знаю, наверно и нет из-за того что у всех свой софт специфичен

+

Alexander (1) увеличил репутацию Alex Gluck (3)

если использовать лог sql запросов, то получается eventually consistency. что не айс

я не понял про миграции

уменьшать время миграций. так не должно быть

Да что ты говоришь. Поди смени на 200 гиговой бд схему и тип поля с конвертацией, да ещё и быстро.

уменьшать время миграций. так не должно быть

записей _очень_ много - по быстрому ну никак

Да что ты говоришь. Поди смени на 200 гиговой бд схему и тип поля с конвертацией, да ещё и быстро.

копировать таблицу, менять на копии, догонять отстающие записи, потом переименовать

все так делают (с)

если использовать лог sql запросов, то получается eventually consistency. что не айс

У тебя в прокси sql есть возможность запросы преобразовывать для синхронной консистентности. Но это сложнее.

жопа. потенциально развал всего

копировать таблицу, менять на копии, догонять отстающие записи, потом переименовать

Копирование часть миграции, всё равно время займёт

нет

копируй пока продуктив работает

никто не мешает

нет

Тогда это полемика. Я считаю по другому

привет всем, может кто знает, есть чат по астериcку?

Тогда это полемика. Я считаю по другому

считай

жопа. потенциально развал всего

Ну надо думать, пытаться. Мой вариант теоретически работоспособен. Я даже когда то проверял теорию и подтвердил её на микровыборке. Но в больших масштабах могут быть описанные тобой проблемы.

я считаю что тут должен быть даунтайм и все

и бить по голове архитеторов, которые решили поля менять в больших таблицах

я считаю что тут должен быть даунтайм и все

Я думаю что можно сделать тестовый стенд и проверить разные варианты.

и бить по голове архитеторов, которые решили поля менять в больших таблицах

Ну тут уже сам понимаешь, не мы принимаем решения

просто чувака загнали в яму

а можно было изначально предусмотреть

а можно было изначально предусмотреть

Это классика. Часто так ошибаются

конечно, но не выкручивают руки с минимальным даунтаймом

а что там за БД?

Толерантность надо проявлять к пидорасам

оракл какой или сиквел?

к геям же

а что там за БД?

Банк он сказал. Наверно оракловые или дб2

это ж мегамонолит, че они парятся

ноччю свопнули базы и все

к геям же

Геи, это люди иной ориентации. А архитекторы меняющие поля на бд, пидорасы

сейчас оракл

вайти-директор про скрамы девопсы и эджайлы начитался?

а если не секрет оракл в RAC работает?

есть желание уйти от монолита и миграций по несколько часов

насколько я знаю, нет не rac

а как вы сейчас мигрируете? и главное - почему мигрируете?

насколько я знаю, нет не rac

а как часто падает БД?

если что - у всех падает и ресторится ии фиксится от краша приложений

а как вы сейчас мигрируете? и главное - почему мигрируете?

раз в квартал

а как часто падает БД?

не владею информацией

раз в квартал

Средненько, прям как в геймдеве

то есть набираете критическую массу изменений в схему и фигачите часами

если так то правильно делаете

точно начитались про микросервисы

но я не пойму если нет пересчета чего-то, почему многочасовые миграции

точно начитались про микросервисы

Всю жизнь работали как белые люди и на тебе. Аджайлы, девопсы, смузи

:-)

есть табл1 надо поменять поле1, в табл1 всего 100 млн записей. делаем табл2 с правильными полями. запускаем утилиту или просто запрос, который вольет содержимое табл1 в табл2. синхронизируем как только можно. тушим приложения. проверяем консистентность табл2 на 100% соответствие табл1. переименовываем табл1 в табл3 а табл2 в табл1. включаем приложения

где тут 3 часа не понимаю

сначала дольше, а потом минут до 5-15 дойдете

даутнайма

у нас порядок цифр несколько иной - десятки миллиардов записей, нагрузка порядка 10к транзакций в сек. скриптов миграций в одной версии - сотни.

поэтому и 3 часа

тут похоже проблема фундаментальнее. чтобы можно было использовать blue-green надо релизиться сильно чаще, чтобы сервис мог управляться с двумя схемами сразу.

иначе дельта м5жду схемами настолбко большая, что сервис просто разорвет от логики поддержки двух схем сразу

поэтому и 3 часа

а как сейчас процесс миграции идет? так как я выше описал или выключили приложение и давай молотить?

10к в сек и хрен с ним

все равно 3 часа - это много

иначе дельта м5жду схемами настолбко большая, что сервис просто разорвет от логики поддержки двух схем сразу

Я бы на вашем месте послушал Александра

Без простоя оракл вы не сможете без смены структуры софта на уход от централизованной бд

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

но это разработчикам было сложновато делать и закладывалось на этапе проектирования (ритейл емнип)

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

Это прям сложно и дорого звучит

вооот, я как раз с этого и начал диалог :-)

объяснить толком не смог

;)

Это прям сложно и дорого звучит

чуваки были головастыми и не ленивыми. босс платил бабло и архитектурно грузил на нормальном уровне. основные проблемы они решали такими финтами. кароче команда была огонь

чуваки были головастыми и не ленивыми. босс платил бабло и архитектурно грузил на нормальном уровне. основные проблемы они решали такими финтами. кароче команда была огонь

Ну согласен, обычные среднячки сейчас такое не вытянут

но хочетс снять эту нагрузку с обчных девов

вот и ищу пример промышленной реализации такого

обычному деву насрать (простите мой французский) на простои при миграциях

выше с копированием написал по сути бест практис

вооот. может быть тогда головастые будут овнерами дао слоя например?

видел производную с переименованим не таблиц а просто колумна

где вся эта магия с zd миграциями будет скрыта

какая магия если вы структуры меняете на миллиардниках?

ну предположим, что начнется движение в микросервисы. бд распилят на несколько... все равно хотелось бы от обычных прикладников скрыть кухню zd миграций

ну предположим, что начнется движение в микросервисы. бд распилят на несколько... все равно хотелось бы от обычных прикладников скрыть кухню zd миграций

херней занимаетесь

простите, но как есть

в гонитве за модой угробите что есть