Melkij

Никак.

Если очень хотите головной боли и новых аварий по ночам вместо того чтобы спокойно спать - возьмите какой-нибудь autofailover типа patroni и прочих.

Критичная проблема фундаментальна - CAP теорема в целом и последствия split brain в частности.

major версия обязана совпадать, обязаны совпадать ряд флагов компиляции и некоторые настройки.

с centos 7 на убунту 20.04 реплицировать можно, но вы гарантированно попадаете на изменение правил сортировки строк в libc: https://wiki.postgresql.org/wiki/Locale_data_changes
Для переезда на другую ОС годится (подняли реплику, в нужный момент переключили на неё мастер и реиндексировали пострадавшие индексы), для долговременной работы уже не очень вариант.

Скорей всего упираетесь в производительность IO на временных файлах, увеличение logical_decoding_work_mem с этим должно помочь.
Затем посмотрите, не упираетесь ли в 100% cpu на этом процессе. logical decoding однопоточный, ему важна производительность в один поток. Тут ничего не поможет. Прочитать, понять и переупорядочить данные среди гигабайтов wal'ов всё равно придётся.

Репликация физическая:
реплицировать несколько мастеров в один слейв невозможно
можете запустить нужное число реплик на разных портах одной системы. Имена баз соответственно безразличны.

Репликация логическая:
я сильно удивлюсь если для какой-то из реализаций логической репликации будет проблемой разные имена баз. Но логическая репликация это логическая репликация. Про DDL операции надо будет помнить и вносить соответствующим образом.

Берёте и настраиваете.
По настройкам сети - любые извращения, лишь бы у вас был открыт tcp порт (тот на котором слушает ведущий, 5432 обычно) от реплики к ведущему.
За синхронность репликации отвечает synchronous_standby_names при включенном synchronous_commit

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

Внимание вопрос: зачем?

100 записей в секунду и 5 чтений в минуту - это ни о чём.
Писать 10000 записей в секунду - ну и? Никакой проблемы держать на одной железке и это в обычном OLTP, а не 99% write/1% read как у вас.

Взять адекватные диски, выкинуть к чертям докер. А для hot standby масштабировать запись не нужно. Простая и надёжная потоковая реплика.

монго можно разделить на X нод без шаманских танцев с бубном

Спасибо, хорошая шутка.

На всякий случай: вы ведь поминаете что никакая репликация для масштабирования записи не может помочь? Если каждый хост должен содержать копию данных - значит он должен все данные записать. Для масштабирования записи - шардирование верное слово. Только это не про сотни транзакций записей.

выводы \l+ и \dt+ в проблемной базе на мастере и реплике совпадают?

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

как более правильно выполнять репликацию

А что хотите-то?

Штатной логической репликацией (pg 10 и выше) или через pglogical или даже триггерной репликацией можете реплицировать в одну базу. Корректное внесение DDL за свой счёт.
Для физической репликации - репликация строго 1:1, потому разные инстансы базы. Всякие докеры абсолютно не нужны для этого. Разворачиваете реплики в разных директориях и на разных listen портах и всё. В ubuntu/debian штатные скрипты pg_ctlcluster даже есть чтобы инстансами удобно рулить.

Раз небольшая остановка сервиса допустима (времени около пары минут), то никакого мастер-мастер!
0) Поднимаете реплику мастер-слейв (имеющийся сервер мастер, новый - слейв)
1) когда слейв догнал мастера, останавливаете сервис (если сайт - вешаете заглушку "зайдите через пару минут")
2) разбираете реплику
3) правите конфиги сервиса, чтобы тот обращался к новому серверу
4) включаете сервис.

Пару лет назад на работе с нашим сисадмином именно так мигрировали. Без проблем с первой попытки и простой пара минут суммарно.