Отстраняване на неизправности в клъстера PostgreSQL
Информация
Цялата процедура трябва да се изпълни като root. За да повишите привилегиите си до root, можете да използвате командата su -.
Грешките при свързване с базата данни на клъстера PostgreSQL на CyberElements Bastion може да имат различни причини. Тази част представя общ метод за отстраняване на неизправности, който трябва да адаптирате към вашия случай.
Проверка на състоянието на клъстера
Информация
Проверката на състоянието на клъстера позволява бързо да се открие отказалият възел или възли.
Можете да проверите състоянието на клъстера със следната команда, която трябва да се изпълни на всеки възел на клъстера PostgreSQL:
| patronictl -c /etc/patroni/config.yml topology
|
Пример за резултат на работеща платформа
| + Cluster: 15-cleanroomvault5 ------+---------+---------+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+------------------+----------------+---------+---------+----+-----------+
| PSQL_3 | psql_3 | Leader | running | 2 | |
| + PSQL_1 | psql_1 | Replica | running | 2 | 0 |
| + PSQL_2 | psql_2 | Replica | running | 2 | 0 |
+------------------+----------------+---------+---------+----+-----------+
|
В резултата по-горе всичко показва, че клъстерът PostgreSQL работи: забавянето е 0 MB за всички възли Replica и всички възли са в списъка със състояние running. Трябва да получите този резултат на всички възли, за да потвърдите, че patroni и etcd работят.
Пример за резултат при проблем с комуникацията между възлите
| + Cluster: 15-cleanroomvault5 ------+---------+---------+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+------------------+----------------+---------+---------+----+-----------+
| PSQL_3 | psql_3 | Leader | running | 2 | |
| + PSQL_1 | psql_1 | Replica | running | 2 | 230 |
| + PSQL_2 | psql_2 | Replica | running | 2 | 0 |
+------------------+----------------+---------+---------+----+-----------+
|
В резултата по-горе забавянето от 230 MB е необичайно: то може да показва проблем с комуникацията между възел 3 и възел 1.
Ако проблемът продължава след няколко часа, това го потвърждава.
Пример за резултат, когато даден възел не е правилно стартиран или спрян
| + Cluster: 15-cleanroomvault5 ------+---------+---------+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+------------------+----------------+---------+---------+----+-----------+
| PSQL_3 | psql_3 | Leader | running | 2 | |
| + PSQL_1 | psql_1 | Replica | started | 2 | unknown |
| + PSQL_2 | psql_2 | Replica | stopped | 2 | unknown |
+------------------+----------------+---------+---------+----+-----------+
|
В резултата по-горе състоянието (колона State) показва, че възел 1 се стартира. Ако състоянието started се запази няколко минути или дори часове, може да има проблем с patroni или etcd на този възел.
Възел 2 е в състояние stopped: той е спрян. Когато възел на клъстера откаже, тази информация се показва само временно, преди възелът да бъде премахнат от списъка.
Пример за резултат, когато etcd откаже на текущия възел
| 2026-04-09 16:21:39,482 - WARNING - Retrying (Retry(total=1, connect=None, read=None, redirect=0, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fcaa1618390>: Failed to establish a new connection: [Errno 111] Connection refused')': /version
2026-04-09 16:21:39,482 - WARNING - Retrying (Retry(total=0, connect=None, read=None, redirect=0, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fcaa1618c10>: Failed to establish a new connection: [Errno 111] Connection refused')': /version
2026-04-09 16:21:39,483 - ERROR - Failed to get list of machines from https://PSQL_3:2379/v2: MaxRetryError("HTTPSConnectionPool(host='psql_3', port=2379): Max retries exceeded with url: /version (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fcaa1619490>: Failed to establish a new connection: [Errno 111] Connection refused'))")
|
Резултатът по-горе показва грешка при свързване с etcd, която не позволява извличането на състоянието на клъстера PostgreSQL.
Пример за резултат, когато един от възлите е излязъл от синхрон
| + Cluster: 15-cleanroomvault5 ------+---------+---------+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+------------------+----------------+---------+---------+----+-----------+
| PSQL_3 | psql_3 | Leader | running | 3 | |
| + PSQL_1 | psql_1 | Replica | running | 2 | 230 |
| + PSQL_2 | psql_2 | Replica | running | 3 | 0 |
+------------------+----------------+---------+---------+----+-----------+
|
В резултата по-горе възелът PSQL_1 вече не е на същата стойност TL като останалите. За да работи клъстерът, всички възли трябва да са на една и съща стойност TL: разлика показва, че един от възлите е излязъл от синхрон.
За да решите този проблем, следвайте процедурата за десинхронизация на възел.
Проверка на състоянието на услугите
След като отказалият възел бъде идентифициран, трябва да идентифицирате неправилно работещата услуга. Двете основни услуги, използвани в клъстера PostgreSQL, са patroni и etcd.
Информация
Услугата patroni зависи от услугата etcd: ако etcd не работи, patroni също няма да работи.
За да идентифицирате отказалата услуга, можете да изпълните следните команди:
| systemctl status etcd
systemctl status patroni
|
Тези команди показват състоянието на услугата заедно с последните ѝ 10 реда от дневника.
Предупреждение
Услуга със състояние active (running) не работи непременно правилно: тя може да е стартирана, докато записва грешки в дневника. Затова е важно да прочетете дневниците на услугата, за да разберете действителното ѝ състояние.
Пример за резултат за etcd, когато услугата работи
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22 | ● etcd.service - etcd - highly-available key value store
Loaded: loaded (/lib/systemd/system/etcd.service; enabled; preset: enabled)
Active: active (running) since Thu 2026-04-09 16:40:01 CEST; 21h ago
Docs: https://etcd.io/docs
man:etcd
Main PID: 283425 (etcd)
Tasks: 7 (limit: 2227)
Memory: 73.2M
CPU: 51min 9.223s
CGroup: /system.slice/etcd.service
└─283425 /usr/bin/etcd
Apr 10 09:26:31 PSQL_1 etcd[283425]: store.index: compact 1624026
Apr 10 09:26:31 PSQL_1 etcd[283425]: finished scheduled compaction at 1624026 (took 325.098µs)
Apr 10 10:26:31 PSQL_1 etcd[283425]: store.index: compact 1624386
Apr 10 10:26:31 PSQL_1 etcd[283425]: finished scheduled compaction at 1624386 (took 417.797µs)
Apr 10 11:26:31 PSQL_1 etcd[283425]: store.index: compact 1624746
Apr 10 11:26:31 PSQL_1 etcd[283425]: finished scheduled compaction at 1624746 (took 1.706489ms)
Apr 10 12:26:31 PSQL_1 etcd[283425]: store.index: compact 1625106
Apr 10 12:26:31 PSQL_1 etcd[283425]: finished scheduled compaction at 1625106 (took 300.098µs)
Apr 10 13:26:31 PSQL_1 etcd[283425]: store.index: compact 1625466
Apr 10 13:26:31 PSQL_1 etcd[283425]: finished scheduled compaction at 1625466 (took 311.398µs)
|
Пример за резултат за etcd, когато услугата е в състояние на грешка
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20 | × etcd.service - etcd - highly-available key value store
Loaded: loaded (/lib/systemd/system/etcd.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Fri 2026-04-10 14:15:26 CEST; 5s ago
Duration: 21h 35min 20.382s
Docs: https://etcd.io/docs
man:etcd
Process: 454701 ExecStart=/usr/bin/etcd $DAEMON_ARGS (code=exited, status=1/FAILURE)
Main PID: 454701 (code=exited, status=1/FAILURE)
CPU: 12ms
Apr 10 14:15:26 PSQL_1 etcd[454701]: [WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag instead
Apr 10 14:15:26 PSQL_1 etcd[454701]: etcd Version: 3.4.23
Apr 10 14:15:26 PSQL_1 etcd[454701]: Git SHA: Not provided (use ./build instead of go build)
Apr 10 14:15:26 PSQL_1 etcd[454701]: Go Version: go1.19.8
Apr 10 14:15:26 PSQL_1 etcd[454701]: Go OS/Arch: linux/amd64
Apr 10 14:15:26 PSQL_1 etcd[454701]: setting maximum number of CPUs to 1, total number of available CPUs is 1
Apr 10 14:15:26 PSQL_1 etcd[454701]: error listing data dir: /var/lib/etcd/cleanroom
Apr 10 14:15:26 PSQL_1 systemd[1]: etcd.service: Main process exited, code=exited, status=1/FAILURE
Apr 10 14:15:26 PSQL_1 systemd[1]: etcd.service: Failed with result 'exit-code'.
Apr 10 14:15:26 PSQL_1 systemd[1]: Failed to start etcd.service - etcd - highly-available key value store.
|
В резултата по-горе услугата etcd е със състояние failed, а грешката, която ѝ е попречила да стартира, е тази на ред 17: услугата не може да прочете съдържанието на директорията /var/lib/etcd/cleanroom. В този случай коригирайте разрешенията за директорията.
Пример за резултат за patroni, когато услугата работи
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29 | ● patroni.service - Runners to orchestrate a high-availability PostgreSQL
Loaded: loaded (/lib/systemd/system/patroni.service; enabled; preset: enabled)
Drop-In: /etc/systemd/system/patroni.service.d
└─local.conf
Active: active (running) since Thu 2026-04-09 16:40:06 CEST; 22h ago
Process: 283510 ExecStartPre=/usr/bin/testetcd.py (code=exited, status=0/SUCCESS)
Main PID: 283517 (patroni)
Tasks: 13 (limit: 2227)
Memory: 56.1M
CPU: 26min 54.918s
CGroup: /system.slice/patroni.service
├─283517 /usr/bin/python3 /usr/bin/patroni /etc/patroni/config.yml
├─283537 /usr/lib/postgresql/15/bin/postgres -D /var/lib/postgresql/15/cleanroomvault5 --config-file=/etc/postgresql/15/cleanroomvault5/postgresql.conf"--listen_addresses=*" --port=5432 --cluster_name=15-cleanroomvault5 --wal_level=replica --hot_standby=on --max_connections=100 --max_wal_senders=10--max_prepared_transactions=0 --max_locks_per_transaction=64 --track_commit_timestamp=off --max_replication_slots=10 --max_worker_processes=8 --wal_log_hints=on
├─283538 "postgres: 15-cleanroomvault5: logger "
├─283540 "postgres: 15-cleanroomvault5: checkpointer "
├─283541 "postgres: 15-cleanroomvault5: background writer "
├─283542 "postgres: 15-cleanroomvault5: startup recovering 00000003000000000000000F"
├─283545 "postgres: 15-cleanroomvault5: walreceiver "
└─283547 "postgres: 15-cleanroomvault5: postgres postgres [local] idle"
Apr 10 14:51:07 PSQL_1 patroni[283517]: 2026-04-10 14:51:07,381 INFO: no action. I am (PSQL_1), a secondary, and following a leader (PSQL_2)
Apr 10 14:51:17 PSQL_1 patroni[283517]: 2026-04-10 14:51:17,428 INFO: no action. I am (PSQL_1), a secondary, and following a leader (PSQL_2)
Apr 10 14:51:27 PSQL_1 patroni[283517]: 2026-04-10 14:51:27,381 INFO: no action. I am (PSQL_1), a secondary, and following a leader (PSQL_2)
Apr 10 14:51:37 PSQL_1 patroni[283517]: 2026-04-10 14:51:37,428 INFO: no action. I am (PSQL_1), a secondary, and following a leader (PSQL_2)
Apr 10 14:51:47 PSQL_1 patroni[283517]: 2026-04-10 14:51:47,381 INFO: no action. I am (PSQL_1), a secondary, and following a leader (PSQL_2)
Apr 10 14:51:57 PSQL_1 patroni[283517]: 2026-04-10 14:51:57,428 INFO: no action. I am (PSQL_1), a secondary, and following a leader (PSQL_2)
Apr 10 14:52:07 PSQL_1 patroni[283517]: 2026-04-10 14:52:07,381 INFO: no action. I am (PSQL_1), a secondary, and following a leader (PSQL_2)
Apr 10 14:52:17 PSQL_1 patroni[283517]: 2026-04-10 14:52:17,428 INFO: no action. I am (PSQL_1), a secondary, and following a leader (PSQL_2)
Apr 10 14:52:27 PSQL_1 patroni[283517]: 2026-04-10 14:52:27,381 INFO: no action. I am (PSQL_1), a secondary, and following a leader (PSQL_2)
Apr 10 14:52:37 PSQL_1 patroni[283517]: 2026-04-10 14:52:37,474 INFO: no action. I am (PSQL_1), a secondary, and following a leader (PSQL_2)
|
Пример за резултат за patroni, когато услугата е в състояние на грешка
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29 | ● patroni.service - Runners to orchestrate a high-availability PostgreSQL
Loaded: loaded (/lib/systemd/system/patroni.service; enabled; preset: enabled)
Drop-In: /etc/systemd/system/patroni.service.d
└─local.conf
Active: active (running) since Thu 2026-04-09 16:40:06 CEST; 23h ago
Process: 283510 ExecStartPre=/usr/bin/testetcd.py (code=exited, status=0/SUCCESS)
Main PID: 283517 (patroni)
Tasks: 12 (limit: 2227)
Memory: 61.7M
CPU: 28min 8.337s
CGroup: /system.slice/patroni.service
├─283517 /usr/bin/python3 /usr/bin/patroni /etc/patroni/config.yml
├─283537 /usr/lib/postgresql/15/bin/postgres -D /var/lib/postgresql/15/cleanroomvault5 --config-file=/etc/postgresql/15/cleanroomvault5/postgresql.conf "--listen_addresses=*" --port=5432 --cluster_name=15-cleanroomvault5 --wal_level=replica --hot_standby=on --max_connections=100 --max_wal_senders=10 --max_prepared_transactions=0 --max_locks_per_transaction=64 --track_commit_timestamp=off --max_replication_slots=10 --max_worker_processes=8 --wal_log_hints=on
├─283538 "postgres: 15-cleanroomvault5: logger "
├─283540 "postgres: 15-cleanroomvault5: checkpointer "
├─283541 "postgres: 15-cleanroomvault5: background writer "
├─283542 "postgres: 15-cleanroomvault5: startup recovering 00000003000000000000000F"
└─283547 "postgres: 15-cleanroomvault5: postgres postgres [local] idle"
Apr 10 15:52:37 PSQL_1 patroni[283517]: 2026-04-10 15:52:37,680 WARNING: Loop time exceeded, rescheduling immediately.
Apr 10 15:52:41 PSQL_1 patroni[283517]: 2026-04-10 15:52:37,681 INFO: Lock owner: PSQL_2; I am PSQL_1
Apr 10 15:52:41 PSQL_1 patroni[283517]: 2026-04-10 15:52:41,069 ERROR: Request to server https://PSQL_3:2379 failed: ReadTimeoutError("HTTPSConnectionPool(host='psql_3', port=2379): Read timed out. (read timeout=3.3331721344341836)")
Apr 10 15:52:41 PSQL_1 patroni[283517]: 2026-04-10 15:52:41,069 INFO: Reconnection allowed, looking for another server.
Apr 10 15:52:41 PSQL_1 patroni[283517]: 2026-04-10 15:52:41,069 INFO: Retrying on https://PSQL_1:2379
Apr 10 15:52:41 PSQL_1 patroni[283517]: 2026-04-10 15:52:41,073 ERROR: Request to server https://PSQL_1:2379 failed: MaxRetryError("HTTPSConnectionPool(host='psql_1', port=2379): Max retries exceeded with url: /v3/lease/keepalive (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fd77c411090>: Failed to establish a new connection: [Errno 111] Connection refused'))")
Apr 10 15:52:41 PSQL_1 patroni[283517]: 2026-04-10 15:52:41,073 INFO: Reconnection allowed, looking for another server.
Apr 10 15:52:41 PSQL_1 patroni[283517]: 2026-04-10 15:52:41,073 INFO: Retrying on https://PSQL_2:2379
Apr 10 15:52:41 PSQL_1 patroni[283517]: 2026-04-10 15:52:41,074 ERROR: Request to server https://PSQL_2:2379 failed: MaxRetryError("HTTPSConnectionPool(host='psql_2', port=2379): Max retries exceeded with url: /v3/lease/keepalive (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fd77c411090>: Failed to establish a new connection: [Errno 111] Connection refused'))")
Apr 10 15:52:41 PSQL_1 patroni[283517]: 2026-04-10 15:52:41,074 INFO: Reconnection allowed, looking for another server.
|
В случая по-горе услугата е със състояние active (running), без в действителност да работи: дневниците показват различни грешки при свързване с etcd, от който patroni се нуждае.
В този пример patroni не е непременно виновникът: тъй като зависи от etcd, първо отстранете проблемите с etcd, след което проверете отново състоянието на patroni.
Процедури за отстраняване на неизправности в услугите
По-долу е дадена по една процедура за отстраняване на неизправности за всяка услуга. Ако и etcd, и patroni не работят правилно, започнете с etcd.