You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+17-2Lines changed: 17 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -34,8 +34,9 @@ See [sharding README](./tests/sharding/README.md) for sharding logic testing.
34
34
3.`COPY` protocol support.
35
35
4. Query cancellation.
36
36
5. Round-robin load balancing of replicas.
37
-
6. Banlist & failover
37
+
6. Banlist & failover.
38
38
7. Sharding!
39
+
8. Explicit query routing to primary or replicas.
39
40
40
41
### Session mode
41
42
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
56
57
### Round-robin load balancing
57
58
This is the novel part. PgBouncer doesn't support it and suggests we use DNS or a TCP proxy instead.
58
59
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.
60
62
61
63
### Banlist & failover
62
64
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';
82
84
83
85
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.
84
86
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.
0 commit comments