PostgreSQL Replication

วัตถุประสงค์

บทความนี้อธิบาย PostgreSQL Replication บน Ruk-Com Cloud PaaS โดยจัดลำดับขั้นตอนและจุดตรวจสอบสำหรับการนำไปใช้งานจริง

ก่อนเริ่มดำเนินการ

• เข้าสู่ระบบด้วยบัญชีที่มีสิทธิ์จัดการ Environment ที่เกี่ยวข้อง
• ตรวจสอบชื่อ Environment, Region และ Resource เป้าหมายก่อนบันทึกการเปลี่ยนแปลง
• สำรองข้อมูลหรือกำหนดแผนย้อนกลับก่อนแก้ไขระบบ Production

การจำลองแบบเป็นเทคโนโลยีพื้นฐานสำหรับ ServerDatabase เนื่องจากการหยุดทำงาน หรือข้อมูลสูญหายอาจส่งผลให้ลดความสามารถในการเข้าถึง ลดประสิทธิภาพการทำงาน และความเชื่อมั่นของผลิตภัณฑ์

การใช้การจำลองข้อมูลจาก Server หลัก (master) ไปยัง standby Server (slaves) อย่างน้อยหนึ่งตัวจะลดความเป็นไปได้ที่ข้อมูลจะสูญหายได้ ด้วย PostgreSQL คุณสามารถสร้าง ClusterDatabase ของ Master-Slave topology ด้วย standby Server ตั้งแต่หนึ่งตัวขึ้นไป

การใช้ WAL (Write-Ahead Logging) เป็นวิธีการจำลองแบบที่เร็วที่สุดพร้อมประสิทธิภาพที่ยอดเยี่ยมซึ่งเรียกว่า asynchronous replication ในกรณีนี้ ServerDatabase ตัวหลัก (Master) จะทำงานในโหมดการเก็บข้อมูลถาวร เพียงแค่เขียนไฟล์ WAL ไปยังหน่วยจัดเก็บข้อมูล (Storage) และกระจายข้อมูลไปยัง ServerDatabase Standby (slave) ที่ทำงานในโหมด recovery ไฟล์เหล่านี้จะถูกโอนไปยัง Database Standby ทันทีหลังจากการเขียนเสร็จสิ้น

ดังนั้นเรามาดูว่า Parameter การกำหนดค่าหลักถูกตั้งค่าเพื่อกำหนดค่า ClusterDatabase PostgreSQL ของ Master-Slave topology ที่มีความพร้อมใช้งานสูงโดยการตั้งค่าการจำลองแบบ hot_ standby (หรือสตรีมมิ่ง) ให้กับ slaves อย่างน้อยหนึ่งรายการที่สามารถคิวรี่เป็น Database แบบอ่านได้อย่างเดียว

เนื่องจาก PostgreSQL เปลี่ยนการกำหนดค่าในทุกรุ่นที่มาใหม่บทความนี้จะใช้ได้กับเวอร์ชัน 13.2 ซึ่งเป็นเวอร์ชันล่าสุดในขณะนี้

สร้าง Environment

ในหน้า Dashbard ของ Ruk-Com Cloud จะมี PostgresSQL ที่มาพร้อมกับฟีเจอร์ Auto-Clustering สามารถเรียกได้จากตัวช่วยสร้าง Environment Topology wizard (ปุ่ม NEW ENVIRONMENT) เมื่อเปิดขึ้นมาแล้วให้เลือกซอร์ฟแวร์ Database เป็น PostgresSQL 12.3 และเปิดสวิตช์การจัดกลุ่มอัตโนมัติ

หากต้องการข้อมูลเพิ่มเติมสามารถวางเมาส์เหนือเครื่องหมายคำแนะนำเครื่องมือ จะมีคำแนะนำเกี่ยวกับ Topology ขึ้นมา

การตั้งค่า Master PostgreSQL

มาดู Parameter การกำหนดค่า master node ที่ใช้ในการทำ auto-clustering

1. ค้นหา Environment ของ Database ตัว master ในลิสรายการ Environment คลิกปุ่ม Config ของ Node PostgreSQL ตัว Master

2. เปิด Directory conf และไปที่ไฟล์ postgresql.conf

การตั้งค่าต่อไปนี้จะเกี่ยวข้องกับ WAL สามารถเปลี่ยนแปลงได้ตามความต้องการ:

wal_level = hot_standby
max_wal_senders = 10
archive_mode = on
archive_command = 'cd .'

โดยที่:

