こうもWindowsUpdateを強制されると、WindowsServerもWorkstationも嫌いになっちまうヽ(´ー｀)ノ 転職以来、大規模な現場経験を経て🐬MySQLを改め、🐘高可用性Pgpool＋PostreSQLを独学できたおかげで、FCスイッチ＆Hyper-Vマルチパス構成が理解できるようになったのは成果だ。素人にわかるわけないｗ

Multigresのドキュメント読んでたらコネクションプーリングの重要性が分かり、PgBouncer, Odyssey, PgCatを少し調べた後Pgpool-II, PgDogと進んでシャーディングと繋がって来た。 これまでAurora使っててなんか困ったらRDS Proxy使うくらいの解像度だったので、理解進んできた

From 25% to 62% just with this prompt. 1. grep -r SqlitePool\|sqlite::memory:\|\.atenea/atenea.db\|sqlx::Sqlite" crates/atenea-server/src/ --include="*.rs" 2. grep -r "PgPool\|DATABASE_URL\|sqlx::Postgres" crates/atenea-server/src/ --include="*.rs" | head -20 🙄🙄🙄🙄🙄🙄🙄🙄

News: Pgpool-II 4.7.1, 4.6.6, 4.5.11, 4.4.16 and 4.3.19 are now officially released. postgresql.org/about/news/pg…

pgpool-II 4.7.1, 4.6.6, 4.5.11, 4.4.16 and 4.3.19 released. These are the latest versions of each major series. You can download them from pgpool.net/mediawiki/index.p…

Btw, We’re already running a similar setup — one primary, multiple replicas. PgBouncer for connection pooling (helps a lot with read-heavy traffic). Pgpool for routing and failover. Reads scale nicely. Writes are still limited by the primary’s capacity. Replica lag and smooth failover — that’s where things get interesting.

А, я уж испугался, что в рамках запроса) Так то это прямое неизбежное следствие из "один реквест одна VM". Для того Господь и дал нам ремингтон со скользящим затвором то есть pgpool и прочее такое.

News: Pgpool-II 4.7.0 is now released. postgresql.org/about/news/pg…

News: Pgpool-II 4.6.5, 4.5.10, 4.4.15 and 4.3.18 released. postgresql.org/about/news/pg…

News: Pgpool-II 4.7 beta1 is now released postgresql.org/about/news/pg…

News: Pgpool-II 4.6.4, 4.5.9, 4.4.14, 4.3.17 and 4.2.24 released. postgresql.org/about/news/pg…

Plusieurs nodes, sites géographiques éloignés ... Master / replica -> streaming réplication / tunel SSH. Attention, À la gestion de la bascule Master <-> Replica inversion de la répli après bascule Cluster HA 1 node master, et X nodes réplica read only PgPool-II load balancing

例に出したDBMSの件、今ならpgsqlにpgpoolでプロキシしてみたいなやり方を一回やっておけばなんだけど、20年前のoracle...でも当時だって名前ベースでサーバ呼べばリカバリプランは立てやすかったんじゃない？と言われればそれはそう

Pgpoolを停止してPgBouncerに切り替える実験をします。 サービスが中断、不安定になる可能性があります。 ご迷惑をおかけいたしますがよろしくお願いいたします。

[概要] PgpoolのかわりにPgBouncerを導入します。導入にともなってサービスが停止したり接続が不安定になる可能性があります。ご迷惑をおかけいたしますが、よろしくお願いいたします。

At this point its a pattern: stuff breaks, you apologize, write a long postmortem, swear it will never happen again. And then it does again. And now we find out you do not even run a proper external connection pooler (like PgBouncer or Pgpool). Just per-container lifetimes ticking away until everything collapses in sync every 15 minutes. Seriously?

You’re doing it wrong, if your Postgres DB is overloaded or read replicas are idle. From our latest #GeekSpeak episode, learn how Pgpool-II AWS RDS can optimize traffic and scale smoothly.👇🏼 youtube.com/watch?v=Uwy-Cz95… #GeekyAnts

Exactly. “Read-your-writes” consistency sounds like common sense, but once you introduce replicas, it gets tricky. On a single node, life is simple — the transaction log is sequential, so once a write is acknowledged, any immediate read will see it. But in a primary/replica setup, replication lag can break that illusion. If your read gets routed to a replica that hasn’t applied the latest write yet, you’ll see stale data (or even a missing record). That’s why many systems enforce: Writes critical reads → primary Other reads → replicas Async and semi-sync replication trade off consistency for performance/availability, so you can’t guarantee read-your-writes if your reads hit replicas. Synchronous replication does guarantee it, but at the cost of higher latency, since the primary waits for acknowledgments from replicas. --- A Real-world example: In MySQL, the default is asynchronous replication. If you write a row to the primary and then immediately query a replica, you might not see it because the replication thread hasn’t applied the change yet. Semi-sync MySQL helps by requiring at least one replica to confirm receipt, but that still doesn’t guarantee your query hits that replica. In Postgres, tools like Patroni or pgpool-II let you route queries smartly — for example, always directing a client’s reads to the primary right after a write to ensure read-your-writes, while still distributing other reads to replicas. So the rule of thumb: if you need strong consistency (like after creating a record and immediately fetching it), stick to the primary. If you just need scale and can tolerate some staleness, replicas are fine.

PgBouncer VS PgPool: Quem ganha? (Carlos Correa Silva Alves) #pgconfbr

The best VPS you can get from Hetzner is around ~$600 per month. When you reach the limits of that VPS, you can split frontend, backend, database. So about $1.8k. But how do you scale further from there without too much hassle? Last time we used pgpool then three database servers. But that was a huge pain to build; At that point, your AWS DB costs probably $20k a month; Anyways; How do you scale beyond those single server limits with your VPS setup? At some point you need shared sessions over redis, connection stickyness, etc.