Добрый день!
Под кластером я подразумеваю один или несколько серверов PostgreSQL, представляющих одно логическое целое.
В контексте вопроса у нас есть 2 кластера СУБД на базе PostgreSQL 11.11 с разными БД.
Первый кластер СУБД состоит из 3 серверов PostgreSQL (один ведущий и два ведомых сервера, физическая синхронная репликация) и балансировщика.
Второй кластер СУБД состоит пока только из одного сервера PostgreSQL (но планируется добавить еще две реплики и балансировщик, аналогично как для первого кластера).
Сейчас эти кластеры никак не связаны между собой, за исключением разве что использования postgres_fdw и dblink.
На кластере №2 есть база данных, запросы (SELECT) в которую из кластера №1 через расширение postgres_fdw выполняются довольно медленно. Обычно analyze для внешних таблиц помогает. Однако тут дело в накладных расходах на установку соединения с другим сервером.
Если создать резервную копию этой БД на кластере 2 и восстановить ее на кластере 1, и в дальнейшем через postgres_fdw делать запросы (один и тот же сервер, но разные БД), то ситуация гораздо лучше по быстродействию.
Перенести целиком всю БД из кластера 2 в кластер 1 нельзя, т.к. в ней есть закрытые данные. Однако есть интересуемая таблица, которая не содержит закрытых данных и для повышения скорости хотелось бы иметь ее копию в кластере 1. Причем без использования всяких ручных обновлений (т.е. refresh materialized view и подобные вещи - это не то), т.е. применить логическую репликацию одной таблицы из кластера 2 в кластер 1.
Ранее какое-то время мы использовали логическую репликацию, о проблемах при ее использовании мы знаем.
Я не нашел в документации одновременного использования логической и физической репликации.
По идее проблем быть не должно, но:
1. Сколько слотов логической репликации будет создано на мастере (кластер №2) после создания публикации и подключении подписчика(-ков)? Ведь после того как я создам подписку на публикацию мастера кластера №1, эти же команды по подписке отреплицируются через физическую репликацию на две других реплики кластера 1.
2. Понятно, что две реплики кластера №1 находятся в режиме "только чтение" и даже если они что-то и вытянут с мастера кластера №2, ничего плохого, кроме лишнего трафика, не случится. Они получат обновления от своего мастера в кластере №1 по физической репликации. Однако, несмотря на то, что в кластере №1 репликация синхронная, мастеру кластера № 1 достаточно подтверждения от любой реплики, т.е. мы легко можем перезагружать или даже выключить одну любую реплику в кластере №1 и это не приведет к остановке мастера в кластере №1. Но перезагрузка или выключение реплики в кластере №2, тогда приведет к тому, что слот на мастере кластера №2 останется и для этого слота публикующий сервер будет копить WAL, ожидая подключения, что может привести к переполнению места на диске.
3. Возможно все наши опасения напрасны и не все машины в кластере №1 на самом деле подписываются на публикацию из второго кластера, а только мастера кластера №1. Но мы можем производить переключение репликации в кластере 1 используя в качестве мастера, то одну, то другую реплику (предварительно "запромоутив" ее до мастера). Тогда потребуется каждого такого нового мастера из кластера №1 подписывать на публикацию с мастера кластера №2?

Все машины боевые, делать такого рода тесты на них опасно (и места свободного на дисках не так много). Уверен, что кто-то точно использует такие схемы репликации. Как на самом деле это все работать будет?

А разве слот на публикующем сервере будет только один? Я вижу такой ход событий:
1. Создали публикацию в кластере №2.
2. Создали подписку на мастере в кластере №1.
3. Эта же команда create subscription отработает и на всех репликах кластера №1.
4. Мастер кластера № 1 подключится к публикующему серверу в кластере №2, создав слот репликации.
5. Реплики кластера №1 также подключатся к публикующему серверу в кластере №2, создав еще слоты репликации.

Или команда create subscription будет проигнорирована на репликах по протоколу репликации (walreciever), однако еще есть путь через архивный каталог (на тот случай, если физическая реплика отстанет в кластере №1)