Постграфиль возможно умеет

быстро реализовать - это за 15 минут развернуть отказоучтойчивый кластер без танцев с бубном, написав только один маленький json с адресами, это очень дешево, и для этого даже не нужен бородатый специалист

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

а как в пг сделать переключение мастера на слейв быстро? и чтобы мастер при восстановлении сети становился слейвом сам и подтягивал журнал?

Насколько я понимаю при логической репликации эта проблема уходит как-то иначе

как она уходит?

Там нет понятий мастер и слейв вообще

что там происходит при невозможности писать в базу?

Всем привет!
Подскажите как заставить PM2 сделать так чтобы при обновлении статики он подтягивал новую?

?

ты думаешь задав вопрос три раза тебе помогут? )

2ой раз

статикой должен управлять nginx

A subscription is the downstream side of logical replication. The node where a subscription is defined is referred to as the subscriber. A subscription defines the connection to another database and set of publications (one or more) to which it wants to subscribe.

The subscriber database behaves in the same way as any other PostgreSQL instance and can be used as a publisher for other databases by defining its own publications.

A subscriber node may have multiple subscriptions if desired. It is possible to define multiple subscriptions between a single publisher-subscriber pair, in which case care must be taken to ensure that the subscribed publication objects don't overlap.

Each subscription will receive changes via one replication slot (see Section 26.2.6). Additional temporary replication slots may be required for the initial data synchronization of pre-existing table data.

A logical replication subscription can be a standby for synchronous replication (see Section 26.2.8). The standby name is by default the subscription name. An alternative name can be specified as application_name in the connection information of the subscription.

Ну там история такая что для каждой новой версии создается новая папка откуда pm2 стартует сервисы

и вот когда из новой версии стартуем, там остается старая

это шо за дебилизм

зачем?

Synchronous replication offers the ability to confirm that all changes made by a transaction have been transferred to one or more synchronous standby servers. This extends that standard level of durability offered by a transaction commit. This level of protection is referred to as 2-safe replication in computer science theory, and group-1-safe (group-safe and 1-safe) when synchronous_commit is set to remote_write.

When requesting synchronous replication, each commit of a write transaction will wait until confirmation is received that the commit has been written to the write-ahead log on disk of both the primary and standby server. The only possibility that data can be lost is if both the primary and the standby suffer crashes at the same time. This can provide a much higher level of durability, though only if the sysadmin is cautious about the placement and management of the two servers. Waiting for confirmation increases the user's confidence that the changes will not be lost in the event of server crashes but it also necessarily increases the response time for the requesting transaction. The minimum wait time is the round-trip time between primary to standby.