• Parameterwal_levelกำหนดปริมาณข้อมูลที่เขียนไปยัง WAL มีสามค่าที่มีความเป็นไปได้:
  -น้อยที่สุด– เหลือเพียงข้อมูลที่จำเป็นในการกู้คืนจากความล้มเหลวหรือการปิดระบบฉุกเฉิน
  -แบบจำลอง– ค่า default ซึ่งเขียนข้อมูลเพียงพอที่จะรองรับการเก็บถาวรและการจำลองแบบ WAL รวมถึงการรันคิวรีแบบอ่านอย่างเดียวบน standby Server ในรุ่นก่อนหน้านี้ถึงรุ่น 9.6 ค่าที่เก็บถาวรและค่า hot_standby จะได้รับอนุญาตสำหรับ Parameter นี้ ในรุ่นหลังจากนี้จะเป็นที่ยอมรับในการใช้งานได้ แต่เป็นการแมปกับแบบจำลอง
  -ตรรกะ– ค่าจะเพิ่มข้อมูลที่จำเป็นเพื่อสนับสนุนการ decoding ลอจิกไปยังระดับการบันทึกแบบจำลอง
• max_wal_sendersกำหนดจำนวนสูงสุดของกระบวนการถ่ายโอน WAL ที่รันพร้อมกัน
• archive_modeอนุญาตให้เก็บ WAL พร้อมกับ Parameterwal_level(ค่าทั้งหมดเปิดใช้งานการเก็บถาวรยกเว้นค่าที่ต่ำสุด)- archive_command คำสั่ง local shell ที่จะดำเนินการเพื่อเก็บเซ็กเมนต์ WAL ที่เสร็จสมบูรณ์อย่างถาวร โดยค่าเริ่มต้นจะไม่มีการทำอะไรโดยการเรียกใช้งาน ‘cd’ นั่นหมายความว่าการเก็บถาวรถูกปิดใช้งาน คุณอาจลองเปลี่ยนสิ่งต่อไปนี้เพื่อคัดลอก archive ไฟล์ของ WAL ไปยัง Directory ปลายทางที่คุณต้องการ (เช่น /tmp/mydata):

archive_command = 'test ! -f /var/lib/pgsql/data/pg_wal/%f && cp %p /tmp/mydata/%f'

หลังจากตั้งค่าเสร็จแล้วกดปุ่มบันทึกด้านบน

1. เปิดไฟล์ กำหนดค่าpg_hba.confอนุญาตให้เชื่อมต่อ Database Standby (slave) โดยระบุ Parameter ต่อไปนี้:

host replication all {standby_IP_address}/32 trust

เสร็จสิ้นการกำหนดค่าสำหรับ Node master มาดำเนินการต่อในการกำหนดค่าสำหรับ Node Standby (slave)

กำหนดค่า Node Standby (slave)

มาตรวจสอบไฟล์การกำหนดค่าที่ Node Slave มีเพียงสามตัวเลือกที่แยกความแตกต่างของ slave ออกจาก master:

1. เปิดไฟล์ postgresql.conf ค้นหาส่วน Standby Servers ดังที่เห็น Server นี้ จะเป็นโหมด Standby อยู่ เพราะว่า Parameter hot_standby นั้นมีสถานะเป็น on ไม่เหมือนกับ master node ที่ Parameter นี้ถูกคอมเมนต์ไว้

2. เลื่อนลงไปที่ท้ายไฟล์ กำหนดค่า มี Parameter primary_conninfo ที่ระบุการเชื่อมต่อซึ่ง standby Server จะใช้เพื่อเชื่อมต่อกับ Server ที่เป็นผู้ส่ง สตริงการเชื่อมต่อต้องระบุชื่อ Host (หรือ address) ของ Server ที่ส่งรวมทั้งหมายเลข Port นอกจากนี้ยังมีชื่อผู้ใช้ที่สอดคล้องกันพร้อมสิทธิ์ที่เหมาะสมบน Server ที่ส่ง ต้องระบุรหัสผ่านใน primary_conninfo หรือในไฟล์ ~/.pgpass แยกต่างหากบน Server สำรองหากผู้ส่งต้องการการยืนยันตัวตนด้วยรหัสผ่าน

3. ตัวเลือกสุดท้ายที่ทำให้ ServerDatabase เป็น slave คือความพร้อมใช้งานของไฟล์สแตนด์บายสัญญาณซึ่งบ่งชี้ว่า Server ควรเริ่มการทำงานแบบ hot standby ไฟล์ต้องอยู่ใน Directory PostgreSQL data และอาจว่างเปล่าหรือมีข้อมูลใด ๆ อยู่ เมื่อ slave ได้รับการเลื่อนขึ้นเป็น master ไฟล์นี้จะถูกลบไป

หมายเหตุ:

