-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
server,pgwire: use a single SQL listener for multiple tenants #92580
Conversation
350d669
to
7437311
Compare
1603461
to
3feea70
Compare
7437311
to
d2ea8ad
Compare
3feea70
to
9cca02f
Compare
If I understand correctly, this only works if we connect to the KV server, right (i.e. based on |
@jaylim-crl I don't understand your question. The logic implemented here only exists for shared-process multitenancy, which we've estimated will only be used in Self-hosted / Dedicated. We may want to have a conversation about whether (and how) sqlproxy will be used with a multitenancy-enabled CC dedicated, but i'm not sure we need to have it now. |
I see. Thanks for the clarification; that explains it. |
d2ea8ad
to
6f7b42b
Compare
9cca02f
to
32a0f50
Compare
I'm confused about what
I'd have expected |
That is exactly what's happening.
correct. |
6f7b42b
to
a8ba3a0
Compare
32a0f50
to
b754185
Compare
Release note: None
We need the read/parse of the parameters to be tenant-independent, so the function cannot contain tenant-specific configuration. Release note: None
This commit extracts the memory reservation into a tenant-independent memory pool. Release note: None
This demonstrates that the logic is tenant-independent and makes it ready to move into the PreServe() function. Release note: None
Release note: None
Release note: None
Release note: None
Release note: None
Release note: None
Release note: None
Release note: None
Release note: None
Release note: None
Release note: None
b4c6bf4
to
e5e3f31
Compare
88b0316
to
4067e7e
Compare
This patch introduces the new cluster setting `server.connector.tenant_name`, which determines which tenant to use to serve client connections when the client does not specify a tenant. This defaults to `system`, the name of the system tenant. Release note: None
This commit implements tenant routing using a single SQL network listener. The tenant name can be specified: - via the client status param `options`, e.g. `options=-ccluster=hello` - via the database name, e.g. `cluster:hello/mydb`. Release note (backward-incompatible change): If a SQL database is created with a name that starts with `cluster:...` (e.g. `CREATE DATABASE "cluster:foo"`, clients will no longer be able to connect to it directly via a pre-existing URL connection string. The URL needs to be modified in this case. For example: Previously: ``` postgres://servername/cluster:foo ``` Now: ``` postgres://servername/cluster:foo&options=-ccluster=system ``` (What this does: it selects the tenant named `system` and then the database named `cluster:foo` inside it. When the `-ccluster:system` option is not specified, `cluster:foo` in the database name position is interpreted as a request to connect to a tenant named `foo`, which likely does not exist.) Connections to databases whose name does not start with `cluster:` (the most common case) are not affected by this change.
4067e7e
to
a5ca120
Compare
TFYRs! bors r=rafiss |
Build succeeded: |
Parent PRs:
SQLServer
#92579Fixes #84585.
Informs #94310.
Epic: CRDB-14537
This commit implements tenant routing using a single SQL network listener.
The tenant name can be specified:
options
, e.g.options=-ccrdb:tenant=hello
crdb:tenant-hello.defaultdb
.Release note (backward-incompatible change): If a SQL database is created with a name that starts with
crdb:tenant-
(e.g.CREATE DATABASE "crdb:tenant-foo"
, clients will no longer be able to connect to it directly.