คู่มือ Auto-Clustering สำหรับ Database

การจำลอง Database PostgreSQL

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

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

มาดูกันว่า ClusterDatabase PostgreSQL หลัก-รองสามารถติดตั้งและกำหนดค่าได้อย่างไร

การสร้าง Cluster PostgreSQL หลัก-รอง

Platform นี้มีวิธีอัตโนมัติสองวิธีในการรับ Cluster PostgreSQL:

• โซลูชันตลาดแบบบรรจุหีบห่อล่วงหน้า
• ตัวช่วยสร้าง Topology การจัดกลุ่มอัตโนมัติ

โซลูชันตลาดแบบบรรจุหีบห่อล่วงหน้า

วิธีที่เร็วและตรงไปตรงมาที่สุดในการสร้าง Cluster PostgreSQL คือการใช้โซลูชันที่จัด Package ล่วงหน้าจากตลาด.

1. คลิกที่ตลาดที่ด้านซ้ายบนของ Dashboard และค้นหาPostgreSQL Cluster หลัก-รองบรรจุุภัณฑ์.

วางเมาส์เหนือโซลูชันแล้วคลิกติดตั้งเพื่อดำเนินการต่อ

2. ภายในกล่องโต้ตอบที่เปิดอยู่คุณสามารถเลือกเวอร์ชัน PostgreSQL ที่ต้องการและเปิดใช้งาน Load Balancer Pgpool-II ได้

3. รอสักครู่เพื่อให้ Platform เตรียม Environment ของคุณและตั้งค่าการกำหนดค่าการจำลองที่จำเป็น

เมื่อเสร็จแล้วคุณจะเห็นการแจ้งเตือนที่เหมาะสมพร้อมข้อมูลสำหรับการเข้าถึง Interface การดูแลระบบ PostgreSQL (ส่งทางอีเมลด้วย)

ตัวช่วยสร้าง Topology การจัดกลุ่มอัตโนมัติ

สามารถเปิดใช้งาน ClusterDatabase PostgreSQL ผ่านทางระบบฝังตัวการจัดกลุ่มอัตโนมัติคุณสมบัติที่ Dashboard มีตัวเลือกการกำหนดค่าเพิ่มเติมเมื่อเปรียบเทียบกับตัวเลือกตลาดในขณะที่ยังคงทำให้กระบวนการกำหนดค่าทั้งหมดเป็นแบบอัตโนมัติ

1. เปิด Environment ใหม่ตัวช่วยสร้าง Topology, เลือกPostgreSQLSoftwareDatabaseStack และเพียงแค่เปิดใช้งานเฉพาะการจัดกลุ่มอัตโนมัติสวิตช์. หากจำเป็นคุณสามารถเปิดใช้งานได้พีจีพูล-ทูLoad Balancer สำหรับ Cluster ของคุณ

จากนั้นคุณสามารถใช้พลังการกำหนดค่าของวิซาร์ดได้อย่างเต็มที่เพื่อเปลี่ยนจำนวน Node ต่อ Layer จัดสรร Resource เพิ่มเติมเพิ่ม StackSoftware อื่นๆให้กับ Environment ของคุณฯลฯ

2. เมื่อพร้อมแล้วคลิกสร้างและรอสักครู่เพื่อให้ Platform สร้าง Environment ของคุณ

การจัดการ Cluster PostgreSQL

ด้านล่างนี้เราจะให้ข้อมูลที่เป็นประโยชน์เกี่ยวกับการจัดการ Cluster PostgreSQL:

• จุดเข้า Cluster
• แผงผู้ดูแลระบบ Cluster
• การกำหนดค่า PostgreSQL หลัก
• การกำหนดค่าสแตนด์บาย
• ตรวจสอบการจำลองแบบ
• สถานการณ์การ Failover อัตโนมัติ
• สถานการณ์การ Failover ด้วยตนเอง

จุดเข้า Cluster

หากไม่ได้เพิ่ม Node Pgpool-II ใน TopologyCluster ให้ใช้ Node หลักเพื่อเข้าถึง Cluster หากมีการใช้งาน LayerLoad Balancing ที่ด้านหน้า ClusterDatabase คุณสามารถใช้ Node Pgpool-II ใดก็ได้เป็นจุดเริ่มต้น

