Przejdź do treści

Rozwiązywanie problemów z etcd

Info

Całą procedurę wykonuj jako root. Aby podnieść swoje uprawnienia do poziomu root, możesz użyć polecenia su -.

etcd to rozproszony magazyn typu klucz-wartość, używany jako punkt koordynacji między węzłami clustera PostgreSQL. W niezawodny sposób centralizuje i udostępnia stan clustera, w tym tożsamość lidera, stan członków oraz mechanizmy blokad.

patroni opiera się na etcd, aby sterować wyborem węzła lidera i automatycznie wyzwalać przełączenia awaryjne w razie incydentu. Zainstalowany na wszystkich węzłach, etcd gwarantuje ogólną spójność clustera, nie uczestnicząc w przechowywaniu ani przetwarzaniu danych PostgreSQL.

patroni zależy więc od etcd i nie może działać prawidłowo, jeśli etcd nie działa.

Info

Konfiguracja etcd jest przechowywana w pliku /etc/default/etcd na każdym węźle.

Logi

Cała procedura opiera się na logach usługi etcd, które uzyskasz za pomocą poniższego polecenia:

1
journalctl -u etcd

Wskazówka

Aby śledzić logi na bieżąco, dodaj do polecenia opcję -f: 

1
journalctl -fu etcd

Info

Logi etcd są również dostępne w /var/log/syslog.

Objaśnienia logów błędów

health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: i/o timeout

Jeśli przepływ TCP/2380 nie jest otwarty między dwoma węzłami, upływa limit czasu połączenia, a etcd zapisuje następujące logi:

1
2
3
4
5
6
Apr 15 11:48:09 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: i/o timeout
Apr 15 11:48:09 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: i/o timeout
Apr 15 11:48:14 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: i/o timeout
Apr 15 11:48:14 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: i/o timeout
Apr 15 11:48:19 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: i/o timeout
Apr 15 11:48:19 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: i/o timeout

Gdzie <PEER_PSQL_NODE_ID> to identyfikator przypisany przez etcd do węzła docelowego, a <PEER_IP_PSQL_NODE> to adres IP węzła docelowego.

Przykład

W naszym przykładzie cluster PostgreSQL jest skonfigurowany następująco:

Węzeł IP węzła ID etcd
PSQL_1 192.168.1.1 53d2c129945ccb8b
PSQL_2 192.168.1.2 7176dd381f583d83
PSQL_3 192.168.1.3 e3d5ef565a5bb46c

Uruchomienie polecenia journalctl -fu etcd na serwerze PSQL_1 daje następujące logi:

1
2
3
4
5
Apr 15 11:50:39 PSQL_1 etcd[1342933]: health check for peer 7176dd381f583d83 could not connect: dial tcp 192.168.1.2:2380: i/o timeout
Apr 15 11:50:44 PSQL_1 etcd[1342933]: health check for peer 7176dd381f583d83 could not connect: dial tcp 192.168.1.2:2380: i/o timeout
Apr 15 11:50:44 PSQL_1 etcd[1342933]: health check for peer 7176dd381f583d83 could not connect: dial tcp 192.168.1.2:2380: i/o timeout
Apr 15 11:50:49 PSQL_1 etcd[1342933]: health check for peer 7176dd381f583d83 could not connect: dial tcp 192.168.1.2:2380: i/o timeout
Apr 15 11:50:49 PSQL_1 etcd[1342933]: health check for peer 7176dd381f583d83 could not connect: dial tcp 192.168.1.2:2380: i/o timeout

Te logi wskazują, że połączenie z serwera PSQL_1 z serwerem o adresie IP 192.168.1.2 (PSQL_2) i identyfikatorze etcd 7176dd381f583d83, na porcie TCP/2380, nie powiodło się: upłynął limit czasu. Można z tego wywnioskować, że przepływ z serwera PSQL_1 do serwera PSQL_2 jest blokowany (DROP) przez zaporę.

Ten przepływ może być blokowany (DROP) przez lokalną zaporę appliance PostgreSQL: sprawdź konfigurację zapory appliance na danych węzłach. Jeśli ta konfiguracja jest poprawna, przepływ TCP/2380 między dwoma węzłami blokuje (DROP) zapora infrastruktury.

health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: connect: connection refused

Gdy połączenie między dwoma węzłami zostaje odrzucone, etcd zgłasza to za pomocą następujących logów:

1
2
3
4
5
6
Apr 15 14:04:30 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: connect: connection refused
Apr 15 14:04:30 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: connect: connection refused
Apr 15 14:04:35 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: connect: connection refused
Apr 15 14:04:35 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: connect: connection refused
Apr 15 14:04:40 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: connect: connection refused
Apr 15 14:04:40 PSQL_1 etcd[1342933]: health check for peer <PEER_PSQL_NODE_ID> could not connect: dial tcp <PEER_IP_PSQL_NODE>:2380: connect: connection refused

