Мултисървърни миграции

[Sava Chankov]

Привет,

приложението ни се разрасна и ще върви на два физически сървъра. Внедряваме го с docker контейнери. Как постъпвате с миграциите на базата данни в такива случаи?

със снежен поздрав,

Сава

[Stefan Kanev]

1. Разделяш уеб сървърите на две групи
   
2. Спираш половината web worker-и и ги вадиш от load balancer-а
3. Пускаш новата версия на кода на тях и ги warmup-ваш
   
4. Пускаш миграция
5. Веднага като приключи, вадиш старите сървъри от load balancer-а и вкарваш новите
6. Качваш новата върху останалата половина

Не е турбо консистентно (ще има завършващи request-и от старата версия които ще виждат новата версия на базата), но не можеш да избягаш от това без да вкараш downtime, бил той и малък (да спреш заявки към уеб-а, да изчакаш всички request-и да се обработят, да пуснеш миграцията и като тя мине да пуснеш новата версия).

Помага да внимаваш всички деплои да са съвместити със старата версия на базата ако искаш да елиминираш и този проблем. Например, ако триеш определена таблица, заедно с функционалността около нея, да го направиш на две стъпки. Първия деплой маха кода, но оставя таблицата. Втория пък е миграция, която затрива таблицата.

HTH

[Krasimir Angelov]

Straight outta config/deploy.rb :)

# first, check out the code on all the servers, and make the internal symlinks - but don't symlink the new code yet

# then, stop the workers on all background jobs servers

# symlink new code on all the background jobs servers and run migrations (one just one of them), then start workers

# roll through the app servers - disable, create symlink, enable, wait for heartbeat

# cleanup

Както каза и Стефан, трябва да се внимава стария код да е съвместим с новата версия на базата. Тук са разцъкали по-подробно различни варианти при миграции на базата - https://github.com/barsoom/devbook/tree/master/deploy_without_downtime#database.