แผงผู้ดูแลระบบ Cluster

ใน PaaS ส่วนประกอบ Cluster PostgreSQL สามารถจัดการได้ผ่านทางคลีไอหรือ UI

• การจัดการ Database

Node Database มีแผงการจัดการการจัดการในตัว phpPgAdmin ใช้อันเดียวบน Node หลัก

*การจัดการ Pgpool-II

Node Pgpool-II ยังสามารถจัดการผ่านแผงการดูแลระบบในตัวที่ใช้งานง่ายpgpool ผู้ดูแลระบบ.

แผงผู้ดูแลระบบ Pgpool-II ให้ความสามารถในการกำหนดค่า:

• โหลดบาลานซ์และกระจายในระดับ Database (วิธีประมวลผลและปรับสมดุลคำขอไปยังทุก Database)
• พูลการเชื่อมต่อ
• การบันทึก
• การจำลองแบบ
• การ Debug
• Failover และเฟลแบ็ค

การกำหนดค่า PostgreSQL หลัก

มาดู Parameter การกำหนดค่า Node หลักที่ใช้ในการจัดกลุ่มอัตโนมัติกัน

1. ค้นหา Environment ด้วย Database หลักในรายการ Environment ของคุณคลิกที่การกำหนดค่าปุ่มถัดจาก Node หลัก PostgreSQL

2. เปิดการประชุมDirectory และนำทางไปยังpostgresql.confไฟล์.

บรรทัดต่อไปนี้ที่เกี่ยวข้องกับไฟล์ WAL สามารถเปลี่ยนแปลงได้หากจำเป็น:

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

ที่ไหน:

• ที่wal_levelParameter กำหนดจำนวนข้อมูลที่เขียนลงใน WAL มีค่าที่เป็นไปได้สามค่า:

  • น้อยที่สุด- เหลือเพียงข้อมูลที่จำเป็นในการกู้คืนจากความล้มเหลวหรือการปิดระบบฉุกเฉิน
  • แบบจำลอง- ค่าเริ่มต้นซึ่งเขียนข้อมูลที่เพียงพอเพื่อรองรับการเก็บถาวรและการจำลองแบบ WAL รวมถึงการเรียกใช้คำสั่งแบบอ่านอย่างเดียวบน Server สแตนด์บายในการเผยแพร่ก่อนเวอร์ชัน 9.6 นั้นคลังเก็บเอกสารสำคัญและร้อน_สแตนด์บายอนุญาตให้ใช้ค่าสำหรับ Parameter นี้ในรุ่นต่อๆไปจะยอมรับได้แต่แม็ปกับเรพลิกา
  • ตรรกะ- ค่าจะเพิ่มข้อมูลที่จำเป็นเพื่อรองรับการถอดรหัสแบบลอจิคัลให้กับระดับการบันทึกเรพลิกา

• max_wal_sendersตั้งค่าจำนวนสูงสุดของกระบวนการถ่ายโอน WAL ที่ทำงานพร้อมกัน

• archive_modeอนุญาตให้เก็บถาวร WAL พร้อมกับwal_levelParameter (ค่าทั้งหมดเปิดใช้งานการเก็บถาวรยกเว้นน้อยที่สุดค่า).
• archive_command- คำสั่งเชลล์ในเครื่องที่จะดำเนินการเพื่อเก็บถาวรส่วน WAL ที่เสร็จสมบูรณ์โดยค่าเริ่มต้นจะไม่ทำอะไรเลยโดยดำเนินการ ‘ซีดี.' นั่นหมายถึงการปิดใช้งานการเก็บถาวรจริงๆคุณอาจลองเปลี่ยนดังต่อไปนี้เพื่อคัดลอกไฟล์เก็บถาวร WAL ไปยัง Directory ปลายทางที่คุณต้องการ (เช่น/tmp/mydata):

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

กดบันทึกปุ่มเหนือตัวแก้ไข

3. เปิดpg_hba.confไฟล์การกำหนดค่าการเชื่อมต่อ Database สแตนด์บายได้รับอนุญาตโดยระบุ Parameter ต่อไปนี้:

host replication all {standby_IP_address}/32 trust

