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

วิธีหนึ่งทำการติดตั้งสองเซิร์ฟเวอร์ที่เหมือนกันสำหรับการเฟลโอเวอร์อัตโนมัติใน PostgreSQL 9.1

ระบบปฏิบัติการ

Centos 5
PostgreSQL 9.1 รวบรวมจากแหล่งข้อมูล
บัญชีผู้ใช้ postgres มีอยู่ในเครื่องทั้งสองเครื่องและมีรหัสผ่าน ssh ที่ไม่มีรหัสผ่านเพื่อเชื่อมต่อกับทั้งสองเครื่อง

การตั้งค่าปัจจุบันของฉัน:

การกำหนดค่าเซิร์ฟเวอร์หลัก:

postgresql.conf:

listen_address = '*'
wal_level = hot_standby
max_wal_senders = 3
checkpoint_segments = 16    
wal_keep_segments = 8 
archive_mode = on    
archive_command = 'cp "%p" /opt/pgsql91/archive/"%f"'  

pg_hba.conf:

 host  replication   all   10.0.66.1/32      trust
 host  replication   all   10.0.66.2/32      trust

เซิร์ฟเวอร์แสตนด์บาย

postgresql.conf และ pg_hba.conf เหมือนกับสิ่งที่กำหนดค่าไว้บนเซิร์ฟเวอร์ต้นแบบ

recovery.conf:

 standby_mode = 'on'
 primary_conninfo = 'host=10.0.66.1'
 trigger_file = '/opt/pgsql91/data/trigger.txt'

ขอบคุณ hzRoot ตอนนี้ฉันเข้าใจวิธีการเปลี่ยนเซิร์ฟเวอร์จากโหมดสแตนด์บายเป็นแบบมาสเตอร์

ด้วยการใช้คำสั่งต่อไปนี้ฉันสามารถซิงโครไนซ์ทาสตัวใหม่กับต้นแบบใหม่แล้วรับการสำรองข้อมูลการจำลองแบบและทำงาน

บนต้นแบบใหม่ (10.0.66.2)

1. su - postgres
2. touch trigger.txt ใน / opt / pgsql91 / data /
3. recovery.conf กลายเป็น recovery.done
4. psql -c "; SELECT pg_start_backup ('สำรองข้อมูล', จริง)";
5. rsync -a -v -e ssh / opt / pgsql91 / data / 10.0.66.1:/opt/pgsql91/data/ --exclude postmaster.pid
6. psql -c "; SELECT pg_stop_backup ()";

บนทาสใหม่ (10.0.66.1)

1. สร้าง recovery.conf: cp recovery.done ไปที่ recovery.conf
2. vi recovery.conf เปลี่ยนที่อยู่ IP: primary_conninfo = 'host = 10.0.66.2'
3. เริ่ม postgresql

ดังนั้นตอนนี้คำถามของฉัน:

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

ตรวจสอบrepmrg :

repmgr เป็นชุดเครื่องมือโอเพนซอร์ซที่ช่วย DBA และผู้ดูแลระบบจัดการคลัสเตอร์ของฐานข้อมูล PostgreSQL

ด้วยการใช้ประโยชน์จากความสามารถ Hot Standby ที่แนะนำใน PostgreSQL 9, repmgr ช่วยลดความยุ่งยากของกระบวนการตั้งค่าและจัดการฐานข้อมูลด้วยความพร้อมใช้งานสูงและข้อกำหนดด้านความยืดหยุ่น

repmgr ทำให้การบริหารจัดการและการจัดการรายวันง่ายขึ้นเพิ่มประสิทธิภาพและลดต้นทุนโดยรวมของคลัสเตอร์ PostgreSQL โดย:

• การตรวจสอบกระบวนการจำลองแบบ การอนุญาตให้ DBAs ออกสูง
• การดำเนินงานความพร้อมใช้งานเช่น switch-overs และ fail-overs

มันทำสองสิ่ง:

1. repmgr: โปรแกรมคำสั่งที่ทำงานบนคลัสเตอร์ของคุณจากนั้นออก
2. repmgrd: การจัดการและการตรวจสอบภูตที่เฝ้าดูคลัสเตอร์และสามารถทำการกระทำระยะไกลโดยอัตโนมัติ

สำหรับการ failover อัตโนมัติ repmgrd ทำเคล็ดลับและไม่ใช่ SPOF ในเครือข่ายของคุณเช่น pgPool อย่างไรก็ตามมันยังคงเป็นสิ่งสำคัญในการตรวจสอบ deamons ทั้งหมดและนำพวกเขากลับมาหลังจากความล้มเหลว

เวอร์ชั่น 2.0 กำลังจะเปิดตัวรวมถึง RPM

ในไฟล์ recovery.conf คุณควรเพิ่มบรรทัดที่บอก postgres ให้ failover จาก master เป็น slave คุณควรเพิ่ม

trigger_file = '/any/file/to/trigger'

เมื่อคุณสร้างไฟล์นี้ในเส้นทางที่กำหนด โหนดจะเปลี่ยน (ไฟล์ไม่รวมสิ่งที่มันเป็นเพียงทริกเกอร์)

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

ในทางกลับกันอาจเป็นไปได้ที่จะทำให้มันสร้างขึ้นโดยอัตโนมัติด้วยเทคนิคบางอย่าง แต่การใช้เครื่องมือตรวจสอบและการทำผิดพลาดด้วยตนเองจะดีกว่า ..

มีใครคิดที่จะใช้ pgpool-II สำหรับเรื่องนี้?

http://pgpool.projects.postgresql.org/contrib_docs/simple_sr_setting/index.html

ฉันตั้งค่าการจำลองแบบสำหรับ PostgreSQL ดูเหมือนว่าส่วนที่ยุ่งยากเกิดขึ้นเมื่อเจ้านายเก่ากลับมา

จากสิ่งที่ฉันได้อ่าน pgpool ดูเหมือนว่ามันจะเป็นไปโดยอัตโนมัติ อย่างไรก็ตามฉันไม่แน่ใจว่าจะยกระดับคุณสมบัติการจำลองแบบที่มีอยู่แล้วใน PostgreSQL 9.1