реплик практичнее? Логическая или физическая?
Преследуемая цель - разгрузка мастера и в случае падения мастера быстрое переключение на слейв.
физицеская для ваших задач
А можно чуть подробнее? Просто в целом с логической тоже это возможно, перевод реплики в мастер и переключение проекта на нее вроде представляется несложным, почему вы отдаете приоритет физической?
> и я задумался над вопросом Вот прямо из введения в документации: The typical use-cases for logical replication are: . Sending incremental changes in a single database or a subset of a database to subscribers as they occur. . Firing triggers for individual changes as they arrive on the subscriber. . Consolidating multiple databases into a single one (for example for analytical purposes). . Replicating between different major versions of PostgreSQL. . Replicating between PostgreSQL instances on different platforms (for example Linux to Windows) . Giving access to replicated data to different groups of users. . Sharing a subset of the database between multiple databases. Если там у вас не один из этих случаев — получите только её недостатки (кроме того, она технически сложнее, что означает... можете поискать, сколько bug reports про неё посылают в -bugs... хоть ежемесячно). > То есть в физической указанных ограничений по реплицированым объектам нет? Физическая просто реплицирует весь кластер баз данных 1:1 (есть тонкости с tablespaces, но это и всё). > Логическая тоже работает ;) Да, для какого-то определения понятия "работает". ;) > ACID, на самом деле, тоже было бы неплохо иметь Ну так с репликацией его нет, потому что асинхронная отстаёт, а синхронная... всё равно может отставать (несмотря на то, что пишут в документации — тут это однажды бурно обсуждалось (spoiler: воз и ныне там)). ;( Кроме того ( https://www.postgresql.org/docs/current/mvcc-caveats.html ): "Support for the Serializable transaction isolation level has not yet been added to hot standby replication targets (described in Section 27.4). The strictest isolation level currently supported in hot standby mode is Repeatable Read. While performing all permanent database writes within Serializable transactions on the primary will ensure that all standbys will eventually reach a consistent state, a Repeatable Read transaction run on the standby can sometimes see a transient state that is inconsistent with any serial execution of the transactions on the primary."
вы у авторов кода спросите, может приложение требует транззакций с записью
Обсуждают сегодня