PowerFlex 4.X: Jak wykonać bezpieczny ponowny rozruch na maszynach wirtualnych zarządzania PFMP MVM

Ponowne uruchomienie maszyn wirtualnych MVM może rozwiązać niektóre problemy z zasobnikami, niepowodzenia wdrożenia i inne błędy

Polecenia w tej procedurze są uruchamiane z głównej powłoki bash. Aby wykonać poniższe czynności, zaloguj się do MVM za pomocą polecenia: delladmin Następnie uruchom sudo -s , aby przełączyć się na nową powłokę główną.

Przykład:

delladmin@pfmp-mvm03:~> whoami
delladmin
delladmin@pfmp-mvm03:~> sudo -s
pfmp-mvm03:/home/delladmin # whoami
root

1. Wyświetl listę wszystkich instancji bazy danych Postgres i zidentyfikuj nazwę zasobnika z rolą lidera, węzeł wiodący powinien być ostatnim węzłem, który ma zostać opróżniony i ponownie uruchomiony:  

1. 1. PFMP 4.6 

kubectl exec -n powerflex -c database $(kubectl get pods -n powerflex -l='postgres-operator.crunchydata.com/role=master, postgres-operator.crunchydata.com/instance-set' | grep Running | cut -d' ' -f1) -- sh -c 'patronictl list'

Uruchom następujące polecenie, aby określić, który MVM uruchamia konsolę lidera Postgres . Jest to ostatni węzeł, który powinien zostać opróżniony i ponownie uruchomiony:

for x in `kubectl get pods -n powerflex | grep "postgres-ha-cmo" |awk '{print $1}'` ; do echo $x; kubectl get pods -n powerflex $x -o json | grep '"nodeName"' | cut -d ':' -f2 ; echo " "; done

1. 2. PFMP 4.8 

kubectl exec -it -n powerflex $(kubectl get pods -n powerflex | grep postgres-monitor | awk '{print $1'}) -- kubectl cnpg status postgres-ha-cnpg

Przykładowe dane wyjściowe 

delladmin@node2:~> kubectl exec -it -n powerflex $(kubectl get pods -n powerflex | grep postgres-monitor | awk '{print $1'}) -- kubectl cnpg status postgres-ha-cnpg
Cluster Summary
Name                 powerflex/postgres-ha-cnpg
System ID:           7570829541331841052
PostgreSQL Image:    dockerrepo:30500/cnpg/cnpg-postgres:14.18-22-53.6b63004-22-9.0
Primary instance:    postgres-ha-cnpg-1
Primary start time:  2025-11-09 22:33:09 +0000 UTC (uptime 3803h6m21s)
Status:              Cluster in healthy state
Instances:           3
Ready instances:     3
Size:                11G
Current Write LSN:   B/6211B568 (Timeline: 3 - WAL File: 000000030000000B00000062)

Continuous Backup status
Not configured

Streaming Replication status
Replication Slots Enabled
Name                Sent LSN    Write LSN   Flush LSN   Replay LSN  Write Lag        Flush Lag        Replay Lag       State      Sync State  Sync Priority  Replication Slot
----                --------    ---------   ---------   ----------  ---------        ---------        ----------       -----      ----------  -------------  ----------------
postgres-ha-cnpg-2  B/6211B568  B/6211B568  B/6211B568  B/6211B568  00:00:00.000365  00:00:00.001507  00:00:00.001618  streaming  async       0              active
postgres-ha-cnpg-3  B/6211B568  B/6211B568  B/6211B568  B/6211B568  00:00:00.000321  00:00:00.001511  00:00:00.001575  streaming  async       0              active

Instances status
Name                Current LSN  Replication role  Status  QoS        Manager Version  Node
----                -----------  ----------------  ------  ---        ---------------  ----
postgres-ha-cnpg-1  B/6211B568   Primary           OK      Burstable  1.26.1           pfmp-mvm01
postgres-ha-cnpg-2  B/6211B568   Standby (async)   OK      Burstable  1.26.1           pfmp-mvm02
postgres-ha-cnpg-3  B/6211B568   Standby (async)   OK      Burstable  1.26.1           pfmp-mvm03

2. Otwórz terminal do MVM3 (jednego z węzłów niebędących węzłami wiodącymi). Uruchom następujące polecenie:

kubectl get nodes

3. Etykieta MVM3 do konserwacji:

kubectl label node pfmp-mvm03 cmo.maintenance.mode=true

4. Opróżnij węzeł MVM03, w którym uruchomione zasobniki są bezpiecznie eksmitowane z węzła. Konsole są planowane i uruchamiane w innym węźle. Po zakończeniu procesu opróżniania węzeł zostanie uruchomiony ponownie. Poczekaj, aż węzeł zostanie uruchomiony ponownie.

5. Uruchom następujące polecenie, aby opróżnić węzeł:

kubectl drain pfmp-mvm03 --ignore-daemonsets --delete-emptydir-data

6. Po rozładowaniu węzła uruchom go ponownie:

sudo reboot

7. Połącz się z MVM02 i uruchom następujące polecenie, aby monitorować ponownie uruchomiony węzeł, aby osiągnąć STAN Ready:

watch kubectl get nodes

8. Gdy MVM03 zgłosi stan gotowości, połącz się z MVM03 przez SSH i wykonaj następujące polecenie, aby odblokować i usunąć etykietę konserwacji .

kubectl uncordon pfmp-mvm03 ; kubectl label node pfmp-mvm03 cmo.maintenance.mode-

9. Poczekaj od 5 do 20 minut, a następnie uruchom polecenie w kroku 1, aby wyświetlić kondycję klastra bazy danych. Możesz powtórzyć kroki dla następnego MVM, gdy dane wyjściowe będą zgodne z poniższym przykładem bazy danych w dobrej kondycji. 
10. Powtórz kroki 3–8 dla MVM02, a następnie MVM01. 

Po zakończeniu procedury na wszystkich trzech MVM uruchom polecenie w kroku 1, aby sprawdzić stan bazy danych postgres . Jedna kapsuła powinna być liderem i być w stanie uruchomienia. Opóźnienie powinno wynosić 0 MB, a oba elementy w trybie gotowości synchronizacji powinny być w stanie przesyłania strumieniowego.

Przykład prawidłowej bazy danych PFMP 4.6:

+ Cluster: postgres-ha-ha +------------------------------------------+--------------+-----------+----+-----------+
| Member                  | Host                                     | Role         | State     | TL | Lag in MB |
+-------------------------+------------------------------------------+--------------+-----------+----+-----------+
| postgres-ha-cmo1-8t2v-0 | postgres-ha-cmo1-8t2v-0.postgres-ha-pods | Leader       | running   | 10 |           |
| postgres-ha-cmo1-h4hx-0 | postgres-ha-cmo1-h4hx-0.postgres-ha-pods | Sync Standby | streaming | 10 |         0 |
| postgres-ha-cmo1-pb88-0 | postgres-ha-cmo1-pb88-0.postgres-ha-pods | Sync Standby | streaming | 10 |         0 |
+-------------------------+------------------------------------------+--------------+-----------+----+-----------+