diff --git a/docs/configuration/users.toml/users.md b/docs/configuration/users.toml/users.md index f59d4bed..4dd75f39 100644 --- a/docs/configuration/users.toml/users.md +++ b/docs/configuration/users.toml/users.md @@ -17,6 +17,12 @@ This configuration controls which users are allowed to connect to PgDog. This is name = "bob" database = "prod" password = "opensesame" + + [[users]] + name = "migrator" + database = "prod" + password = "hunter_prod" + schema_admin = true ``` === "Helm chart" ```yaml @@ -27,6 +33,10 @@ This configuration controls which users are allowed to connect to PgDog. This is - name: bob database: prod password: opensesame + - name: migrator + database: prod + password: hunter_prod + schemaAdmin: true ``` ### `name` @@ -157,3 +167,12 @@ Default: **none** (not set) Overrides [`two_phase_commit_auto`](../pgdog.toml/general.md#two_phase_commit_auto) for this user. Default: **none** (not set) + +### `schema_admin` + +Marks this user as a schema administrator. Such user should have sufficient privileges to be able to run DDL commands and use replication protocol commands (e.g., `CREATE_REPLICATION_SLOT`). + +A `schema_admin` database user is required for following features: + +- [Sharding schema management](../../features/sharding/schema_management/manager.md) +- [Resharding](../../features/sharding/resharding/index.md#schema-admin) diff --git a/docs/features/sharding/resharding/index.md b/docs/features/sharding/resharding/index.md index ede08288..0bb4e858 100644 --- a/docs/features/sharding/resharding/index.md +++ b/docs/features/sharding/resharding/index.md @@ -58,6 +58,18 @@ Unlike `RESHARD`, the manual path does not cut over automatically: the data move !!! note "Traffic cutover" Traffic cutover requires careful synchronization to avoid data loss and a split-brain situation. The `RESHARD` command supports this for **single node** PgDog deployments only. The [Enterprise Edition](../../../enterprise_edition/index.md) provides a control plane, which supports traffic cutover with multiple PgDog containers. +## Requirements + +### Schema admin + +During the resharding the following permissions are required for the user used for connecting to the source and destination databases: + +- `CREATE` permissions on database and target schemas for creating tables and indexes +- `REPLICATION` role attribute for creating replication slots and reading the replication stream +- `SET ON PARAMETER session_replication_role` permission to bypass triggers during replication + +Users with these permissions should be defined in `users.toml` and marked as [`schema_admin`](../../../configuration/users.toml/users.md#schema_admin). PgDog will use this user to connect to the source and destination databases, so make sure to specify one for source and destination databases in the configuration (could be the same user or different for each database). + ## Terminology | Term | Description | diff --git a/docs/features/sharding/resharding/schema.md b/docs/features/sharding/resharding/schema.md index b53320b6..db940a10 100644 --- a/docs/features/sharding/resharding/schema.md +++ b/docs/features/sharding/resharding/schema.md @@ -153,28 +153,6 @@ Since creating indexes on large tables can take some time, PgDog provides an adm sql | CREATE INDEX CONCURRENTLY IF NOT EXISTS "users_email_idx" ON "public"."users" USING btree ("email") ``` -### Schema admin - -Schema sync creates tables, indexes, and other entities on the destination database. To make sure that this is done with a user with sufficient privileges (e.g., `CREATE` and `REPLICATION` permissions on the database), make sure to add such a user to [`users.toml`](../../../configuration/users.toml/users.md) and mark it as the schema administrator: - -=== "users.toml" - ```toml - [[users]] - name = "migrator" - database = "prod" - password = "hunter2" - schema_admin = true - ``` -=== "Helm chart" - ```yaml - users: - - name: migrator - database: prod - password: hunter2 - ``` - -PgDog will use this user to connect to the source and destination databases, so make sure to specify one for both databases in the configuration. - ## Cutover During the cutover, PgDog will execute last minute schema synchronization commands to make sure the destination sharded cluster works as expected. This involves putting back constraints that were removed for logical replication to work and moving sequence values.