นั่นคือทั้งหมดสำหรับประถมศึกษา! ดำเนินการกำหนดค่าของ Server สแตนด์บายต่อไป

การกำหนดค่าสแตนด์บาย

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

1. เปิดpostgresql.confไฟล์ให้ค้นหาไฟล์Server สแตนด์บายส่วน. อย่างที่คุณเห็น Server นี้ทำหน้าที่เป็นสแตนด์บายตั้งแต่ร้อน_สแตนด์บายParameter คือบนไม่เหมือนกับ Node หลักที่ Parameter นี้ถูกใส่เครื่องหมายความคิดเห็น

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

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

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

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

2. ผ่านอินเตอร์เฟสบรรทัดคำสั่งผ่านทางเว็บ SSHลูกค้า. โดยคลิกที่เว็บ SSHปุ่มที่ Node ที่ต้องการเช่นรอง

และออกคำสั่งให้ RestartServerDatabase:

sudo service postgresql restart

ตรวจสอบการจำลองแบบ

1. เปิดphpPgAdmin.phpแผงสำหรับคุณหลักDatabase โดยคลิกเปิดใน Browserปุ่มข้างๆ

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

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

สถานการณ์การ Failover อัตโนมัติ

ที่Failover อัตโนมัติสำหรับ Cluster PostgreSQL ได้รับการ Deploy ด้วยความช่วยเหลือของพีจีพูล-ทูNode และไม่พร้อมใช้งานสำหรับ Topology ที่ไม่มีมัน (การกำหนดค่าด้วยตนเองเป็นสิ่งจำเป็น) Node Load Balancing จะตรวจพบโดยอัตโนมัติว่า Database หลักหยุดทำงานหรือไม่และเลื่อนระดับ Database รองที่มีอยู่รายการใดรายการหนึ่งเมื่อ Node ที่มีปัญหากลับมาแล้ว Node นั้นจะถูกเพิ่มเข้าไปใน Cluster อีกครั้งโดยอัตโนมัติ (เป็น Node รอง) พร้อมข้อมูลที่ขาดหายไปทั้งหมดจะถูกกู้คืนโดยใช้พีกรีวินด์คุณประโยชน์.

สถานการณ์การ Failover ด้วยตนเอง

PostgreSQL ไม่มีสถานการณ์การ Failover อัตโนมัติแบบเนทีฟสำหรับ ClusterDatabase ในทางกลับกันเนื่องจากมีโซลูชันของบริษัทอื่นมากมายที่คุณสามารถใช้เพื่อนำไปใช้เพื่อให้แน่ใจว่าระบบของคุณมีความพร้อมใช้งานสูงในเวลาเดียวกันคุณสามารถสร้างโซลูชันของคุณเองเพื่อเอาชนะความล้มเหลวของ ClusterDatabase ของคุณได้สถานการณ์ความล้มเหลวของ Cluster เกิดขึ้นได้ในชีวิตจริงที่นี่เราจะพิจารณาเพียง Workflow ทั่วไปเพียงขั้นตอนเดียวเท่านั้นที่สามารถช่วยให้คุณสร้างสถานการณ์การ Failover ได้โดยอัตโนมัติ

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

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

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

ที่ไหน/var/lib/pgsql/dataเป็น Directory ข้อมูล Database

เมื่อ Database รองได้รับการเลื่อนระดับเป็น Database หลักคุณควรเปลี่ยนสตริงการเชื่อมต่อ Application ของคุณเพื่อเปลี่ยนจุดเข้าใช้งาน ClusterDatabase เป็นชื่อ Host หรือที่อยู่ IP ใหม่

กระบวนการ Failover สามารถพึ่งพาได้pg_isreadyยูทิลิตี้ที่ออกการตรวจสอบการเชื่อมต่อกับ Database PostgreSQL

คุณสามารถสร้าง Script ง่ายๆซึ่งจะตรวจสอบความพร้อมใช้งานของ ServerDatabase หลักและส่งเสริมการสแตนด์บายในกรณีที่เกิดความล้มเหลวหลักรัน Script ผ่านไฟล์โครนแท็บที่ Node รองด้วยช่วงเวลาที่เหมาะสม Script อาจมีลักษณะเช่นนี้ลองเรียกมันว่าFailover.ช::