Gdzie <PEER_PSQL_NODE_ID> to identyfikator przypisany przez etcd do węzła docelowego, a <PEER_IP_PSQL_NODE> to adres IP węzła docelowego.

Odrzucenie może mieć kilka przyczyn:

  • Usługa etcd działa nieprawidłowo lub jest zatrzymana na węźle docelowym. W takim przypadku sprawdź stan (systemctl status etcd) i logi usługi etcd na tym węźle.
  • Zapora odrzuca (REJECT) przepływ TCP/2380 między dwoma węzłami. Może to być lokalna zapora appliance lub zapora infrastruktury.
Przykład

W naszym przykładzie cluster PostgreSQL jest skonfigurowany następująco:

Węzeł IP węzła ID etcd
PSQL_1 192.168.1.1 53d2c129945ccb8b
PSQL_2 192.168.1.2 7176dd381f583d83
PSQL_3 192.168.1.3 e3d5ef565a5bb46c

Uruchomienie polecenia journalctl -fu etcd na serwerze PSQL_1 daje następujące logi:

1
2
3
4
5
Apr 15 14:04:15 PSQL_1 etcd[1342933]: health check for peer e3d5ef565a5bb46c could not connect: dial tcp 192.168.1.3:2380: connect: connection refused
Apr 15 14:04:15 PSQL_1 etcd[1342933]: health check for peer e3d5ef565a5bb46c could not connect: dial tcp 192.168.1.3:2380: connect: connection refused
Apr 15 14:04:20 PSQL_1 etcd[1342933]: health check for peer e3d5ef565a5bb46c could not connect: dial tcp 192.168.1.3:2380: connect: connection refused
Apr 15 14:04:20 PSQL_1 etcd[1342933]: health check for peer e3d5ef565a5bb46c could not connect: dial tcp 192.168.1.3:2380: connect: connection refused
Apr 15 14:04:25 PSQL_1 etcd[1342933]: health check for peer e3d5ef565a5bb46c could not connect: dial tcp 192.168.1.3:2380: connect: connection refused

Te logi wskazują, że połączenie z serwera PSQL_1 z serwerem o adresie IP 192.168.1.3 (PSQL_3) i identyfikatorze etcd e3d5ef565a5bb46c, na porcie TCP/2380, zostało odrzucone.

Na serwerze PSQL_3 polecenie systemctl status etcd pokazuje, że etcd jest zatrzymany:

 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: inactive (dead) since Wed 2026-04-15 16:09:34 CEST; 38s ago
Duration: 1min 36.087s
    Docs: https://etcd.io/docs
            man:etcd
    Process: 1400558 ExecStart=/usr/bin/etcd $DAEMON_ARGS (code=killed, signal=TERM)
Main PID: 1400558 (code=killed, signal=TERM)
        CPU: 49.071s

Apr 15 12:26:32 PSQL_3 etcd[1197556]: finished scheduled compaction at 1665243 (took 583.297µs)
Apr 15 13:26:32 PSQL_3 etcd[1197556]: store.index: compact 1665949
Apr 15 13:26:32 PSQL_3 etcd[1197556]: finished scheduled compaction at 1665949 (took 574.496µs)
Apr 15 14:26:32 PSQL_3 etcd[1197556]: store.index: compact 1666658
Apr 15 14:26:32 PSQL_3 etcd[1197556]: finished scheduled compaction at 1666658 (took 567.196µs)
Apr 15 15:26:32 PSQL_3 etcd[1197556]: store.index: compact 1667368
Apr 15 15:26:32 PSQL_3 etcd[1197556]: finished scheduled compaction at 1667368 (took 568.096µs)
Apr 15 16:09:34 PSQL_3 systemd[1]: etcd.service: Deactivated successfully.
Apr 15 16:09:34 PSQL_3 systemd[1]: Stopped etcd.service - etcd - highly-available key value store.
Apr 15 16:09:34 PSQL_3 systemd[1]: etcd.service: Consumed 49.071s CPU time.

Po uruchomieniu etcd problem zostaje rozwiązany.

rejected connection from "<PEER_IP_PSQL_NODE>:35956" (error "remote error: tls: bad certificate", ServerName "PSQL_1")

Jeśli certyfikaty clustera PostgreSQL wygasły albo nie zostały poprawnie zainstalowane lub odnowione na węźle, z którego odczytujesz logi, w logach etcd pojawia się następujący błąd:

