Skip to content

Commit 6d5ab79

Browse files
committed
readme
1 parent fccfb40 commit 6d5ab79

File tree

1 file changed

+17
-2
lines changed

1 file changed

+17
-2
lines changed

README.md

Lines changed: 17 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -34,8 +34,9 @@ See [sharding README](./tests/sharding/README.md) for sharding logic testing.
3434
3. `COPY` protocol support.
3535
4. Query cancellation.
3636
5. Round-robin load balancing of replicas.
37-
6. Banlist & failover
37+
6. Banlist & failover.
3838
7. Sharding!
39+
8. Explicit query routing to primary or replicas.
3940

4041
### Session mode
4142
Each client owns its own server for the duration of the session. Commands like `SET` are allowed.
@@ -56,7 +57,8 @@ this might be relevant given than this is a transactional pooler but if you're n
5657
### Round-robin load balancing
5758
This is the novel part. PgBouncer doesn't support it and suggests we use DNS or a TCP proxy instead.
5859
We prefer to have everything as part of one package; arguably, it's easier to understand and optimize.
59-
This pooler will round-robin between multiple replicas keeping load reasonably even.
60+
This pooler will round-robin between multiple replicas keeping load reasonably even. If the primary is in
61+
the pool as well, it'll be treated as a replica for read-only queries.
6062

6163
### Banlist & failover
6264
This is where it gets even more interesting. If we fail to connect to one of the replicas or it fails a health check,
@@ -82,6 +84,19 @@ SET SHARDING KEY TO '1234';
8284

8385
This sharding key will be hashed and the pooler will select a shard to use for the next transaction. If the pooler is in session mode, this sharding key has to be set as the first query on startup & cannot be changed until the client re-connects.
8486

87+
### Explicit read/write query routing
88+
89+
If you want to have the primary and replicas in the same pooler, you'd probably want to
90+
route queries explicitely to the primary or replicas, depending if they are reads or writes (e.g `SELECT`s or `INSERT`/`UPDATE`, etc). To help with this, we introduce some more custom syntax:
91+
92+
```sql
93+
SET SERVER ROLE TO 'primary';
94+
SET SERVER ROLE TO 'replica';
95+
```
96+
97+
After executing this, the next transaction will be routed to the primary or replica respectively. By default, all queries will be load-balanced between all servers, so if the client wants to write or talk to the primary, they have to explicitely select it using the syntax above.
98+
99+
85100

86101
## Missing
87102

0 commit comments

Comments
 (0)