PostgreSQL failover และการจำลองแบบ


14

ฉันประเมิน PostgreSQL 9.1 และมีคำถามสองสามข้อที่เกี่ยวข้องกับรายละเอียดการเฟลโอเวอร์และการจำลองแบบ

ฉันมีสถานการณ์การทดสอบน้อย สิ่งแรกคือเซิร์ฟเวอร์หลักและทาสไม่กี่คน ในกรณีที่อาจารย์ขัดข้องฉันต้องการให้ทาสคนหนึ่งกลายเป็นนาย หลังจากที่ Master กลับสู่สภาวะปกติแล้วควรซิงค์กับเซิร์ฟเวอร์อื่นในคลัสเตอร์ (ใช้การเปลี่ยนแปลงทั้งหมดที่ทำในขณะที่มันหยุดทำงาน) และเรียกคืนบทบาท Master หรือกลายเป็น Slave

ปัญหาที่ฉันเห็นด้วย PostgreSQL และสถานการณ์ปัจจุบันมีดังต่อไปนี้

1) ฉันไม่เห็นเครื่องมือในตัวสำหรับตรวจจับการหยุดทำงานของเซิร์ฟเวอร์หลัก ฉันอ่านว่า pgpool สามารถจัดการกับมันและสร้างไฟล์ทริกเกอร์ได้ฉันยังอ่านอีกว่าผู้คนใช้เครื่องมือ heartbeat Linux หรือเครื่องมือที่คล้ายกันสำหรับเรื่องนี้ โอเคฉันสามารถตรวจจับความล้มเหลวและกำหนดมาสเตอร์ใหม่ในคลัสเตอร์ได้ ทาสคนอื่นจะเข้าใจหรือไม่ว่ามีเจ้านายคนใหม่และพวกเขาควรจะสำรองไว้ตอนนี้หรือไม่?

2) ฉันไม่เข้าใจขั้นตอนการย้อนกลับ การกำหนดค่าโฮสต์ Master และ Slave นั้นแตกต่างกัน ดังนั้นฉันจะมีผู้เชี่ยวชาญสองคนหลังจากที่ล้มเหลวของอาจารย์ล้มเหลวหรือไม่ เซิร์ฟเวอร์จะซิงค์กันอย่างไร ฉันเห็นวิธีแก้ปัญหาด้วยตนเองเช่น "ถ่ายโอนโฟลเดอร์ข้อมูลไปยังเซิร์ฟเวอร์แล้วรีสตาร์ท" ดังนั้นทางออกหรือแนวปฏิบัติที่ดีที่สุดหรือหลักสำคัญอย่างน้อยที่นี่คืออะไร

3) ฉันควรจัดการเซิร์ฟเวอร์ขัดข้องทางฝั่งไคลเอ็นต์ได้อย่างไร เมื่อฉันสร้างการเชื่อมต่อฉันระบุ IP ของเซิร์ฟเวอร์อย่างชัดเจน ฉันควรพัฒนา ConnectionManager บางประเภทซึ่งจะรู้จักโครงสร้าง Master-Slave ของฉันส่งคำขอไปยัง Master เท่านั้นและในกรณีที่การเชื่อมต่อขาดหายไปจะเปลี่ยนไปใช้เซิร์ฟเวอร์สำรองเป็นต้น ฉันอ่านว่า pgpool สามารถเป็นจุดเริ่มต้นสำหรับแอปพลิเคชันและจัดการการเชื่อมต่อในวิธีที่ถูกต้อง pgpool เป็นทางออกเดียวหรือไม่? มันจัดการกับ failover และ failback ได้ดีหรือไม่?

4) มีวิธีแก้ปัญหา (เชิงพาณิชย์ด้วย) ดังนั้นฉันสามารถหลีกเลี่ยงการคัดลอกข้อมูลด้วยตนเองตั้งค่าอินสแตนซ์ของ PostgreSQL และสิ่งอื่น ๆ ที่ควรทำด้วยมือ? ดังนั้นการกำหนดค่าคลัสเตอร์เมื่อทุกคนซิงค์กันชัดเจนว่าใครเป็นนายและทุกอย่างสลับไปมาโดยอัตโนมัติ

ตามหัวข้อและบทความเหล่านี้

การจำลองแบบสตรีมมิ่งและความล้มเหลวบน PostgreSQL

การทำงานอัตโนมัติล้มเหลวใน PostgreSQL 9.1

http://denishjpatel.blogspot.com/2010/11/possibility-of-graceful-switchover.html

ไม่มีวิธีแก้ปัญหาอัตโนมัติเต็มรูปแบบเดียวในการแก้คำถามเหล่านี้ ฉันถูกไหม?

ขอบคุณ!


มันอาจจะคุ้มค่าชี้ไปที่เกี่ยวข้อง 9.2 เอกสาร
ไมค์ Sherrill 'Cat Recall'

คำตอบ:


4
  1. ทาสไม่เข้าใจนายคนใหม่ คุณควรทำเช่นนั้นด้วยตนเอง
  2. ใช่มันแตกต่างกันและคุณควรสร้างอันใหม่สำหรับมาสเตอร์เก่าไม่ว่าสแตนด์บายเก่าจะทำงานเป็นมาสเตอร์ต่อไปได้ แต่คุณควรตั้งค่า max_wal_senders บนโหนดนั้น คุณควรตั้งค่า pg_hba.conf ของต้นแบบใหม่หลังจากเกิดความล้มเหลว หลังจาก failover (เมื่อโหนดเปลี่ยนบทบาท master-> slave slave-> master) คุณควรถ่ายโอนไฟล์ wal ใหม่ไปยังไดเรคทอรีโฟลเดอร์ข้อมูลสแตนด์บายใหม่ที่คุณตั้งค่าในไฟล์ recovery.conf หรือเพียงแค่คุณสามารถใช้ rsync

  3. อาจเป็นคุณสามารถใช้ pgbouncer ด้วยวิธีนี้คุณจะเปลี่ยนที่อยู่เซิร์ฟเวอร์ pgbouncer เป็นเจ้านายใหม่

  4. EnterpriseDB มีเครื่องมือเชิงพาณิชย์ อาจเป็นคุณสามารถตรวจสอบพวกเขา

และในที่สุดก็ใช่คุณพูดถูก ไม่มีวิธีแก้ปัญหาอัตโนมัติเต็มรูปแบบเดียวในการแก้คำถามเหล่านี้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.