โปรดทราบว่าตัวเลือกส่วนใหญ่ที่มีการเปลี่ยนแปลงจำเป็นต้อง RestartServer สามารถทำได้สองวิธี:

1. จาก Dashboard คุณสามารถ RestartNode ใด Node หนึ่งหรือทั้งสอง Node ก็ได้

2. ทำผ่าน command line interface ผ่านไปยัง Web SSH client โดยคลิกที่ปุ่ม Web SSH ที่ Node ที่ต้องการ เช่น slave

และป้อนคำสั่งเพื่อ RestartServerDatabase:

sudo service postgresql restart

ตรวจสอบการ Replication

1. เปิดพาเนลphpPgAdmin.phpสำหรับ Databaseอาจารย์โดยคลิกปุ่ม Open in Browser ที่อยู่ข้าง ๆ

2. เข้าสู่ระบบด้วยข้อมูลรับรอง Database ที่ได้รับทางอีเมลก่อนหน้านี้และสร้าง Database ใหม่

3. จากนั้นคุณควรเปิดพาเนลแอดมินของ ServerDatabaseNode standby (ในลักษณะเดียวกับ master) และตรวจสอบว่า Database ใหม่ถูกสร้างขึ้นสำเร็จหรือไม่

สถานการณ์การ Failover

PostgreSQL ไม่มี native automatic failover scenario สำหรับ ClusterDatabase ในทางกลับกันเนื่องจากมีโซลูชัน third-party มากมายที่คุณสามารถใช้เพื่อ Deploy เพื่อให้แน่ใจว่าระบบของคุณมีความพร้อมใช้งานสูง ในขณะเดียวกันคุณอาจสร้างโซลูชันของคุณเองเพื่อหยุดความล้มเหลวของ ClusterDatabase สถานการณ์หลายอย่างของความล้มเหลวของ Cluster เป็นไปได้ในชีวิตจริง ในตัวอย่างนี้เราจะพิจารณาขั้นตอนการทำงานที่พบบ่อยที่สุดเพียงขั้นตอนเดียวเท่านั้นที่สามารถช่วยคุณในการทำ automate failover scenario

Topology เริ่มต้นประกอบด้วยสอง Node:

เมื่อ master node ล้มเหลว slave node จะต้องเลื่อนระดับเป็น Node master ใหม่ สามารถทำได้ด้วยยูทิลิตี้ pg_ctl ซึ่งใช้ในการเตรียมใช้งานเริ่มต้นหยุดหรือควบคุม Server PostgreSQL ในการเข้าสู่ระบบเข้าสู่ Server standby ผ่าน Web SSH และใช้คำสั่งดังนี้:

/usr/pgsql-13/bin/pg_ctl promote -D /var/lib/pgsql/data

โดยที่ /var/lib/pgsql/data คือ Directory ข้อมูลของ Database

เมื่อเลื่อนขั้น Database slave เป็น master แล้ว คุณควรเปลี่ยนสตริงการเชื่อมต่อ Application เปลี่ยน entry point ของ ClusterDatabase เป็นชื่อ Host หรือ IP address ใหม่

กระบวนการ Failover สามารถอาศัยการใช้งานpg_isreadyutility ที่ตรวจสอบการเชื่อมต่อกับ Database PostgreSQL ได้

คุณสามารถสร้าง Script ง่าย ๆ ที่ตรวจสอบความพร้อมใช้งานของ ServerDatabase master และส่งเสริมการ standby ในกรณีที่ master เกิดความล้มเหลว รัน Script ผ่าน link # crontab ที่ slave node ด้วยช่วงเวลาที่เหมาะสม Script อาจมีลักษณะดังนี้ เรียกว่า failover.sh:

#!/bin/bash
master="10.100.2.84"
slave="10.100.2.85"
status=$(/usr/pgsql-13/bin/pg_isready -d postgres -h $master)
response="$master:5432 - no response"
if [ "$status" == "$response" ]
then
/usr/pgsql-13/bin/pg_ctl promote -D /var/lib/pgsql/data
echo "Slave promoted to new Master. Change your app connection string to new Master address $slave"
else
echo "Master is alive. Nothing to do."
fi

เมื่อ Script ถูก trigger การเลื่อนขั้น slave เป็น master ผลลัพธ์ของ Script ควรมีลักษณะดังนี้:

ตอนนี้ Database ของคุณกลับมาใช้งานได้แล้วและพร้อมที่จะจัดการ read/write ตาม master address ใหม่

การฟื้นฟู Cluster

