Предотвращение дублирования данных с помощью логической репликации (PostgreSQL 10) - PullRequest
Новая
       39

Предотвращение дублирования данных с помощью логической репликации (PostgreSQL 10)

0 голосов
/ 08 января 2020

Я настроил два сервера с настройкой резервирования, используя конфигурацию pcsd. Обе машины состоят из Postgres 10 и логической репликации. Ниже приведены шаги для настройки логической репликации.

  • Взял PG Dump на Server1 с помощью команды pg_dump.
  • Восстановил его на Server2 с postgres 10 с помощью pg_restore.
  • Внесены изменения в файлы pg_hba.conf и postgres .conf.
  • Используются следующие команды для настройки логической репликации. 
CREATE PUBLICATION my_publication FOR ALL TABLES;
CREATE SUBSCRIPTION my_subscription 
  CONNECTION 'host=Server1 port=5432 password=postgres user=postgres dbname=database1' 
  PUBLICATION my_publication WITH (copy_data = false);
  • Перезапущены оба сервера.

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

...
2020-01-08 15:14:08.551 EET >LOG:  logical replication apply worker for subscription "my_subscription" has started
2020-01-08 15:14:08.559 EET >ERROR:  duplicate key value violates unique constraint "pk_xyz_instance"
2020-01-08 15:14:08.559 EET >DETAIL:  Key (xyz_instance_id)=(103) already exists.
2020-01-08 15:14:08.560 EET >LOG:  worker process: logical replication worker for subscription 23176 (PID 7411) exited with exit code 1
....

Поскольку мне нужны более ранние данные Server1, я взял дамп и восстановил его для других, используя copy_data как false, чтобы избежать дублирования.

После каждого переключения служб с Сервера1 на Сервер2 или наоборот, эти уникальные ошибки нарушения ограничений видны на Сервере2 (где службы неактивны)

Есть ли что-то, чего мне здесь не хватает при настройке репликации с использованием PostgreSQL 10.11?

Флаг copy_data не работает, как я ожидал?

1 Ответ

0 голосов
/ 08 января 2020

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

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

Лучше всего использовать физическую репликацию. Это не только проще и эффективнее, но вы также можете использовать pg_rewind для быстрого превращения старого основного сервера в новый резервный сервер.

...