Тут подумал, почему нельзя сделать репликацию на основе только модифицирующих запросов: log-statement = mod, а затем его распарсить, и заливать на слейв?

минусы:
* что в самих запросах явно не указана база. Поэтому репликация возможна только при внесении изменений в единственную базу.
* в лог попадают запросы в явном, а не фактическом виде (собственно потому базу и не видно). Хотя может быть лог можно настроить, чтобы выделить DB

плюсы:
*В отличие от Slony-никаких изменений в схему. Нормальная асинхронная репликация на основе лога запросов :)

Есть ли у кого-то такой опыт. Сильно сомневаюсь что я один до этого додумался :)

не взлетитИМХО, репликация получится такая же как в pgpool, только менее производительная (удвоенный поток записи на диск + парсинг).

Кстати имя базы можно логировать (log_line_prefix).

Спасибо, попробую на счет разделения попробую.

Минус pgpool что репликация синхронная. Для надежность все-таки лучше асинхронная, примерно такая как в MySQL.
А лог физически можно сливать на другой винт, возможно даже сетевой или лучше слейвовый.

Распарсиванием будет заниматься собственно слейв и заливать изменения в собственную базу. Дело мастера - положить в лог.

Остается только выяснить, на сколько корректно PostgreSQL определяет, изменяют запрос базу фактически. Все-таки существуют не явные с т.з. синтаксис изменения. Например
* при вызове хранимой функции. SELECT [функция]. Чем занимается функция внутри - синтаксис анализатор не знает.
* триггеры могуд изменять и другие таблицы... Хотя если и на слейве они есть - то исходный запрос вызовет тот же каскад изменений.

vkhai
Спасибо, попробую на счет разделения попробую.
Ура! Базу писать можно. Вот кусок лога (база test таблица test_1):

test 48dccbdf.5dd1LOG: statement: ALTER TABLE test_1 ADD PRIMARY KEY (id);

test 48dccbdf.5dd1NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "test_1_pkey" for table "
test_1"
test 48dccbdf.5dd1STATEMENT: ALTER TABLE test_1 ADD PRIMARY KEY (id);

test 48dccbfa.5dd4LOG: statement: INSERT INTO public.test_1("name") VALUES ('name_5'::text)
test 48dccbfa.5dd4LOG: statement: INSERT INTO public.test_1("name") VALUES ('name_6'::text)

ALTER TABLE - вот чего в репликации на триггерах не хватало. И отсутствие изменений в схеме.

Дальше попробую следующее:
* Договариваемся о формате
* Пишем парсер.
* Заливаем дамп изменений на слейв.

Выявлен "минус".
Судя по всему тип запроса для 'mod' READ/WRETE определяется по синтаксису.

Если сделать хранимую функцию делающую фактически INSERT:

CREATE OR REPLACE FUNCTION execute1("value" character varying)
RETURNS integer AS
$BODY$
DECLARE
BEGIN
INSERT INTO test_1 (name) VALUES (value);
RETURN 1;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;

то вызов её SELECT execute1('name_11'); в 'mod' лог не попадает
Это в принципе свойственно любым разделителям потоков READ/WRETE на основе синтаксиса.
В репликации на триггерах все работает корректно.

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

alex_v13По моему полный бред, только не обижайтесь.
Ни по надежности, ни по скорости это не прокатит.
Тем более, что данные prepared запросов в лог не попадют.
Единственный нормальный способ репликации - парсинг и выполнение WAL-логов.

От асинхронной репликации скорости никто не ждет. А вот на счет надежности я бы поспорил :)

На счет WAL-логов: нескоглко мегабайт изменений при возможных фактическиих изменениях пару килобайт - не совсем гуманно к трафику.

Хотя я читал, что хотят оптимизировать WAL журнал и относительно репликации связывают надежды именно с ним. Но пока много недостатков. Сейчас в случае WALL изменения данных в 1кб будут весить несколько Мб. В данном же случае почти точно 1кб (чуть больше за счет служебной информ.).

===
То что выше - идинтичные по структуре и данным мастер и слейв + компактный поток запросов на изменение в фактическом синтаксисе. PREPARED попадает как на мастер, так и на слейв. Ровно как и EXECUTE этого PREPARED.

Ещё один плюс, о котором подумал, не нужно синхронизировать SEQUENSES (ибо nextval и там и там) . :)

Вот немного более "причесанный" лог:

test LOG: statement: ALTER TABLE public.test_1 DROP CONSTRAINT test_1_pkey;
test LOG: statement: ALTER TABLE test_1 ADD PRIMARY KEY (id);

test NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "test_1_pkey" for table "test_1"
test STATEMENT: ALTER TABLE test_1 ADD PRIMARY KEY (id);

test LOG: statement: INSERT INTO public.test_1("name") VALUES ('name_7'::text)
test LOG: statement: INSERT INTO public.test_1("name") VALUES ('name_8'::text)
test LOG: statement: CREATE OR REPLACE FUNCTION execute1("value" character varying) RETURNS integer AS
$BODY$
DECLARE
BEGIN
INSERT INTO test_1 (name) VALUES (value);
RETURN 1;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;

test LOG: statement: INSERT INTO public.test_1("name") VALUES ('name_12'::text)
test LOG: statement: INSERT INTO public.test_1("name") VALUES ('name_13'::text)

Какая красота! Где ещё в АСИНХРОННОЙ репликации вы такое видели? ;)

vkhai...Где ещё в АСИНХРОННОЙ репликации вы такое видели? ;) Асинхронной репликации PostgreSQL конечно же.

Konstantin~UPDATE sometable SET something=random() WHERE ... будет классно реплицироватся

Вообще полезно ознакомится http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling Такие проблемы существуют и в репликации MySQL. Однако никто не считает её непригодной. Надо сказать что PostgreSQL до такой репликации ещё расти и рести :) Как собственно любая система репликация, работающая со стейтметнами, а не фактическими значениями (pgpool например) :)

Согласен. Тем не менее мне такой подход кажется тоже интересным.

В дополнение. Чтобы правильно работали транзакции нужно разделять сессии/процессы. Для каждой нити запускать свой процесс.

В выходные заработала первая версия :)