mirror of
https://github.com/outbackdingo/patroni.git
synced 2026-08-25 14:53:37 +00:00
Alexander KukushkinandGitHub
4872ac51e0
Citus cluster (coordinator and workers) will be stored in DCS as a fleet of Patroni logically grouped together: ``` /service/batman/ /service/batman/0/ /service/batman/0/initialize /service/batman/0/leader /service/batman/0/members/ /service/batman/0/members/m1 /service/batman/0/members/m2 /service/batman/ /service/batman/1/ /service/batman/1/initialize /service/batman/1/leader /service/batman/1/members/ /service/batman/1/members/m1 /service/batman/1/members/m2 ... ``` Where 0 is a Citus group for coordinator and 1, 2, etc are worker groups. Such hierarchy allows reading the entire Citus cluster with a single call to DCS (except Zookeeper). The get_cluster() method will be reading the entire Citus cluster on the coordinator because it needs to discover workers. For the worker cluster it will be reading the subtree of its own group. Besides that we introduce a new method get_citus_coordinator(). It will be used only by worker clusters. Since there is no hierarchical structures on K8s we will use the citus group suffix on all objects that Patroni creates. E.g. ``` batman-0-leader # the leader config map for the coordinator batman-0-config # the config map holding initialize, config, and history "keys" ... batman-1-leader # the leader config map for worker group 1 batman-1-config ... ``` Citus integration is enabled from patroni.yaml: ```yaml citus: database: citus group: 0 # 0 is for coordinator, 1, 2, etc are for workers ``` If enabled, Patroni will create the database, citus extension in it, and INSERTs INTO `pg_dist_authinfo` information required for Citus nodes to communicate between each other, i.e. 'password', 'sslcert', 'sslkey' for superuser if they are defined in the Patroni configuration file. When the new Citus coordinator/worker is bootstrapped, Patroni adds `synchronous_mode: on` to the `bootstrap.dcs` section. Besides that, Patroni takes over management of some Postgres GUCs: - `shared_preload_libraries` - Patroni ensures that the "citus" is added to the first place - `max_prepared_transactions` - if not set or set to 0, Patroni changes the value to `max_connections*2` - wal_level - automatically set to logical. It is used by Citus to move/split shards. Under the hood Citus is creating/removing replication slots and they are automatically added by Patroni to the `ignore_slots` configuration to avoid accidental removal. The coordinator primary actively discovers worker primary nodes and registers/updates them in the `pg_dist_node` table using citus_add_node() and citus_update_node() functions. Patroni running on the coordinator provides the new REST API endpoint: `POST /citus`. It is used by workers to facilitate controlled switchovers and restarts of worker primaries. When the worker primary needs to shut down Postgres because of restart or switchover, it calls the `POST /citus` endpoint on the coordinator and the Patroni on the coordinator starts a transaction and calls `citus_update_node(nodeid, 'host-demoted', port)` in order to pause client connections that work with the given worker. Once the new leader is elected or postgres started back, they perform another call to the `POST/citus` endpoint, that does another `citus_update_node()` call with actual hostname and port and commits a transaction. After transaction is committed, coordinator reestablishes connections to the worker node and client connections are unblocked. If clients don't run long transaction the operation finishes without client visible errors, but only a short latency spike. All operations on the `pg_dist_node` are serialized by Patroni on the coordinator. It allows to have more control and ROLLBACK transaction in progress if its lifetime exceeding a certain threshold and there are other worker nodes should be updated.
73 lines
4.1 KiB
Gherkin
73 lines
4.1 KiB
Gherkin
Feature: citus
|
|
We should check that coordinator discovers and registers workers and clients don't have errors when worker cluster switches over
|
|
|
|
Scenario: check that worker cluster is registered in the coordinator
|
|
Given I start postgres0 in citus group 0
|
|
And I start postgres2 in citus group 1
|
|
Then postgres0 is a leader in a group 0 after 10 seconds
|
|
And postgres2 is a leader in a group 1 after 10 seconds
|
|
When I start postgres1 in citus group 0
|
|
And I start postgres3 in citus group 1
|
|
Then replication works from postgres0 to postgres1 after 15 seconds
|
|
Then replication works from postgres2 to postgres3 after 15 seconds
|
|
And postgres0 is registered in the coordinator postgres0 as the worker in group 0
|
|
And postgres2 is registered in the coordinator postgres0 as the worker in group 1
|
|
|
|
Scenario: coordinator failover updates pg_dist_node
|
|
Given I run patronictl.py failover batman --group 0 --candidate postgres1 --force
|
|
Then postgres1 role is the primary after 10 seconds
|
|
And replication works from postgres1 to postgres0 after 15 seconds
|
|
And "sync" key in a group 0 in DCS has sync_standby=postgres0 after 15 seconds
|
|
And postgres1 is registered in the coordinator postgres1 as the worker in group 0
|
|
When I run patronictl.py failover batman --group 0 --candidate postgres0 --force
|
|
Then postgres0 role is the primary after 10 seconds
|
|
And replication works from postgres0 to postgres1 after 15 seconds
|
|
And "sync" key in a group 0 in DCS has sync_standby=postgres1 after 15 seconds
|
|
And postgres0 is registered in the coordinator postgres0 as the worker in group 0
|
|
|
|
Scenario: worker switchover doesn't break client queries on the coordinator
|
|
Given I create a distributed table on postgres0
|
|
And I start a thread inserting data on postgres0
|
|
When I run patronictl.py switchover batman --group 1 --force
|
|
Then I receive a response returncode 0
|
|
And postgres3 role is the primary after 10 seconds
|
|
And replication works from postgres3 to postgres2 after 15 seconds
|
|
And "sync" key in a group 1 in DCS has sync_standby=postgres2 after 15 seconds
|
|
And postgres3 is registered in the coordinator postgres0 as the worker in group 1
|
|
And a thread is still alive
|
|
When I run patronictl.py switchover batman --group 1 --force
|
|
Then I receive a response returncode 0
|
|
And postgres2 role is the primary after 10 seconds
|
|
And replication works from postgres2 to postgres3 after 15 seconds
|
|
And "sync" key in a group 1 in DCS has sync_standby=postgres3 after 15 seconds
|
|
And postgres2 is registered in the coordinator postgres0 as the worker in group 1
|
|
And a thread is still alive
|
|
When I stop a thread
|
|
Then a distributed table on postgres0 has expected rows
|
|
|
|
Scenario: worker primary restart doesn't break client queries on the coordinator
|
|
Given I cleanup a distributed table on postgres0
|
|
And I start a thread inserting data on postgres0
|
|
When I run patronictl.py restart batman postgres2 --group 1 --force
|
|
Then I receive a response returncode 0
|
|
And postgres2 role is the primary after 10 seconds
|
|
And replication works from postgres2 to postgres3 after 15 seconds
|
|
And postgres2 is registered in the coordinator postgres0 as the worker in group 1
|
|
And a thread is still alive
|
|
When I stop a thread
|
|
Then a distributed table on postgres0 has expected rows
|
|
|
|
Scenario: check that in-flight transaction is rolled back after timeout when other workers need to change pg_dist_node
|
|
Given I start postgres4 in citus group 2
|
|
Then postgres4 is a leader in a group 2 after 10 seconds
|
|
And "members/postgres4" key in a group 2 in DCS has role=master after 3 seconds
|
|
When I run patronictl.py edit-config batman --group 2 -s ttl=20 --force
|
|
Then I receive a response returncode 0
|
|
And I receive a response output "+ttl: 20"
|
|
When I sleep for 2 seconds
|
|
Then postgres4 is registered in the coordinator postgres0 as the worker in group 2
|
|
When I shut down postgres4
|
|
Then There is a transaction in progress on postgres0 changing pg_dist_node
|
|
When I run patronictl.py restart batman postgres2 --group 1 --force
|
|
Then a transaction finishes in 20 seconds
|