พาวเวอร์เฟล็กซ์ 4.X: วิธีทําการรีบูตอย่างสง่างามบน VM การจัดการ PFMP MVM

การรีบูต MVM VM สามารถแก้ปัญหา Pod ความล้มเหลวในการปรับใช้ และข้อผิดพลาดอื่นๆ ได้

คําสั่งในกระบวนงานนี้ถูกรันจากเชลล์ root bash หากต้องการสะท้อนขั้นตอนด้านล่าง ให้เข้าสู่ระบบ MVM โดยใช้ delladmin จากนั้นเรียกใช้ sudo -s เพื่อเปลี่ยนไปใช้เปลือก

รูทใหม่ตัวอย่าง:

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

1. แสดงรายการอินสแตนซ์ฐานข้อมูล Postgres ทั้งหมดและระบุชื่อ Pod ด้วยบทบาท Leader โหนดผู้นําควรเป็นโหนดสุดท้ายที่จะระบายและรีบูต:  

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'

เรียกใช้คําสั่งต่อไปนี้เพื่อ ระบุว่า MVM ใดกําลังเรียกใช้ Postgres Leader Pod นี่คือโหนดสุดท้ายที่จะถูกระบายออกและรีบูต:

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

ตัวอย่างผลลัพธ์ 

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. เปิดเทอร์มินัลไปที่ MVM3 (หนึ่งในโหนดที่ไม่ใช่ผู้นํา) เรียกใช้คําสั่งต่อไปนี้:

kubectl get nodes

3. ฉลาก MVM3 สําหรับการบํารุงรักษา:

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

4. โหนดระบายน้ํา MVM03 ที่ Pods ที่ทํางานอยู่ จะถูกขับออกจากโหนดอย่างสง่างาม พ็อดกําหนดเวลาและทํางานบนโหนดอื่น เมื่อกระบวนการระบายน้ําเสร็จสิ้นโหนดจะรีบูต รอให้โหนดกลับมา

5. เรียกใช้คําสั่งต่อไปนี้เพื่อ ระบายโหนด:

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

6. เมื่อโหนดหมดแล้ว ให้รีบูตโหนด:

sudo reboot

7. SSH ไปยัง MVM02 และเรียกใช้คําสั่งต่อไปนี้เพื่อตรวจสอบโหนดที่คุณรีบูตเพื่อไปถึงสถานะเป็น Ready:

watch kubectl get nodes

8. เมื่อ MVM03 รายงานสถานะพร้อมแล้ว SSH ไปยัง MVM03 และดําเนินการคําสั่งต่อไปนี้เพื่อยกเลิกและลบฉลากการบํารุงรักษา

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

9. รอ 5 ถึง 20 นาที จากนั้นเรียกใช้คําสั่งในขั้นตอนที่ 1 เพื่อดูสถานภาพคลัสเตอร์ฐานข้อมูล คุณสามารถทําซ้ําขั้นตอนสําหรับ MVM ถัดไปได้เมื่อผลลัพธ์ตรงกับ ตัวอย่างฐานข้อมูลที่ดีด้านล่าง 
10. ทําซ้ําขั้นตอนที่ 3-8 บน MVM02 จากนั้น MVM01 

เมื่อคุณทําตามขั้นตอนบน MVM ทั้งสามเสร็จสมบูรณ์แล้ว ให้เรียกใช้คําสั่งในขั้นตอนที่ 1 เพื่อตรวจสอบความสมบูรณ์ของฐานข้อมูล postgres One Pod ควรเป็นผู้นําและอยู่ในสถานะของการทํางาน ควรมีความล่าช้า 0MB และสมาชิกสแตนด์บายซิงค์ทั้งสองควรมีสถานะ การ

สตรีมตัวอย่างฐานข้อมูลสุขภาพ 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 |
+-------------------------+------------------------------------------+--------------+-----------+----+-----------+