Как сделать ALTER TABLE для slave для postgres 9.5 pglogical?

... Как быть?

Для начала загляните в логи PostgreSQL на master и slave.

все остальные изменения работают примерно так
SELECT pglogical.replicate_ddl_command('update public.stats SET ...

update - это не DDL

К сожалению в логах при

SELECT pglogical.replicate_ddl_command('ALTER TABLE public.stats ADD Phone CHARACTER VARYING(20)');

ничего. Равно как и при update

update проходит и так и так, и с ddl и без него, alter не проходит никак. Как делать alter?

Роль на slave имеет права superuser? На slave есть подписка на ddl_sql ?

Попробуйте в точности повторить конфигурацию и действия следующего примера:
http://oguridbtech.blogspot.com/2017/12/pglogical-installation-and.html

Роль это юзер postgres, который ходит как

host replication all 172.31.2.17/32 trust host all all 172.31.2.17/32 trust

то есть даже без пароля Остальные-то операции проходят, update, insert, delete

А подписка на ddl_sql на slave это как? Я делал настройки так

master

CREATE EXTENSION pglogical; SELECT pglogical.create_node(node_name := 'provider',dsn := 'host=172.31.9.8 port=5432 dbname=aaa user=postgres'); SELECT pglogical.create_replication_set (set_name:='insert_update',replicate_insert:=TRUE,replicate_update:=TRUE,replicate_delete:=TRUE,replicate_truncate := TRUE); SELECT pglogical.replication_set_add_table(set_name := 'insert_update', relation := 'aaa_video');

slave

CREATE EXTENSION pglogical; SELECT pglogical.create_node(node_name := 'subscriber',dsn := 'host=172.31.9.8 port=5432 dbname=aaa user=postgres'); SELECT pglogical.create_subscription( subscription_name := 'insert_update_subscription_to_cluster_a_db_prod', provider_dsn := 'host=172.31.9.8 dbname=aaa port=5432 user=postgres', replication_sets := ARRAY['insert_update'], synchronize_structure := FALSE, synchronize_data := FALSE);

Может быть тут что-то не то? если не указать synchronize_structure := FALSE, synchronize_data := FALSE то реплика down

... Может быть тут что-то не то?

Я ж вам дал ссылку на рабочую конфигурацию с примером репликации DDL-команды... Как вы думаете - для чего???

Ну и документацию по расширению pglogical прочитайте, чтобы использовать всё осмысленно:

pglogical.replicate_ddl_command(command text, replication_sets text[])
Execute locally and then send the specified command to the replication queue for execution
on subscribers which are subscribed to one of the specified replication_sets.

Parameters:
  command - DDL query to execute
  replication_sets - array of replication sets which this command should be associated with, default "{ddl_sql}"

... чтобы уж ткнуть носом:

master:
... dsn := 'host=172.31.9.8 port=5432 dbname=aaa user=postgres'
slave:
... dsn := 'host=172.31.9.8 port=5432 dbname=aaa user=postgres

Вы вообще чего куда реплицировать-то собрались?
Далее:

slave:
SELECT pglogical.create_subscription( ... replication_sets := ARRAY['insert_update']

Если вы явно подписались только на 'insert_update', то должны и на мастере использовать это в replicate_ddl_command.
Далее:

master:
SELECT pglogical.replication_set_add_table(set_name := 'insert_update', relation := 'aaa_video');

Если вы включили в 'insert_update' только таблицу aaa_video, то почему вы в стартовом топике работаете с таблицей public.stats?

Вы вообще факт успешной репликации как проверяете?

1) ну в описании даже к мастеру вроде как так и написано, строки одинаковые, это да, немного смущает. А какая на мастере должна быть? 2) insert_update - насколько я понял, просто название. delete там тоже работает, например 3) названия таблиц я тут меняю для сайта тут, по-этому могут быть несовпадения, на деле они иначе называются и факт репликации я проверяю, разумеется, селектом.

Если на мастере на такой-то id меняю например

update stats SET value=91 where id=6247; UPDATE 1

то на слейве, соответвенно, value в табличке меняется с 90 на 91, например. Если было 90. То есть update проходит как надо

Я обызательно попробую чётко по ссылке, но мне, к примеру, все таблицы не нужны, а только парочка. Иначе зачем логическая репликация?

ЯННП, нормальные люди останавливают репликацию, делают ALTER сначала на слейве, потом на мастере и только после этого возвращают репликацию взад. в постгресе какие-то особые механизмы для того, чтобы делать через задницу?

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

В обсуждаемом расширении postgresql предоставляется возможность делать ALTER и через одно место ))

Как это «останавливают репликацию» ?:))

То есть ты на 20 слейвах будешь «останавливать репликацию», чтобы столбик создать? А потом на мастере и уже потом запустишь снова все реплики? Клёво.

Обычно, в hot_standby, это делается исключительно на мастере. В мускуле как-то тоже с этим нет проблем. Это у 9.х какие-то хрени с этим

А какая на мастере должна быть?

В pglogical.create_node: для master - master-IP, для slave - slave-IP. Ну и на slave в pglogical.create_subscription - master-IP.
Похоже, этому pglogical IP-шники в create_node по барабану )

insert_update - насколько я понял, просто название

Ну да, название - только это название сконфигурированного набора таблиц (Replication Set), которые должны реплицироваться. А у вас как-то странно получается: вы на мастере включили в 'insert_update' только таблицу aaa_video, и подписались на слэйве только на 'insert_update', а реплицируется у вас stats. Чего-то тут не то...

В общем тебе спасибо, ты дал нормальную ссылку, где таки есть нужный пинок. Вот правильная команда, ПЕРЕДАЮЩАЯ alter

SELECT pglogical.replicate_ddl_command(command :='ALTER TABLE public.stats ADD Phone CHARACTER VARYING(20)',replication_sets:=ARRAY['insert_update']);

столбик Phone создаётся!!! на реплике. И удаляется. Так что всё супер!

Вот правильная команда, ПЕРЕДАЮЩАЯ alter ...

Похоже, в pglogical.replicate_ddl_command можно запихнуть любую SQL-команду - главное, указать нужное значение replication_sets. И эта любая команда выполнится у соответствующих подписчиков.

Интересный вопрос: почему у тебя таблица stats реплицируется при выполнении обычных UPDATE-командушек?

Вот почему простой update проходит - фиг знает. Но проходит, и не только update, но и delete

update, завёрнутый во всё это как alter, тоже отлично передаётся.

Вот почему простой update проходит - фиг знает. Но проходит, и не только update, но и delete

Попробуй на мастере:

SELECT pglogical.replication_set_remove_table(set_name := 'insert_update', relation := 'public.stats');
SELECT pglogical.replication_set_remove_table(set_name := 'default', relation := 'public.stats');

Будет после этого stats реплицироваться?

Нет, обычный update теперь не проходит. Только с ddl

Нет, обычный update теперь не проходит. Только с ddl

ну значит ты чего-то лишнего наконфигурил и забыл уже. Дропни pglogical везде и с нуля всё сделай.

Дропал я за время тестов раз 100500, серьёзно. Не поможет)

Дропал я за время тестов раз 100500, серьёзно. Не поможет)

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

Проверь хоть, какая из двух команд replication_set_remove_table реально отменяет репликацию. Если та, которая чистит default-набор, то, возможно, в нем болтается вся схема базы данных и ты каким-то макаром подписался на default-набор.
А какие-нибудь другие таблички реплицируются, которые ты не использовал в replicate_ddl_command?