ด้วย master address ใหม่คุณสามารถหลีกเลี่ยงการปรับแต่งสตริงการเชื่อมต่อ Application ของคุณโดยเปลี่ยน ip address ของ Database master ได้อย่างง่ายดาย ในการดำเนินการนี้คุณต้องวาง load balancer ที่ด้านหน้าของ Cluster ที่จะตรวจสอบสถานะของส่วนประกอบและกำหนดเส้นทาง Traffic ไปยัง master ปัจจุบัน แต่สิ่งนี้อยู่นอกขอบเขตของเอกสารนี้ เราจะสาธิตวิธีการคืนค่าดั้งเดิมของ cluster topology ดังนั้นจึงไม่จำเป็นต้องมีการเปลี่ยนแปลงใด ๆ ที่ส่วน frontend

อีกเหตุผลหนึ่งที่ควรกู้คืน topology เกี่ยวข้องกับการรับรองความสามารถในการปรับสเกลของ Cluster Topology แบบดั้งเดิมเท่านั้นที่สามารถปรับสเกลเข้า / ออกในแนวนอนได้

มาดูวิธีการกู้คืน ClusterDatabase PostgreSQL หลังจากที่ master เก่าถูกละทิ้งออกจาก Cluster และ slave เดิมได้รับการเลื่อนขั้นเป็น master

ดังนั้นงานคือ: master ที่ถูกละทิ้งควรกลายเป็น master ที่แท้จริงและ master ในปัจจุบัน (ที่เลื่อนขั้นมาจาก slave) ควรกลายเป็น slave ที่แท้จริงแทน

ข้อมูลเบื้องต้นคือ:
- ข้อมูลเริ่มต้นคือ ClusterDatabase ประกอบด้วย Node master สอง Node (IP: 10.2.100.84) และ slave (IP: 10.2.100.85)
- Master node หยุดทำงานและ Database หลักหยุดทำงาน
- Database Standby ได้รับการเลื่อนระดับเป็นตัว master
- ตอนนี้ slave ยังคง reads/writes
- master node เดิมได้รับการแก้ไขแล้ว และพร้อมที่จะแนะนำให้รู้จักกับการจำลองแบบเป็นหลัก

ทำตามขั้นตอนต่อไปนี้เพื่อรับ Cluster ของ Topology เริ่มต้น:

1. เพื่อจำลองการพังของ Database จะลบข้อมูลออก ให้เข้าไป web SSH ที่ master node และ ป้อนคำสั่ง:

rm -rf /var/lib/pgsql/data/*

2. เพิ่ม master IP address เดิม 10.100.2.84 ไปยังpg_hba.confที่ master node ปัจจุบัน (ตอนนี้เป็น Node secondary):

host replication replication 10.100.2.84/32 trust

จะทำให้ Node master เดิม สามารถเข้าถึง master ปัจจุบันได้ จากนั้น RestartDatabase หลักในปัจจุบัน (ตอนนี้เป็น Node secondary) เพื่อเปลี่ยนแปลงค่า

sudo service postgresql restart

3. ไปยัง master node เดิม ผ่านทาง Web SSH และ ป้อนคำสั่ง:

pg_basebackup -U replication -h 10.100.2.85 -D /var/lib/pgsql/data -Fp -Xs -P -R

โดยที่:

• ลิงค์ #pg_basebackup- ใช้เพื่อสำรองข้อมูลพื้นฐานของ ClusterDatabase PostgreSQL ที่รันอยู่
• 10.100.2.85 - IP address ของ master node ปัจจุบัน
• /var/lib/pgsql/data - Directory ข้อมูล PostgreSQL

4. ตรวจสอบให้แน่ใจว่า ip address ใน HostParameter ที่อธิบายไว้ในข้อ #2 ของการ link #การกำหนดค่าสแตนด์บายมี ip address ที่เหมาะสมกับ master เดิม

5. สร้างไฟล์ standby.signal ที่ master ปัจจุบัน:

touch /var/lib/pgsql/data/standby.signal

และ RestartNode เพื่อรับ Database slave ใหม่:

sudo service postgresql restart

ลบไฟล์ standby.signal ที่ master เดิม:

rm /var/lib/pgsql/data/standby.signal

และ RestartNode เพื่อรับ Database master ใหม่

sudo service postgresql restart

6. สุดท้ายเพื่อให้ได้สถานะการกู้คืนที่สอดคล้องกันสำหรับทั้ง Database หลักและ Database standby จำเป็นต้องมีการ Restart ครั้งสุดท้ายซึ่งสามารถทำได้ผ่าน Dashboard ดังนี้:

เมื่อกระบวนการ Restart เสร็จสิ้น Cluster จะกลับมาที่ Topology ดั้งเดิมและอาจถูกปรับสเกลในแนวนอน