Hot/Online Backup

Репликация?

Репликация на второй сервер, с него бекапить.

Не исключает что на реплике будут неконсистентные данные с точки зрения бизнес-логики. Тут скорее вопрос именно что, где и когда подмешивать в само приложение.

Бизнес логика делает атомарные транзакции, репликация также атомарная. Тогда всё будет консистентно.

Бизнес-логика делает что угодно атомарно или нет да еще и в хренцать потоков. В этом то и проблема.

Не исключает что на реплике будут неконсистентные данные с точки зрения бизнес-логики.

Это как? autocommit?

да, например.

Бизнес-логика делает что угодно атомарно или нет

То есть на мастере тоже могут быть неконсистентные данные, а бэкап это должнен исправить? Мило.

Более того общение с СУБД может происходить как через модели так и raw sql. Плюс асинхронные задачи с любым способом взаимодействие с СУБД.

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

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

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

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

Я дев и мы таки исправляем все это легаси. Но время есть время а волшебный бэкап ннада.

Дешево и сердито: оборочивать целиком реквест в транзакцию. Внутри ничего не коммитить. По исключению откатывать.

да, как вариант. остается сделать тоже самое с асинхронщиной и менеджмент.

Спрошу немного не по теме, но какое-то отношение к вопросу имеется.

Кака менеджить распределенные транзакции, если система распределенная и базы данных в компонентах гетерогенные? Т. е., к примеру, логика такая: есть приложение, которое внутри себя делает три запроса (например, кто-то хочет файл залить):

1) в абстрактный менеджер доступа - спросить «можно ли мне выполнить запрос этого клиента?»

-- тут присходит какая-то работа, что-то там в фс пишется, что-то читается из базы - похер, ничего не модифицируется в БД --

2) в nosql-базу по какому-то rpc шлется «увеличить счетчик занятого места для этого клиента» (эта информация используется на первом этапе, когда менеджер решает, можно ли)

3) в sql-базу ложится какая-то еще информация - какие-то уведомляшки, то-се.

(Все компоненты - отдельные приложения, общаются посредством установленных протоколов и интерфейсов, все очень разделенное)

Собственно, если что-то завалится, нужно все откатить. Как откатывать, если там в разных компонентах уже все покоммичено?

Есть, конечно, ХА и двухфазные коммиты, но реализовать самому все соответствующие протоколы - чувствую, грозит еще большим пиздецом, чем сейчас есть.

// чувствую, что в какой-то EIP уже все решено до меня

Сначала создаем себе проблемы, а потом героически решаем? Ню-ню. Чудес не бывает как и волшебных легких распределенных транзакций, причем абстрактных.

А в чем конкретно проблема? Сказать-то что-то есть по теме?

1. добиться того, что база консистентна

2. бекап через wal-e (https://github.com/wal-e/wal-e)

2. бекап через wal-e (https://github.com/wal-e/wal-e)

Ещё есть http://www.pgbarman.org/.

Нет никакой проблемы, разве что в качестве твоего волшебного eip выступает x/open xa. Если ты считаешь, что может быть что-то проще, то удачи.

О классная вещь!

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

Я же просто спросил, ты чего ерепенишься-то?

На самом деле, для жабы существует много JTA-aware компонент, и если изначально закладываться на XA, то внесение дополнительного звена в распределенную транзакцию можно сделать достаточно дешево.

В любом случае я предпочту выделить самый важную операцию в один сервис (уменьшение квоты + запись в ФС), в котором атомарность реализуется просто, без всяких XA. А всякие уведомляшки потом могут и обосраться, их повторить ничего не стоит.