172 похожих чатов

Господа, день добрый! Обращаюсь за советом к экспертному сообществу, какая из

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

4 ответов

19 просмотров

физицеская для ваших задач

Artem-M Автор вопроса
Konstantin Zaitsev
физицеская для ваших задач

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

> и я задумался над вопросом Вот прямо из введения в документации: 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."

вы у авторов кода спросите, может приложение требует транззакций с записью

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта