LINUX.ORG.RU
ФорумTalks

Postgresql - КРУТОЙ!


0

0

Сабж. Сутки себе напрягал моск над тем как мне сделать нормальный Multi Table Inheritance в Rails. Случайно нашел заветное слово "postgres table inheritance" и теперь счастлив и полон уверенности что проект получится не с кривым хранилищем. MySQL - в стойло!

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

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

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

Oceanborn
() автор топика

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

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

> постгрес пока не умеет репликацию на бинарном логе.

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

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

> постгрес пока не умеет репликацию на бинарном логе.

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

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

>> А что такое "репликация на бинарном логе"?

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

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

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

> А что мешает просто скопировать журнал транзакций, а затем подсунуть его другой базе

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

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

>> А что мешает просто скопировать журнал транзакций, а затем подсунуть его другой базе

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

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

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

> postgresql.conf есть спецальная опция, которой передаёшь команду которой WAL архивируется

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

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

> А что значит не продакшн вариант?

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

iBliss
()

Боян!

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

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

мда... ну и времена пошли.... пару лет назад помнится и простого SQL на всё про всё хватало... а теперь подиж ты.... какие выкрутасы....

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

>> postgresql.conf есть спецальная опция, которой передаёшь команду которой WAL архивируется

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

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

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

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

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

>> А что значит не продакшн вариант?

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

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

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

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

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

Думаю, что ты и был :). То типа шутко :)

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

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

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

> Смыс в том, что в реплике восстанавливается во время ребута. (recover) А это не совсем репликация.

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

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