Postgresql - КРУТОЙ!

А что такое "репликация на бинарном логе"? А то что такое репликация знаю, что такое журнал транзакций знаю, а что такое репликация на журнале транзакций не очень понимаю.

А у мну уже почти умеет :P

Репликация внутренней очереди инструкций вместо данных.

>Репликация внутренней очереди инструкций вместо данных.

А что мешает просто скопировать журнал транзакций, а затем подсунуть его другой базе? Стандартное действие при восстановлении из последнего бэкапа, а затем до последней транзакции с помощью Point-In-Time Recovery (PITR). Это "репликация на бинарном логе"?

Лень. Ну и не продакшн это вариант.

> Лень. Ну и не продакшн это вариант.

? Лень это сделать самому - в postgresql.conf есть спецальная опция, которой передаёшь команду которой WAL архивируется. Можно подстваить что угодно. А что значит не продакшн вариант?

Про это не знал. А не продакшн значит, что слишком высокая зависимость от человеческого фактора. Ну там забыл копию снять\не успел. Ди и даже в случае, если воспользоваться встроенным механизмом, вызывающем внешнюю программу, надо же как-то оттрекать корректность отработки. Вобщем надо какие-то костыли уже приделывать. Это конечно же решаемо и вряд ли составит большую проблему, но вот enterprise такого не терпит.

Это значит костыль на который страшно опереться. Репликация транзакций в БД (а тем более в случае N-репликантов) гораздо более сложный процесс нежели сунул/вынул...

Чувак в рассылке тебя опередил и даже полностью написал что и как делать :))))

>Про это не знал. А не продакшн значит, что слишком высокая зависимость от человеческого фактора. Ну там забыл копию снять\не успел. Ди и даже в случае, если воспользоваться встроенным механизмом, вызывающем внешнюю программу, надо же как-то оттрекать корректность отработки.

Там по-моему можно воспользоваться и встроенными возможностями, но рекомендуют для копирования таки внешние программы, так как ситуации могут быть очень сильно разные да и правильно перекладывать копирование на специализированные утилиты. Информацию что всё в порядке (просто указать -v, скажем для cp) можно в общий лог скидывать - как это делать тоже тюториал есть.

> Вобщем надо какие-то костыли уже приделывать. Это конечно же решаемо и вряд ли составит большую проблему, но вот enterprise такого не терпит.

Какие костыли? cp/scp - это костыль? Собственно говоря это и есть unix-way: каждый делает то, что лучше всего умеет. IMHO если энтерпрайз в себя в себя функционал scp пихает, то я бы с некоторой опаской к нему относился.

> Это значит костыль на который страшно опереться. Репликация транзакций в БД (а тем более в случае N-репликантов) гораздо более сложный процесс нежели сунул/вынул...

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

> Ну и если ты про создание представления и правила на вставку, обновления и т д, то скажи что ты об этом думаешь

Ничего не думаю :). Задач таких не было. Но в принципе стараюсь использовать минимальное количество разных вещей, чтобы легче было сопровождать. Поэтому в контексте рельс использовал бы STI и не трогал бы постгресовские навороты.

Не вижу особой разницы между этими действиями. Раз в скоько-то транзаций/через какое-то время WAL архивируется (переносится куда надо), а оттуда кто угодно может брать этот WAL и заглатывать.