LINUX.ORG.RU

Hot/Online Backup

 , ,


0

1
Дано:
    Одна или более баз (не кластеров) СУБД PostgreSQL;
Требуется:
    Быстрое, не блокирующее и не ломающее (как на уровне БД так и на уровне бизнес-логики (да, вы скажете LOL!!!11, WTF???77)) целостность данных резервное копирование;
Проблема:
    Должно работать на продакшн сервере с кучей параллельно выполняющихся запросов;
Примечание:
    В следствии одного из требований становится ясно что в само приложение придется подмешивать немного магии;

Собственно дискач.

Ответ на: комментарий от dn2010

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

exception13 ★★★★★
() автор топика
Ответ на: комментарий от exception13

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

dn2010 ★★★★★
()
Ответ на: комментарий от dn2010

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

exception13 ★★★★★
() автор топика
Ответ на: комментарий от exception13

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

Это как? autocommit?

bj
()
Ответ на: комментарий от exception13

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

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

bj
()
Последнее исправление: bj (всего исправлений: 1)
Ответ на: комментарий от bj

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

exception13 ★★★★★
() автор топика
Ответ на: комментарий от exception13

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

bj
()
Ответ на: комментарий от exception13

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

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

bj
()
Ответ на: комментарий от exception13

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

bj
()
Ответ на: комментарий от bj

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

exception13 ★★★★★
() автор топика
Ответ на: комментарий от bj

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

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

bj
()
Ответ на: комментарий от anonymous

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

bj
()
Ответ на: комментарий от bj

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

bj
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.