tf
можно ещё реализовать её синхронную работу на двух машинах сразу с восстановлением при выпадении одной из них, но это уже костыли
Size: a a a
2021 June 25
NM
А не, даже если свои, то другие долго понимать будут.
NM
Не очень, тут понимаю, что костыли.
NM
Я думаю только как мигрировать на новую версию без боли.
NM
Есть идея подрубать репликанта новой версии и после синхронизации отрубать старый.
tf
костыли то что одна виртуальная машина работает сразу на двух физических хостах на архитектуре от калькулятора, которая для подобных развлечений не очень-то предназначена
tf
получается что надо решить часть проблем - синхронный доступ к стореджу, синхронная генерация рандома и так далее
NM
Хых
tf
прочитать гайд по миграции.
tf
может быть так наоборот не стоит делать
tf
процедура миграции это не "а давайте попробуем вот так", а всегда заранее спланированное действие.
NM
Хвхв
tf
планирование начинается ещё у разработчиков базы когда они выбирают структуры данных и прочее такое
tf
у хвалёного постгреса с обновлениями и репликацией труднее чем у проклятого мускуля с innodb 😛
tf
и перечитать эту же статью через пару лет опыта.
tf
резервное копирование чего вы там настраиваете? в зависимости от этого рекомендации могут отличаться
VP
5 лет, в современном айти, это почти что вечность...
VP
Безусловно, не нужно писать код, который держит открытыми транзакции во время выполнения несвязанного блокирующего ввода-вывода, но реальность такова, что многие программисты не являются экспертами по базам данных и не всегда понимают суть проблемы, особенно при использовании ORM, которая скрывает низкоуровневые детали, в том числе и связанные с транзакциями.
Но виноват, конечно, постгрес, а не code monkeys, ага...
Но виноват, конечно, постгрес, а не code monkeys, ага...