1
2
3
4
5
6
Apr 15 16:38:54 PSQL_1 etcd[1407644]: rejected connection from "<PEER_IP_PSQL_NODE>:49274" (error "remote error: tls: bad certificate", ServerName "PSQL_1")
Apr 15 16:38:54 PSQL_1 etcd[1407644]: rejected connection from "<PEER_IP_PSQL_NODE>:49294" (error "remote error: tls: bad certificate", ServerName "PSQL_1")
Apr 15 16:38:54 PSQL_1 etcd[1407644]: rejected connection from "<PEER_IP_PSQL_NODE>:49288" (error "remote error: tls: bad certificate", ServerName "PSQL_1")
Apr 15 16:38:55 PSQL_1 etcd[1407644]: rejected connection from "<PEER_IP_PSQL_NODE>:49316" (error "remote error: tls: bad certificate", ServerName "PSQL_1")
Apr 15 16:38:55 PSQL_1 etcd[1407644]: rejected connection from "<PEER_IP_PSQL_NODE>:49304" (error "remote error: tls: bad certificate", ServerName "PSQL_1")
Apr 15 16:38:55 PSQL_1 etcd[1407644]: rejected connection from "<PEER_IP_PSQL_NODE>:60958" (error "remote error: tls: bad certificate", ServerName "PSQL_1")

Gdzie <PEER_IP_PSQL_NODE> to adres IP jednego z węzłów clustera.

Ten log wskazuje, że gdy węzeł, z którym jesteś połączony, próbował nawiązać połączenie z pozostałymi węzłami clustera (<PEER_IP_PSQL_NODE>), odrzuciły one je, zgłaszając błąd dotyczący certyfikatu bieżącego węzła.

Sprawdź więc ważność certyfikatów clustera na węźle, z którym jesteś połączony.

Ostrzeżenie

Jeśli urząd certyfikacji skonfigurowany na węźle zdalnym (w /etc/etcd/ca.crt) jest nieprawidłowy, błąd pojawia się również na węźle, z którego odczytujesz logi: oznacza wówczas, że węzeł zdalny nie może zweryfikować przedstawionego certyfikatu, ponieważ nie ma właściwego urzędu CA.

Przykład

W naszym przykładzie cluster PostgreSQL jest skonfigurowany następująco:

Węzeł IP węzła ID etcd
PSQL_1 192.168.1.1 53d2c129945ccb8b
PSQL_2 192.168.1.2 7176dd381f583d83
PSQL_3 192.168.1.3 e3d5ef565a5bb46c

Uruchomienie polecenia journalctl -fu etcd na serwerze PSQL_1 daje następujące logi:

1
2
3
4
5
6
Apr 15 16:38:54 PSQL_1 etcd[1407644]: rejected connection from "192.168.1.2:49274" (error "remote error: tls: bad certificate", ServerName "PSQL_1")
Apr 15 16:38:54 PSQL_1 etcd[1407644]: rejected connection from "192.168.1.3:49294" (error "remote error: tls: bad certificate", ServerName "PSQL_1")
Apr 15 16:38:54 PSQL_1 etcd[1407644]: rejected connection from "192.168.1.2:49288" (error "remote error: tls: bad certificate", ServerName "PSQL_1")
Apr 15 16:38:55 PSQL_1 etcd[1407644]: rejected connection from "192.168.1.2:49316" (error "remote error: tls: bad certificate", ServerName "PSQL_1")
Apr 15 16:38:55 PSQL_1 etcd[1407644]: rejected connection from "192.168.1.3:49304" (error "remote error: tls: bad certificate", ServerName "PSQL_1")
Apr 15 16:38:55 PSQL_1 etcd[1407644]: rejected connection from "192.168.1.3:60958" (error "remote error: tls: bad certificate", ServerName "PSQL_1")

Te logi wskazują, że węzły PSQL_2 i PSQL_3 odrzuciły połączenie z węzła PSQL_1, ponieważ certyfikat PSQL_1 nie jest ważny w tym kontekście.

Sprawdzamy więc ważność certyfikatów węzła PSQL_1, postępując zgodnie z procedurą sprawdzania certyfikatów clustera:

1
2
openssl x509 -in /etc/etcd/peer.crt -noout -enddate
openssl x509 -in /etc/etcd/ca.crt -noout -enddate

Wynik pokazuje, że certyfikat węzła wygasł:

1
2
notAfter=Dec 18 14:04:09 2025 GMT
notAfter=Dec 17 14:03:47 2030 GMT

W takim przypadku odnów certyfikaty clustera PostgreSQL.

error listing data dir: /var/lib/etcd/cleanroom

Jeśli etcd nie ma właściwych uprawnień do katalogu /var/lib/etcd/cleanroom, usługa nie uruchamia się i zapisuje następujące logi:

1
2
3
4
5
6
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

Aby rozwiązać ten problem, nadaj katalogowi właściwe uprawnienia za pomocą następującego polecenia:

1
chown -R etcd:etcd /var/lib/etcd/cleanroom