#!/bin/bash
primary="172.25.2.22"
secondary="172.25.2.31"
status=$(/usr/pgsql-12/bin/pg_isready -d postgres -h $primary)
response="$primary:5432 - no response"
if [ "$status" == "$response" ]
then
/usr/pgsql-12/bin/pg_ctl promote -D /var/lib/pgsql/data
echo "Secondary promoted to new Primary. Change your app connection string to new Primary address $secondary"
else
echo "Primary is alive. Nothing to do."
fi

เมื่อ Script ถูกทริกเกอร์การเลื่อนระดับรองไปที่ระดับหลักผลลัพธ์ของ Script ควรมีลักษณะดังนี้:

ตอนนี้ Database ของคุณกลับมาทำงานอีกครั้งและพร้อมที่จะจัดการคำขออ่าน/เขียนตามที่อยู่หลักใหม่

การฟื้นฟู Cluster

ด้วยที่อยู่หลักใหม่คุณสามารถหลีกเลี่ยงการปรับสตริงการเชื่อมต่อ Application ของคุณโดยการเปลี่ยนที่อยู่ IP ของ Database หลักได้อย่างง่ายดายในการทำเช่นนี้คุณต้องใส่Load Balancerด้านหน้า Cluster ที่จะตรวจสอบสถานะของส่วนประกอบและกำหนดเส้นทาง Traffic ไปยัง Cluster หลักปัจจุบันด้านล่างนี้เราจะสาธิตวิธีการคืนค่า TopologyCluster ดั้งเดิมดังนั้นจึงไม่จำเป็นต้องทำการเปลี่ยนแปลงที่ฟรอนต์เอนด์

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

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

ดังนั้นภารกิจคือ: หลักที่ส่งออกไปควรกลายเป็นหลักที่แท้จริงและหลักปัจจุบัน (รองก่อนหน้านี้) ควรกลายเป็นรองจริง

ข้อมูลเริ่มต้นคือ:

• ClusterDatabase ประกอบด้วยสอง Node หลัก (ไอพี: 172.25.2.22) และรอง (ไอพี: 172.25.2.31).
• Node หลักหยุดทำงานและ Database หลักหยุดทำงาน
• Database สแตนด์บายได้รับการเลื่อนตำแหน่งเป็นบทบาทหลัก
• ตอนนี้ส่วนรองยังคงอ่าน/เขียนอยู่
• Node หลักเดิมได้รับการแก้ไขแล้วและพร้อมที่จะนำกลับมาใช้อีกครั้งในการจำลองแบบเป็น Node หลัก

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

1. ป้อน Node หลักเดิมผ่าน Web SSH และออกคำสั่ง:

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

2. เพิ่มที่อยู่ IP หลักเดิม 172.22.2.22 ลงในpg_hba.confที่ Node หลักปัจจุบัน:

host replication replication 172.22.2.22/32 trust

RestartDatabase หลักปัจจุบันเพื่อใช้การเปลี่ยนแปลง:

sudo service postgresql restart

3. ป้อน Node หลักเดิมผ่าน Web SSH และออกคำสั่ง:

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

ที่ไหน:

• pg_basebackup- ใช้เพื่อสำรองข้อมูลพื้นฐานของ ClusterDatabase PostgreSQL ที่ทำงานอยู่
• 172.25.2.31- ที่อยู่ IP ของ Node หลักปัจจุบัน
• /var/lib/pgsql/data- Directory ข้อมูล PostgreSQL

4. ตรวจสอบให้แน่ใจว่าที่อยู่ IP ในเจ้าภาพParameter ที่อธิบายไว้ในขั้นตอนที่สองของการกำหนดค่าสแตนด์บายมีที่อยู่ IP ที่ถูกต้องของที่อยู่หลักเดิม

5. สร้างสแตนด์บายสัญญาณไฟล์ที่หลักปัจจุบัน:

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

และ Restart Node เพื่อรับ Database รองใหม่:

sudo service postgresql restart

ลบสแตนด์บายสัญญาณไฟล์ที่ Primary เดิม:

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

และ Restart Node เพื่อรับ Database หลักใหม่:

sudo service postgresql restart

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

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