เรื่องราวความล้มเหลวของ Patroni หรือวิธีทำให้คลัสเตอร์ PostgreSQL ของคุณพัง อเล็กเซย์ เลซอฟสกี

เป้าหมายหลักของ Patroni คือการจัดเตรียมความพร้อมใช้งานสูงสำหรับ PostgreSQL แต่ Patroni เป็นเพียงเทมเพลต ไม่ใช่เครื่องมือสำเร็จรูป (ซึ่งโดยทั่วไปมีการระบุไว้ในเอกสารประกอบ) เมื่อมองแวบแรก เมื่อตั้งค่า Patroni ในห้องปฏิบัติการทดสอบแล้ว คุณจะเห็นได้ว่าเครื่องมือนี้เป็นเครื่องมือที่ยอดเยี่ยมเพียงใด และจัดการกับความพยายามของเราที่จะทำลายคลัสเตอร์ได้ง่ายเพียงใด อย่างไรก็ตาม ในทางปฏิบัติ ในสภาพแวดล้อมการผลิต ทุกสิ่งไม่ได้เกิดขึ้นอย่างสวยงามและหรูหราเหมือนในห้องปฏิบัติการทดสอบเสมอไป

ฉันจะบอกคุณเล็กน้อยเกี่ยวกับตัวฉันเอง ฉันเริ่มต้นจากการเป็นผู้ดูแลระบบ ทำงานในการพัฒนาเว็บ ฉันทำงานที่ Data Egret มาตั้งแต่ปี 2014 บริษัทมีส่วนร่วมในการให้คำปรึกษาในด้าน Postgres และเราให้บริการ Postgres ทุกประการ และเราทำงานร่วมกับ Postgres ทุกวัน ดังนั้นเราจึงมีความเชี่ยวชาญที่แตกต่างกันเกี่ยวกับการดำเนินการ

และในปลายปี 2018 เราเริ่มใช้ Patroni อย่างช้าๆ และสั่งสมประสบการณ์มาบ้าง เราวินิจฉัยมัน ปรับแต่งมัน มาถึงแนวทางปฏิบัติที่ดีที่สุดของเรา และในรายงานนี้ฉันจะพูดถึงพวกเขา

นอกเหนือจาก Postgres แล้ว ฉันรักลินุกซ์ ฉันชอบแหย่มันและสำรวจ ฉันชอบสะสมคอร์ ฉันชอบระบบเสมือนจริง คอนเทนเนอร์ นักเทียบท่า Kubernetes ทั้งหมดนี้ทำให้ฉันสนใจเพราะนิสัยของผู้ดูแลระบบแบบเก่ากำลังส่งผลกระทบ ฉันชอบที่จะจัดการกับการตรวจสอบ และฉันชอบโพสต์เกรสที่เกี่ยวข้องกับการดูแลระบบ เช่น การจำลองแบบ การสำรองข้อมูล และในเวลาว่างฉันเขียนใน Go ฉันไม่ใช่วิศวกรซอฟต์แวร์ ฉันแค่เขียนเพื่อตัวเองใน Go และมันทำให้ฉันมีความสุข

• ฉันคิดว่าพวกคุณหลายคนรู้ว่า Postgres ไม่มี HA (ความพร้อมใช้งานสูง) นอกกรอบ ในการรับ HA คุณต้องติดตั้งบางอย่าง กำหนดค่า ใช้ความพยายามและรับมัน
• มีเครื่องมือหลายอย่างและ Patroni เป็นหนึ่งในนั้นที่แก้ปัญหา HA ได้ค่อนข้างดีและดีมาก แต่ด้วยการรวมทุกอย่างไว้ในห้องแล็บทดสอบและเรียกใช้ เราจะเห็นว่าทุกอย่างใช้งานได้ เราสามารถสร้างปัญหาขึ้นมาใหม่ได้ ดูว่า Patroni ให้บริการอย่างไร และเราจะเห็นว่าทุกอย่างทำงานได้ดี
• แต่ในทางปฏิบัติเราประสบปัญหาที่แตกต่างกัน และฉันจะพูดถึงปัญหาเหล่านี้
• ฉันจะบอกคุณว่าเราวินิจฉัยได้อย่างไร สิ่งที่เราปรับแต่ง - ไม่ว่ามันจะช่วยเราหรือไม่ก็ตาม

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

และข้อจำกัดความรับผิดชอบเล็กน้อยก่อนที่เราจะเริ่มต้นรายงานของเรา

ปัญหาทั้งหมดที่เราเจอ เรามีตั้งแต่ 6-7-8 เดือนแรกของการทำงาน เมื่อเวลาผ่านไป เรามาถึงแนวทางปฏิบัติที่ดีที่สุดภายในของเรา และปัญหาของเราก็หมดไป ดังนั้น รายงานดังกล่าวจึงถูกประกาศเมื่อหกเดือนก่อน ในตอนที่ผมคิดใหม่ทั้งหมดและผมจำมันได้อย่างสมบูรณ์

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

Patroni คืออะไร?

• นี่คือเทมเพลตสำหรับการสร้าง HA นั่นคือสิ่งที่กล่าวในเอกสารประกอบ และจากมุมมองของฉัน นี่เป็นคำชี้แจงที่ถูกต้องมาก Patroni ไม่ใช่กระสุนเงินที่จะแก้ปัญหาทั้งหมดของคุณนั่นคือคุณต้องพยายามทำให้มันได้ผลและก่อให้เกิดประโยชน์
• นี่คือบริการตัวแทนที่ติดตั้งในทุกบริการฐานข้อมูลและเป็นระบบเริ่มต้นสำหรับ Postgres ของคุณ มันเริ่มต้น Postgres หยุด รีสตาร์ท กำหนดค่าใหม่ และเปลี่ยนโทโพโลยีของคลัสเตอร์ของคุณ
• ดังนั้น เพื่อจัดเก็บสถานะของคลัสเตอร์ การแสดงปัจจุบันจึงจำเป็นต้องมีพื้นที่เก็บข้อมูลบางประเภท และจากมุมมองนี้ Patroni ใช้เส้นทางของการจัดเก็บสถานะในระบบภายนอก เป็นระบบจัดเก็บการกำหนดค่าแบบกระจาย อาจเป็น Etcd, Consul, ZooKeeper หรือ kubernetes Etcd เช่น หนึ่งในตัวเลือกเหล่านี้
• และคุณลักษณะอย่างหนึ่งของ Patroni คือคุณนำตัวกรองอัตโนมัติออกจากกล่องได้ เพียงแค่ตั้งค่าเท่านั้น หากเราใช้ Repmgr เพื่อเปรียบเทียบ ก็จะรวม filer ไว้ที่นั่น ด้วย Repmgr เราได้รับการเปลี่ยน แต่ถ้าเราต้องการ autofiler เราก็จำเป็นต้องกำหนดค่าเพิ่มเติม Patroni มีตัวกรองอัตโนมัติอยู่แล้ว
• และยังมีอีกหลายสิ่งหลายอย่าง ตัวอย่างเช่น การบำรุงรักษาการกำหนดค่า การเทสำเนาใหม่ การสำรองข้อมูล ฯลฯ แต่นี่อยู่นอกเหนือขอบเขตของรายงาน ฉันจะไม่พูดถึงเรื่องนี้

และผลลัพธ์เล็กๆ น้อยๆ ก็คืองานหลักของ Patroni คือการทำไฟล์อัตโนมัติให้ดีและเชื่อถือได้ เพื่อให้คลัสเตอร์ของเรายังคงใช้งานได้ และแอปพลิเคชันไม่สังเกตเห็นการเปลี่ยนแปลงในโทโพโลยีของคลัสเตอร์

แต่เมื่อเราเริ่มใช้ Patroni ระบบของเราจะซับซ้อนขึ้นเล็กน้อย หากก่อนหน้านี้เรามี Postgres เมื่อใช้ Patroni เราจะได้ Patroni เอง เราจะได้รับ DCS ที่จัดเก็บสถานะ และทุกอย่างต้องได้ผล แล้วจะเกิดอะไรขึ้น?

อาจแตก:

• Postgres อาจแตก สามารถเป็นต้นแบบหรือแบบจำลอง หนึ่งในนั้นอาจล้มเหลว
• Patroni เองอาจแตกสลาย
• DCS ที่จัดเก็บสถานะอาจเสียหาย
• และเครือข่ายสามารถทำลายได้

ฉันจะพิจารณาประเด็นทั้งหมดเหล่านี้ในรายงาน

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

และกรณีแรกนั้นง่ายที่สุด นี่เป็นกรณีที่เราใช้คลัสเตอร์ฐานข้อมูลและปรับใช้ที่เก็บข้อมูล DCS ของเราบนคลัสเตอร์เดียวกัน นี่เป็นข้อผิดพลาดที่พบบ่อยที่สุด นี่เป็นข้อผิดพลาดในการสร้างสถาปัตยกรรม กล่าวคือ การรวมส่วนประกอบต่างๆ ไว้ในที่เดียว

มีผู้ยื่นขอไปจัดการกับสิ่งที่เกิดขึ้น

และที่นี่เราสนใจว่าไฟล์เกิดขึ้นเมื่อใด นั่นคือเราสนใจในช่วงเวลานี้เมื่อสถานะของคลัสเตอร์เปลี่ยนไป

แต่ตัวเก็บไฟล์ไม่ได้เกิดขึ้นทันทีเสมอไป กล่าวคือ มันไม่ได้ใช้เวลาหน่วยใด ๆ มันสามารถล่าช้าได้ สามารถติดทนนาน

ดังนั้นจึงมีเวลาเริ่มต้นและเวลาสิ้นสุด เช่น เป็นเหตุการณ์ที่ต่อเนื่องกัน และเราแบ่งเหตุการณ์ทั้งหมดออกเป็นสามช่วงเวลา: เรามีเวลาก่อนไฟล์เดอร์ ระหว่างไฟล์เดอร์ และหลังไฟล์เดอร์ นั่นคือเราพิจารณาเหตุการณ์ทั้งหมดในไทม์ไลน์นี้

อย่างแรกเลย เมื่อไฟล์เกอร์เกิดขึ้น เราจะมองหาสาเหตุของสิ่งที่เกิดขึ้น อะไรคือสาเหตุของไฟล์เดอร์

หากเราดูที่ท่อนซุง พวกมันจะเป็นท่อนซุงคลาสสิกของ Patroni เขาบอกเราว่าเซิร์ฟเวอร์กลายเป็นมาสเตอร์และบทบาทของมาสเตอร์ได้ผ่านไปยังโหนดนี้แล้ว นี่มันเน้น

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

หากเราดูที่เหตุการณ์ก่อนหน้า filer เราจะเห็นว่ามีเหตุผลมากมายที่เป็นปัญหาสำหรับการดำเนินการต่อของตัวช่วยสร้าง

หากเราดูบันทึกของ Patroni เราจะเห็นว่าเรามีข้อผิดพลาดมากมาย หมดเวลา เช่น ตัวแทน Patroni ไม่สามารถทำงานกับ DCS ได้ ในกรณีนี้ นี่คือตัวแทนกงสุล ซึ่งกำลังสื่อสารบนพอร์ต 8500

และปัญหาที่นี่คือ Patroni และฐานข้อมูลทำงานบนโฮสต์เดียวกัน และเซิร์ฟเวอร์กงสุลเปิดตัวบนโหนดเดียวกัน ด้วยการสร้างโหลดบนเซิร์ฟเวอร์ เราได้สร้างปัญหาให้กับเซิร์ฟเวอร์ Consul ด้วยเช่นกัน พวกเขาไม่สามารถสื่อสารได้อย่างถูกต้อง

หลังจากผ่านไประยะหนึ่ง เมื่อโหลดลดลง Patroni ของเราก็สามารถสื่อสารกับเจ้าหน้าที่ได้อีกครั้ง กลับมาทำงานตามปกติ และเซิร์ฟเวอร์ Pgdb-2 เดิมก็กลายเป็นเซิร์ฟเวอร์หลักอีกครั้ง นั่นคือมีการพลิกกลับเล็กน้อยเนื่องจากโหนดลาออกจากอำนาจของอาจารย์แล้วเข้ายึดอีกครั้งนั่นคือทุกอย่างกลับมาเหมือนเดิม

และนี่อาจถือเป็นการเตือนที่ผิดพลาด หรืออาจถือได้ว่า Patroni ทำทุกอย่างถูกต้อง นั่นคือเขาตระหนักว่าเขาไม่สามารถรักษาสถานะของกลุ่มและถอดอำนาจของเขาออกได้

และที่นี่ปัญหาเกิดขึ้นเนื่องจากเซิร์ฟเวอร์ Consul อยู่บนฮาร์ดแวร์เดียวกันกับฐาน ดังนั้น โหลดใด ๆ: ไม่ว่าจะเป็นโหลดบนดิสก์หรือโปรเซสเซอร์ ก็ยังส่งผลต่อการโต้ตอบกับคลัสเตอร์ Consul

และเราตัดสินใจว่าไม่ควรอยู่ด้วยกัน เราจัดสรรกลุ่มแยกต่างหากสำหรับกงสุล และ Patroni ได้ทำงานร่วมกับกงสุลแยกต่างหาก นั่นคือ มีกลุ่ม Postgres แยกต่างหาก ซึ่งเป็นกลุ่มกงสุลแยกต่างหาก นี่คือคำแนะนำเบื้องต้นเกี่ยวกับวิธีพกพาและเก็บรักษาสิ่งเหล่านี้เพื่อไม่ให้อยู่ด้วยกัน

คุณสามารถบิดพารามิเตอร์ ttl, loop_wait, retry_timeout, เช่น พยายามรักษายอดโหลดในระยะสั้นเหล่านี้ให้คงอยู่ได้ด้วยการเพิ่มพารามิเตอร์เหล่านี้ แต่นี่ไม่ใช่ตัวเลือกที่เหมาะสมที่สุดเนื่องจากการโหลดนี้อาจใช้เวลานาน และเราจะก้าวข้ามขีดจำกัดของพารามิเตอร์เหล่านี้ และนั่นอาจช่วยไม่ได้จริงๆ

ปัญหาแรกอย่างที่คุณเข้าใจนั้นง่ายมาก เราเอา DCS มารวมกับฐาน เรามีปัญหา

ปัญหาที่สองคล้ายกับปัญหาแรก คล้ายกับที่เรามีปัญหาการทำงานร่วมกันกับระบบ DCS อีกครั้ง

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

นายเก่ากลายเป็นแบบจำลอง Patroni ทำงานที่นี่ตามที่ควรจะเป็น มันทำงาน pg_rewind เพื่อย้อนกลับบันทึกการทำธุรกรรมจากนั้นเชื่อมต่อกับต้นแบบใหม่เพื่อติดตามต้นแบบใหม่ ที่นี่ Patroni ทำงานได้ดีเท่าที่ควร

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

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

และเมื่อเลื่อนไปยังจุดที่ข้อผิดพลาดเริ่มปรากฏ เราจะเห็นว่าเรามีไฟล์โอเวอร์อัตโนมัติ และเนื่องจากข้อผิดพลาดของเราเกี่ยวข้องกับการโต้ตอบกับ DCS และในกรณีของเรา เราใช้กงสุล เราจึงดูบันทึกของกงสุลด้วยว่าเกิดอะไรขึ้นที่นั่น

เมื่อเปรียบเทียบเวลาของผู้ยื่นไฟล์กับเวลาในบันทึกกงสุลอย่างคร่าว ๆ เราจะเห็นว่าเพื่อนบ้านของเราในกลุ่มกงสุลเริ่มสงสัยการมีอยู่ของสมาชิกคนอื่น ๆ ของกลุ่มกงสุล

และถ้าคุณดูบันทึกของตัวแทนกงสุลคนอื่นๆ คุณยังเห็นได้ว่ามีการล่มสลายของเครือข่ายบางอย่างเกิดขึ้นที่นั่น และสมาชิกในกลุ่มกงศุลต่างก็สงสัยในการมีอยู่ของกันและกัน และนี่คือแรงผลักดันสำหรับผู้ยื่นเอกสาร

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

คำตอบที่ง่ายที่สุดคือการซ่อมแซมเครือข่าย แต่สำหรับผมการยืนอยู่บนโพเดียมมันง่ายที่จะพูดแบบนี้ แต่สถานการณ์เป็นเช่นนั้นลูกค้าไม่สามารถซ่อมแซมเครือข่ายได้เสมอไป เขาอาจอาศัยอยู่ใน DC และอาจไม่สามารถซ่อมแซมเครือข่ายได้ ส่งผลกระทบต่ออุปกรณ์ ดังนั้นจึงจำเป็นต้องมีตัวเลือกอื่น ๆ

มีตัวเลือก:

• ตัวเลือกที่ง่ายที่สุดซึ่งเขียนในความคิดของฉันแม้ในเอกสารประกอบคือการปิดใช้งานการตรวจสอบกงสุลนั่นคือเพียงแค่ส่งอาร์เรย์ที่ว่างเปล่า และเราบอกตัวแทนกงศุลว่าอย่าใช้เช็คใดๆ ด้วยการตรวจสอบเหล่านี้ เราสามารถเพิกเฉยต่อพายุเครือข่ายเหล่านี้และไม่เริ่มสร้างไฟล์
• อีกทางเลือกหนึ่งคือการตรวจสอบraft_multiplierอีกครั้ง นี่คือพารามิเตอร์ของเซิร์ฟเวอร์กงสุลเอง ตามค่าดีฟอลต์ จะถูกตั้งค่าเป็น 5 ค่านี้แนะนำโดยเอกสารประกอบสำหรับสภาพแวดล้อมการจัดเตรียม ในความเป็นจริงสิ่งนี้ส่งผลต่อความถี่ของการส่งข้อความระหว่างสมาชิกของเครือข่ายกงสุล ในความเป็นจริง พารามิเตอร์นี้ส่งผลต่อความเร็วของการสื่อสารบริการระหว่างสมาชิกของกลุ่มกงสุล และสำหรับการผลิต ขอแนะนำให้ลดขนาดลงเพื่อให้โหนดแลกเปลี่ยนข้อความบ่อยขึ้น
• อีกทางเลือกหนึ่งที่เราพบคือการเพิ่มลำดับความสำคัญของกระบวนการ Consul ท่ามกลางกระบวนการอื่นๆ สำหรับตัวกำหนดตารางเวลากระบวนการของระบบปฏิบัติการ มีพารามิเตอร์ที่ "ดี" เพียงกำหนดลำดับความสำคัญของกระบวนการที่ตัวกำหนดตารางเวลา OS นำมาพิจารณาเมื่อตั้งเวลา เรายังลดมูลค่าที่ดีสำหรับตัวแทนกงสุล เช่น เพิ่มลำดับความสำคัญเพื่อให้ระบบปฏิบัติการให้ Consul มีเวลามากขึ้นในการทำงานและดำเนินการโค้ด ในกรณีของเรา สิ่งนี้ช่วยแก้ปัญหาของเราได้
• อีกทางเลือกหนึ่งคือไม่ใช้กงศุล ฉันมีเพื่อนที่เป็นผู้สนับสนุนรายใหญ่ของ Etcd และเราก็โต้เถียงกับเขาเป็นประจำว่า Etcd หรือ Consul ดีกว่ากัน แต่ในแง่ของสิ่งที่ดีกว่า เรามักจะเห็นด้วยกับเขาว่า Consul มีตัวแทนที่ควรจะทำงานในแต่ละโหนดที่มีฐานข้อมูล นั่นคือปฏิสัมพันธ์ของ Patroni กับกลุ่มกงสุลต้องผ่านตัวแทนนี้ และตัวแทนนี้จะกลายเป็นคอขวด หากมีอะไรเกิดขึ้นกับตัวแทน Patroni จะไม่สามารถทำงานร่วมกับ Consul Cluster ได้อีกต่อไป และนี่คือปัญหา ไม่มีตัวแทนในแผน Etcd Patroni สามารถทำงานได้โดยตรงกับรายการเซิร์ฟเวอร์ Etcd และสื่อสารกับพวกเขาแล้ว ในเรื่องนี้ หากคุณใช้ Etcd ในบริษัทของคุณ Etcd น่าจะเป็นทางเลือกที่ดีกว่ากงสุล แต่เราที่ลูกค้าของเรามักถูกจำกัดโดยสิ่งที่ลูกค้าเลือกและใช้เสมอ และเรามีกงสุลเป็นส่วนใหญ่สำหรับลูกค้าทั้งหมด
• และจุดสุดท้ายคือการแก้ไขค่าพารามิเตอร์ เราสามารถเพิ่มพารามิเตอร์เหล่านี้โดยหวังว่าปัญหาเครือข่ายในระยะสั้นของเราจะสั้นและไม่ตกอยู่นอกช่วงของพารามิเตอร์เหล่านี้ วิธีนี้ทำให้เราสามารถลดความก้าวร้าวของ Patroni เพื่อบันทึกอัตโนมัติหากเกิดปัญหาเครือข่าย

ฉันคิดว่าหลายคนที่ใช้ Patroni คุ้นเคยกับคำสั่งนี้

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

ดังนั้นจึงมีไฟล์อัตโนมัติ และหลังจากไฟล์อัตโนมัตินี้ แบบจำลองของเราก็หายไป เราต้องหาสาเหตุที่เธอหายไป และนำเธอกลับมา ฟื้นฟูเธอ และเราไปที่บันทึกอีกครั้งและดูว่าทำไมเราจึงมีการฝากไฟล์อัตโนมัติ

ในกรณีนี้ แบบจำลองที่สองกลายเป็นต้นแบบ ไม่เป็นไรที่นี่

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

ในกรณีนี้ เราไม่มีบันทึกธุรกรรมและเรพพลิกาไม่สามารถเริ่มต้นได้ ดังนั้นเราจึงหยุด Postgres ด้วยข้อผิดพลาด ดังนั้นจึงไม่อยู่ในคลัสเตอร์

เราต้องเข้าใจว่าเหตุใดจึงไม่อยู่ในคลัสเตอร์และเหตุใดจึงไม่มีบันทึก เราไปหานายใหม่และดูว่าเขามีอะไรอยู่ในบันทึก ปรากฎว่าเมื่อ pg_rewind เสร็จสิ้น มีจุดตรวจสอบเกิดขึ้น และบันทึกธุรกรรมเก่าบางส่วนก็ถูกเปลี่ยนชื่อ เมื่อมาสเตอร์เก่าพยายามเชื่อมต่อกับมาสเตอร์ใหม่และค้นหาบันทึกเหล่านี้ พวกเขาถูกเปลี่ยนชื่อไปแล้ว ไม่มีอยู่จริง

ฉันเปรียบเทียบการประทับเวลาที่เหตุการณ์เหล่านี้เกิดขึ้น และมีความแตกต่างอย่างแท้จริงคือ 150 มิลลิวินาที นั่นคือ จุดตรวจสอบเสร็จสมบูรณ์ใน 369 มิลลิวินาที ส่วน WAL ถูกเปลี่ยนชื่อ และแท้จริงแล้วในปี 517 หลังจากผ่านไป 150 มิลลิวินาที การย้อนกลับก็เริ่มขึ้นในแบบจำลองเก่า นั่นคือ 150 มิลลิวินาทีก็เพียงพอแล้วสำหรับเราเพื่อให้แบบจำลองไม่สามารถเชื่อมต่อและรับได้

มีตัวเลือกอะไรบ้าง?

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

แต่มีปัญหาตรงที่ว่าเมื่อมาสเตอร์ไปที่เรพลิกา มันจะลบสล็อตและลบเซกเมนต์ WAL พร้อมกับสล็อต และเพื่อขจัดปัญหานี้ เราจึงตัดสินใจที่จะเพิ่มพารามิเตอร์ wal_keep_segments มีค่าเริ่มต้นเป็น 8 ส่วน เราเพิ่มเป็น 1 และดูว่าเรามีพื้นที่ว่างเท่าใด และเราได้บริจาค 000 กิกะไบต์สำหรับ wal_keep_segments นั่นคือเมื่อทำการเปลี่ยน เรามีบันทึกธุรกรรมสำรองไว้ 16 กิกะไบต์บนโหนดทั้งหมดเสมอ

และข้อดี - ยังคงเกี่ยวข้องกับงานบำรุงรักษาระยะยาว สมมติว่าเราต้องอัปเดตแบบจำลองหนึ่งรายการ และเราต้องการปิด เราจำเป็นต้องอัปเดตซอฟต์แวร์ อาจจะเป็นระบบปฏิบัติการ หรืออย่างอื่น และเมื่อเราปิดแบบจำลอง ช่องสำหรับแบบจำลองนั้นจะถูกเอาออกด้วย และหากเราใช้ wal_keep_segments ขนาดเล็ก หากไม่มีแบบจำลองเป็นเวลานาน บันทึกธุรกรรมก็จะสูญหายไป เราจะสร้างแบบจำลองขึ้นมา โดยจะขอบันทึกธุรกรรมเหล่านั้นเมื่อหยุดทำงาน แต่อาจไม่อยู่ในต้นแบบ และแบบจำลองจะไม่สามารถเชื่อมต่อได้เช่นกัน ดังนั้นเราจึงเก็บนิตยสารไว้เป็นจำนวนมาก

เรามีฐานการผลิต มีโครงการที่กำลังดำเนินการอยู่แล้ว

มีผู้ยื่นเอกสาร เราเข้าไปดู - ทุกอย่างเรียบร้อย แบบจำลองเข้าที่ ไม่มีการจำลองแบบล่าช้า ไม่มีข้อผิดพลาดในบันทึกเช่นกัน ทุกอย่างเป็นไปตามลำดับ

ทีมผลิตภัณฑ์บอกว่าควรมีข้อมูลบางอย่าง แต่เราดูจากแหล่งเดียว แต่ไม่เห็นในฐานข้อมูล และเราต้องเข้าใจว่าเกิดอะไรขึ้นกับพวกเขา

เห็นได้ชัดว่า pg_rewind พลาดไป เราเข้าใจสิ่งนี้ทันที แต่ไปดูว่าเกิดอะไรขึ้น

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

เจ้านายเก่าของเรารีบูตแล้ว และ Patroni ได้รับการจดทะเบียนใน autorun เปิดตัว Patroni จากนั้นเขาก็เริ่ม Postgres อย่างแม่นยำยิ่งขึ้น ก่อนเริ่ม Postgres และก่อนที่จะสร้างแบบจำลอง Patroni ได้เปิดตัวกระบวนการ pg_rewind ดังนั้น เขาจึงลบส่วนหนึ่งของบันทึกการทำธุรกรรม ดาวน์โหลดรายการใหม่และเชื่อมต่อ ที่นี่ Patroni ทำงานอย่างชาญฉลาดตามที่คาดไว้ คืนค่าคลัสเตอร์แล้ว เรามี 3 โหนดหลังจาก filer 3 โหนด - ทุกอย่างยอดเยี่ยม

เราได้สูญเสียข้อมูลบางส่วน และเราต้องเข้าใจว่าเราสูญเสียไปเท่าไร เรากำลังมองหาเพียงช่วงเวลาที่เราได้ย้อนกลับ เราสามารถหาได้จากรายการบันทึกดังกล่าว ย้อนกลับเริ่มต้นทำบางสิ่งบางอย่างที่นั่นและจบลง

เราจำเป็นต้องค้นหาตำแหน่งในบันทึกการทำธุรกรรมที่เจ้านายเก่าออกไป ในกรณีนี้นี่คือเครื่องหมาย และเราต้องการเครื่องหมายที่สองนั่นคือระยะทางที่นายเก่าแตกต่างจากนายใหม่

เราใช้ pg_wal_lsn_diff ปกติและเปรียบเทียบเครื่องหมายทั้งสองนี้ และในกรณีนี้ เราได้รับ 17 เมกะไบต์ มากหรือน้อยทุกคนตัดสินใจด้วยตัวเอง เพราะสำหรับบางคน 17 เมกะไบต์นั้นไม่มากสำหรับบางคนมันเยอะและรับไม่ได้ ที่นี่แต่ละคนกำหนดตัวเองตามความต้องการของธุรกิจ

แต่เราค้นพบอะไรด้วยตัวเราเอง?

อันดับแรก เราต้องตัดสินใจด้วยตัวเองว่าเราต้องการให้ Patroni เริ่มการทำงานอัตโนมัติหลังจากรีบูตระบบหรือไม่ บ่อยครั้งที่เราต้องไปหานายเก่าดูว่าเขาไปไกลแค่ไหน อาจตรวจสอบส่วนต่าง ๆ ของบันทึกธุรกรรม ดูว่ามีอะไรบ้าง และเพื่อทำความเข้าใจว่าเราจะสูญเสียข้อมูลนี้ไปได้หรือไม่ หรือเราต้องเรียกใช้ต้นแบบเก่าในโหมดสแตนด์อโลนเพื่อดึงข้อมูลนี้ออกมา

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

นอกจากนี้ยังมีพารามิเตอร์ "maximum_lag_on_failover" ตามค่าเริ่มต้น ถ้าหน่วยความจำของฉันให้บริการ พารามิเตอร์นี้มีค่า 1 เมกะไบต์

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

แต่มีปัญหาในความล่าช้าของการจำลองแบบในคลัสเตอร์ Patroni และ DCS ได้รับการอัปเดตในช่วงเวลาหนึ่ง ฉันคิดว่า 30 วินาทีเป็นค่า ttl เริ่มต้น

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

และความเสี่ยงที่จะสูญเสียยังคงมีอยู่เสมอ และในกรณีที่เลวร้ายที่สุด สูตรหนึ่ง และในกรณีทั่วไป อีกสูตรหนึ่ง นั่นคือ เมื่อเราวางแผนการนำ Patroni ไปใช้และประเมินว่าข้อมูลที่เราเสียไปได้มากน้อยเพียงใด เราต้องใช้สูตรเหล่านี้และจินตนาการคร่าวๆ ว่าข้อมูลที่เราเสียไปได้เท่าไร

และมีข่าวดี เมื่อเจ้านายเก่าเดินไปข้างหน้า เขาสามารถดำเนินการต่อไปได้เนื่องจากกระบวนการเบื้องหลังบางอย่าง นั่นคือมี autovacuum บางชนิด เขาเขียนข้อมูลบันทึกไว้ในบันทึกการทำธุรกรรม และเราสามารถเพิกเฉยและสูญเสียข้อมูลนี้ได้อย่างง่ายดาย ไม่มีปัญหาในเรื่องนี้

และนี่คือลักษณะของบันทึก หากตั้งค่า maximum_lag_on_failover แล้วเกิด filer และคุณต้องเลือกต้นแบบใหม่ แบบจำลองประเมินตัวเองว่าไม่สามารถมีส่วนร่วมในการเลือกตั้งได้ และเธอปฏิเสธที่จะเข้าร่วมการแข่งขันเพื่อเป็นผู้นำ และเธอรอการเลือกต้นแบบใหม่เพื่อที่เธอจะสามารถเชื่อมต่อกับมันได้ นี่เป็นมาตรการเพิ่มเติมเพื่อป้องกันข้อมูลสูญหาย

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

โฮสต์นี้ถูกบังคับให้รีบูต เนื่องจากการรีบูต ไฟล์อัตโนมัติจึงเกิดขึ้น แม้ว่ามันจะเป็นไปได้ที่จะสร้างไฟล์อัตโนมัติด้วยตัวเองก็ตาม ตอนนี้ฉันเข้าใจแล้ว และหลังจากการรีบูตเราจะเห็นสิ่งที่เรามีกับต้นแบบปัจจุบันแล้ว

ในขณะเดียวกัน เรารู้ล่วงหน้าว่าเรามีปัญหากับดิสก์ นั่นคือเรารู้แล้วจากการเฝ้าติดตามตำแหน่งที่จะขุดและสิ่งที่ต้องค้นหา

เราเข้าไปในบันทึกของ postgres เริ่มดูว่าเกิดอะไรขึ้นที่นั่น เราเห็นการคอมมิตที่คงอยู่เป็นเวลา XNUMX, XNUMX, XNUMX วินาที ซึ่งไม่ปกติเลย เราเห็นว่าเครื่องดูดฝุ่นอัตโนมัติของเราเริ่มทำงานช้าและแปลกมาก และเราเห็นไฟล์ชั่วคราวบนดิสก์ นั่นคือตัวบ่งชี้ทั้งหมดของปัญหาเกี่ยวกับดิสก์

เราตรวจสอบระบบ dmesg (บันทึกเคอร์เนล) และเราเห็นว่าเรามีปัญหากับหนึ่งในดิสก์ ระบบย่อยของดิสก์คือซอฟต์แวร์ Raid เราดูที่ /proc/mdstat และเห็นว่าเราขาดไปหนึ่งไดรฟ์ นั่นคือมี Raid 8 แผ่นเราขาดไปหนึ่งแผ่น หากคุณดูที่สไลด์อย่างระมัดระวังในผลลัพธ์คุณจะเห็นว่าเราไม่มี sde ที่นั่น ที่เราพูดอย่างมีเงื่อนไขดิสก์หลุดออกมา สิ่งนี้ทำให้เกิดปัญหาเกี่ยวกับดิสก์ และแอปพลิเคชันยังประสบปัญหาเมื่อทำงานกับคลัสเตอร์ Postgres

และในกรณีนี้ Patroni จะไม่ช่วยเรา แต่อย่างใด เนื่องจาก Patroni ไม่มีภารกิจในการตรวจสอบสถานะของเซิร์ฟเวอร์ สถานะของดิสก์ และเราต้องติดตามสถานการณ์ดังกล่าวโดยการติดตามจากภายนอก เราได้เพิ่มการตรวจสอบดิสก์ไปยังการตรวจสอบภายนอกอย่างรวดเร็ว

และมีความคิดเช่นนี้ - ซอฟต์แวร์ฟันดาบหรือสุนัขเฝ้าบ้านจะช่วยเราได้หรือไม่? เราคิดว่าเขาแทบจะไม่ช่วยเราในกรณีนี้เลย เพราะในระหว่างที่เกิดปัญหา Patroni ยังคงโต้ตอบกับคลัสเตอร์ DCS และไม่เห็นปัญหาใดๆ นั่นคือจากมุมมองของ DCS และ Patroni ทุกอย่างเรียบร้อยดีกับคลัสเตอร์แม้ว่าในความเป็นจริงจะมีปัญหากับดิสก์ แต่มีปัญหาเกี่ยวกับความพร้อมใช้งานของฐานข้อมูล

ในความคิดของฉัน นี่เป็นหนึ่งในปัญหาที่แปลกประหลาดที่สุดที่ฉันค้นคว้ามาเป็นเวลานาน ฉันได้อ่านบันทึกจำนวนมาก เลือกใหม่และเรียกมันว่าตัวจำลองคลัสเตอร์

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

และมันเริ่มต้นอย่างไร? มันเริ่มต้นด้วยปัญหาก่อนหน้านี้ด้วยดิสก์เบรก เรามีความมุ่งมั่นสำหรับวินาทีที่สอง

มีการแตกหักของการเชื่อมต่อ เช่น ลูกค้าขาดการติดต่อ

มีการอุดตันที่มีความรุนแรงต่างกัน

ดังนั้นระบบย่อยของดิสก์จึงไม่ตอบสนองมากนัก

และสิ่งที่ลึกลับที่สุดสำหรับฉันก็คือคำขอปิดระบบในทันทีที่มาถึง Postgres มีโหมดปิดสามโหมด:

• เป็นเรื่องดีเมื่อเรารอให้ไคลเอ็นต์ทั้งหมดตัดการเชื่อมต่อด้วยตัวเอง
• มีความรวดเร็วเมื่อเราบังคับให้ลูกค้าตัดการเชื่อมต่อเนื่องจากเรากำลังจะปิดระบบ
• และในทันที ในกรณีนี้ ทันทีไม่ได้บอกลูกค้าให้ปิดเครื่อง มันแค่ปิดโดยไม่มีการเตือนล่วงหน้า และไปยังไคลเอนต์ทั้งหมด ระบบปฏิบัติการได้ส่งข้อความ RST แล้ว (ข้อความ TCP ที่การเชื่อมต่อถูกขัดจังหวะ และไคลเอ็นต์ไม่มีอะไรให้จับอีกต่อไป)

ใครเป็นคนส่งสัญญาณนี้? กระบวนการพื้นหลังของ Postgres จะไม่ส่งสัญญาณดังกล่าวให้กันและกัน นั่นคือ นี่คือ kill-9 พวกเขาไม่ได้ส่งสิ่งเหล่านี้ให้กันและกัน แต่จะตอบสนองต่อสิ่งนั้นเท่านั้น เช่น นี่คือการรีสตาร์ท Postgres ในกรณีฉุกเฉิน ใครส่งมาก็ไม่รู้

ฉันดูที่คำสั่ง "สุดท้าย" และฉันเห็นคนหนึ่งที่เข้าสู่ระบบเซิร์ฟเวอร์นี้กับเราด้วย แต่ฉันก็อายเกินกว่าจะถามคำถาม บางทีมันอาจจะเป็นคิล -9 ฉันจะเห็น kill -9 ในบันทึกเพราะ Postgres บอกว่าต้องใช้ kill -9 แต่ฉันไม่เห็นมันในบันทึก

เมื่อมองต่อไปฉันเห็นว่า Patroni ไม่ได้เขียนบันทึกเป็นเวลานาน - 54 วินาที และถ้าเราเปรียบเทียบการประทับเวลาสองครั้ง จะไม่มีข้อความใดๆ ประมาณ 54 วินาที

และในช่วงเวลานี้มีไฟล์อัตโนมัติ Patroni ทำผลงานได้ดีที่นี่อีกครั้ง นายเก่าของเราไม่ว่าง มีบางอย่างเกิดขึ้นกับเขา และการเลือกตั้งนายใหม่ก็เริ่มขึ้น ทุกอย่างทำงานได้ดีที่นี่ pgsql01 ของเราได้กลายเป็นผู้นำคนใหม่

เรามีแบบจำลองที่ได้กลายเป็นต้นแบบ และมีคำตอบที่สอง และมีปัญหากับแบบจำลองที่สอง เธอพยายามที่จะกำหนดค่าใหม่ ตามที่ฉันเข้าใจ เธอพยายามเปลี่ยน recovery.conf รีสตาร์ท Postgres และเชื่อมต่อกับต้นแบบใหม่ เธอเขียนข้อความทุก ๆ 10 วินาทีที่เธอพยายาม แต่ก็ไม่สำเร็จ

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

เมื่อถึงจุดหนึ่ง มันใช้งานได้ แต่การจำลองแบบไม่ได้เริ่มขึ้น

สิ่งเดียวที่ฉันเดาคือมีที่อยู่หลักเก่าใน recovery.conf และเมื่อต้นแบบใหม่ปรากฏขึ้น แบบจำลองที่สองยังคงพยายามเชื่อมต่อกับต้นแบบเก่า

เมื่อ Patroni เริ่มทำงานในแบบจำลองที่สอง โหนดจะเริ่มต้นขึ้นแต่ไม่สามารถทำซ้ำได้ และเกิด replication lag ซึ่งมีลักษณะดังนี้ นั่นคือทั้งสามโหนดอยู่ในตำแหน่ง แต่โหนดที่สองล้าหลัง

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

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

หลังจากผ่านไป 30 นาที ผู้ดูแลระบบก็มา เช่น ฉันรีสตาร์ท Patroni บนแบบจำลอง หมดสิ้นไปแล้วคิดว่าคงต้องเติม และฉันคิดว่า - ฉันจะเริ่มต้น Patroni ใหม่ อาจจะมีสิ่งดีๆ เกิดขึ้น เริ่มการกู้คืนแล้ว และแม้แต่ฐานก็เปิดออก มันพร้อมที่จะรับการเชื่อมต่อ

การจำลองแบบเริ่มต้นขึ้นแล้ว แต่หนึ่งนาทีต่อมาเธอก็ตกลงด้วยข้อผิดพลาดว่าบันทึกการทำธุรกรรมไม่เหมาะกับเธอ

ฉันคิดว่าฉันจะเริ่มใหม่อีกครั้ง ฉันรีสตาร์ท Patroni อีกครั้ง และไม่ได้รีสตาร์ท Postgres แต่รีสตาร์ท Patroni ด้วยความหวังว่าระบบจะเริ่มต้นฐานข้อมูลอย่างน่าอัศจรรย์

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

แล้วมันเกิดขึ้นกับฉัน - จะเกิดอะไรขึ้นถ้าฉันรีสตาร์ท Postgres ในเวลานี้ฉันสร้างจุดตรวจบนต้นแบบปัจจุบันเพื่อย้ายจุดในบันทึกธุรกรรมไปข้างหน้าเล็กน้อยเพื่อให้การกู้คืนเริ่มต้นจากช่วงเวลาอื่น นอกจากนี้เรายังมีหุ้นของ WAL

ฉันรีสตาร์ท Patroni ทำสองจุดตรวจบนมาสเตอร์ จุดรีสตาร์ทสองจุดบนแบบจำลองเมื่อเปิด และมันก็ช่วยได้ ฉันคิดอยู่นานว่าทำไมมันถึงช่วยได้และมันทำงานอย่างไร และแบบจำลองก็เริ่มขึ้น และการจำลองแบบไม่ได้ขาดอีกต่อไป

ปัญหาดังกล่าวสำหรับฉันเป็นปัญหาที่ลึกลับมากปัญหาหนึ่งซึ่งฉันยังคงสงสัยว่าเกิดอะไรขึ้นที่นั่น

ความหมายที่นี่คืออะไร? Patroni สามารถทำงานได้ตามที่ตั้งใจไว้และไม่มีข้อผิดพลาดใดๆ แต่ในเวลาเดียวกันนี่ไม่ใช่การรับประกัน 100% ว่าทุกอย่างเรียบร้อยดีสำหรับเรา แบบจำลองอาจเริ่มทำงาน แต่อาจอยู่ในสถานะกึ่งทำงาน และแอปพลิเคชันไม่สามารถทำงานกับแบบจำลองดังกล่าวได้ เนื่องจากจะมีข้อมูลเก่า

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

และในขณะที่เราจัดการกับปัญหาเหล่านี้ ผมจะให้คำแนะนำ ฉันพยายามรวมเข้าด้วยกันเป็นสองสไลด์ อาจเป็นไปได้ว่าเรื่องราวทั้งหมดสามารถรวมกันเป็นสองสไลด์และบอกเล่าได้เท่านั้น

เมื่อคุณใช้ Patroni คุณต้องมีการตรวจสอบ คุณควรทราบเสมอเมื่อเกิด autofileover เพราะถ้าคุณไม่รู้ว่าคุณมี autofileover คุณจะไม่สามารถควบคุมคลัสเตอร์ได้ และนั่นก็แย่

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

ระบบอัตโนมัติสามารถทำงานได้สำเร็จ Patroni เป็นเครื่องมือที่ดีมาก สามารถทำงานได้ แต่จะไม่นำคลัสเตอร์ไปสู่สถานะที่ต้องการ และถ้าเราไม่ทราบ เราจะมีปัญหา

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

ฉันจะแก้ไขปัญหาการวินิจฉัยได้อย่างไร มันเกิดขึ้นที่เราทำงานกับไคลเอนต์ที่แตกต่างกันและไม่มีใครมี ELK stack และเราต้องจัดเรียงบันทึกโดยเปิด 6 คอนโซลและ 2 แท็บ ในแท็บหนึ่ง แท็บเหล่านี้คือบันทึกของ Patroni สำหรับแต่ละโหนด ส่วนอีกแท็บหนึ่งคือบันทึกของกงสุล หรือ Postgres หากจำเป็น เป็นการยากที่จะวินิจฉัยสิ่งนี้

ฉันได้ใช้วิธีใด? อันดับแรก ฉันมักจะดูเสมอว่าไฟล์มาถึงเมื่อไหร่ และสำหรับฉันนี่คือต้นน้ำ ฉันดูว่าเกิดอะไรขึ้นก่อนคนทำไฟล์ ระหว่างคนทำไฟล์ และหลังคนทำไฟล์ fileover มีเครื่องหมายสองอัน: นี่คือเวลาเริ่มต้นและเวลาสิ้นสุด

ต่อไป ฉันจะค้นหาเหตุการณ์ก่อนไฟล์เดอร์ในบันทึก ซึ่งนำหน้าไฟล์เดอร์ นั่นคือ ฉันมองหาสาเหตุที่ไฟล์เดอร์เกิดขึ้น

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

และเรามักจะดูที่ไหน? ฉันมอง:

• ประการแรก ในบันทึกของผู้อุปถัมภ์
• ต่อไป ฉันดูที่บันทึกของ Postgres หรือบันทึกของ DCS ขึ้นอยู่กับสิ่งที่พบในบันทึกของ Patroni
• และบางครั้งบันทึกของระบบยังช่วยให้เข้าใจว่าอะไรเป็นสาเหตุของ filer

ฉันรู้สึกอย่างไรเกี่ยวกับ Patroni ฉันมีความสัมพันธ์ที่ดีกับ Patroni ในความคิดของฉัน นี่คือสิ่งที่ดีที่สุดในปัจจุบัน ฉันรู้จักผลิตภัณฑ์อื่น ๆ อีกมากมาย ได้แก่ Stolon, Repmgr, Pg_auto_failover, PAF 4 เครื่องมือ ฉันพยายามทั้งหมด Patroni เป็นที่ชื่นชอบ

หากพวกเขาถามฉัน: "ฉันแนะนำ Patroni หรือไม่" ฉันจะตอบว่าใช่ เพราะฉันชอบ Patroni และฉันคิดว่าฉันได้เรียนรู้วิธีทำอาหาร

หากคุณสนใจที่จะดูว่า Patroni มีปัญหาอะไรอีกบ้างนอกเหนือจากปัญหาที่ฉันกล่าวถึง คุณสามารถดูหน้านี้ได้ตลอดเวลา ปัญหา บน GitHub มีเรื่องราวต่างๆ มากมาย และประเด็นที่น่าสนใจมากมายถูกกล่าวถึงที่นั่น และด้วยเหตุนี้จึงมีการแนะนำและแก้ไขข้อบกพร่องบางอย่างนั่นคือนี่คือการอ่านที่น่าสนใจ

มีเรื่องราวที่น่าสนใจเกี่ยวกับคนที่ยิงตัวเองที่เท้า ข้อมูลมาก คุณอ่านและเข้าใจว่าไม่จำเป็นต้องทำเช่นนั้น ฉันติ๊กเอง

และฉันอยากจะขอบคุณ Zalando อย่างมากสำหรับการพัฒนาโครงการนี้ ได้แก่ Alexander Kukushkin และ Alexey Klyukin Aleksey Klyukin เป็นหนึ่งในผู้เขียนร่วม เขาไม่ได้ทำงานที่ Zalando อีกต่อไป แต่คนสองคนนี้เริ่มทำงานกับผลิตภัณฑ์นี้

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

นั่นคือทั้งหมด หากคุณมีคำถามให้ถาม

คำถาม

ขอบคุณสำหรับรายงาน! หากหลังจากเก็บไฟล์แล้วคุณยังต้องดูอย่างระมัดระวัง แล้วทำไมเราต้องใช้ไฟล์เก็บเอกสารอัตโนมัติ

เพราะเป็นของใหม่ เราอยู่กับเธอแค่ปีเดียว ดีกว่าที่จะปลอดภัย เราต้องการเข้ามาและเห็นว่าทุกอย่างเป็นไปอย่างที่ควรจะเป็น นี่คือระดับความไม่ไว้วางใจของผู้ใหญ่ - เป็นการดีกว่าที่จะตรวจสอบและดูอีกครั้ง

เช่นเราไปตอนเช้าแล้วดูใช่ไหม?

ไม่ใช่ในตอนเช้าเรามักจะเรียนรู้เกี่ยวกับไฟล์อัตโนมัติเกือบจะในทันที เราได้รับการแจ้งเตือน เราเห็นว่ามีไฟล์อัตโนมัติเกิดขึ้น เราเกือบจะไปดูทันที แต่ควรนำการตรวจสอบทั้งหมดเหล่านี้ไปสู่ระดับการตรวจสอบ หากคุณเข้าถึง Patroni ผ่าน REST API แสดงว่ามีประวัติ ตามประวัติ คุณสามารถดูการประทับเวลาเมื่อไฟล์เกิดขึ้น จากนี้สามารถตรวจสอบได้ สามารถดูประวัติว่ามีกี่เหตุการณ์ หากเรามีเหตุการณ์มากกว่านี้ แสดงว่ามีไฟล์อัตโนมัติเกิดขึ้น คุณสามารถไปดู หรือการตรวจสอบอัตโนมัติของเราได้ตรวจสอบว่าเรามีแบบจำลองทั้งหมดแล้ว ไม่มีความล่าช้าและทุกอย่างเรียบร้อยดี

ขอบคุณ!

ขอบคุณมากสำหรับเรื่องราวดีๆ! หากเราย้ายคลัสเตอร์ DCS ไปที่ไหนไกลจากคลัสเตอร์ Postgres คลัสเตอร์นี้จำเป็นต้องได้รับการบริการเป็นระยะด้วยหรือไม่ แนวปฏิบัติที่ดีที่สุดใดบ้างที่จำเป็นต้องปิดการทำงานของคลัสเตอร์ DCS บางชิ้น สิ่งที่ต้องทำกับสิ่งเหล่านี้ ฯลฯ โครงสร้างทั้งหมดนี้อยู่รอดได้อย่างไร? และคุณทำสิ่งเหล่านี้ได้อย่างไร?

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

นั่นคือฉันเข้าใจถูกต้องหรือไม่ว่าฉันต้องปิดใช้งาน Patroni ปิดใช้งาน filer ปิดใช้งานทุกอย่างก่อนที่จะทำอะไรกับโฮสต์

ขึ้นอยู่กับจำนวนโหนดที่เรามีในคลัสเตอร์ DCS หากมีหลายโหนดและหากเราปิดใช้งานเพียงโหนดเดียว (ตัวจำลอง) คลัสเตอร์จะคงองค์ประชุมไว้ และ Patroni ยังคงใช้งานได้ และไม่มีอะไรเกิดขึ้น หากเรามีการดำเนินการที่ซับซ้อนซึ่งส่งผลกระทบต่อโหนดต่างๆ มากขึ้น การไม่มีการดำเนินการดังกล่าวสามารถทำลายองค์ประชุมได้ ดังนั้น ใช่ การหยุด Patroni ชั่วคราวอาจสมเหตุสมผล มีคำสั่งที่สอดคล้องกัน - หยุดชั่วคราวผู้อุปถัมภ์, ดำเนินการต่อผู้อุปถัมภ์ เราเพียงแค่หยุดชั่วคราวและโปรแกรมกรองอัตโนมัติไม่ทำงานในขณะนั้น เราทำการบำรุงรักษาคลัสเตอร์ DCS จากนั้นหยุดชั่วคราวและใช้งานต่อไป

ขอบคุณมาก!

ขอบคุณมากสำหรับรายงานของคุณ! ทีมผลิตภัณฑ์รู้สึกอย่างไรเกี่ยวกับข้อมูลสูญหาย

ทีมผลิตภัณฑ์ไม่สนใจ และหัวหน้าทีมก็กังวล

มีการรับประกันอะไรบ้าง?

ค้ำประกันได้ยากมาก Alexander Kukushkin มีรายงาน "วิธีคำนวณ RPO และ RTO" เช่น เวลากู้คืนและข้อมูลที่เราเสียไปได้ ฉันคิดว่าเราต้องหาสไลด์เหล่านี้และศึกษามัน เท่าที่ฉันจำได้มีขั้นตอนเฉพาะในการคำนวณสิ่งเหล่านี้ จำนวนธุรกรรมที่เราสามารถสูญเสีย ข้อมูลที่เราสูญเสียได้ เราสามารถใช้การจำลองแบบซิงโครนัสที่ระดับ Patroni ได้ แต่นี่เป็นดาบสองคม: เราอาจมีความเชื่อถือได้ของข้อมูล หรือไม่ก็สูญเสียความเร็ว มีการจำลองแบบแบบซิงโครนัส แต่ก็ไม่รับประกันการป้องกันข้อมูลสูญหาย 100%

Alexey ขอบคุณสำหรับรายงานที่ยอดเยี่ยม! มีประสบการณ์ในการใช้ Patroni สำหรับการป้องกันระดับศูนย์หรือไม่? นั่นคือร่วมกับสแตนด์บายแบบซิงโครนัส? นี่เป็นคำถามแรก และคำถามที่สอง คุณใช้วิธีแก้ไขปัญหาต่างๆ เราใช้ Repmgr แต่ไม่มี autofiler และตอนนี้เรากำลังวางแผนที่จะรวม autofiler และเราถือว่า Patroni เป็นอีกทางเลือกหนึ่ง คุณสามารถพูดอะไรที่เป็นข้อได้เปรียบเมื่อเทียบกับ Repmgr?

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

สำหรับคำถามที่สอง เราใช้ Repmgr และยังคงทำกับลูกค้าบางรายด้วยเหตุผลทางประวัติศาสตร์ สามารถพูดอะไรได้บ้าง? Patroni มาพร้อมกับตัวกรองอัตโนมัติที่แกะกล่อง Repmgr มาพร้อมกับตัวกรองอัตโนมัติเป็นคุณสมบัติเพิ่มเติมที่ต้องเปิดใช้งาน เราจำเป็นต้องเรียกใช้ Repmgr daemon ในแต่ละโหนด จากนั้นจึงกำหนดค่า autofiler ได้

Repmgr ตรวจสอบว่าโหนด Postgres ยังมีชีวิตอยู่หรือไม่ กระบวนการ Repmgr ตรวจสอบการมีอยู่ของกันและกัน นี่ไม่ใช่วิธีที่มีประสิทธิภาพมากนัก อาจมีกรณีที่ซับซ้อนของการแยกเครือข่าย ซึ่งคลัสเตอร์ Repmgr ขนาดใหญ่สามารถแตกออกเป็นหลายอันที่เล็กกว่าและทำงานต่อไปได้ ฉันไม่ได้ติดตาม Repmgr มานาน อาจจะได้รับการแก้ไข ... หรืออาจจะไม่ แต่การลบข้อมูลเกี่ยวกับสถานะของคลัสเตอร์ใน DCS เช่นเดียวกับที่ Stolon, Patroni ทำนั้นเป็นตัวเลือกที่ได้ผลที่สุด

อเล็กเซย์ ฉันมีคำถาม บางทีอาจจะเป็นคนที่โง่กว่า ในหนึ่งในตัวอย่างแรก คุณได้ย้าย DCS จากเครื่องโลคัลไปยังรีโมตโฮสต์ เราเข้าใจดีว่าเครือข่ายเป็นสิ่งที่มีลักษณะเฉพาะของมันเอง และจะเกิดอะไรขึ้นหากคลัสเตอร์ DCS ไม่พร้อมใช้งานด้วยเหตุผลบางอย่าง ฉันจะไม่พูดเหตุผล อาจมีมากมาย: จากมือที่คดเคี้ยวของนักเครือข่ายไปจนถึงปัญหาที่แท้จริง

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

พูดประมาณว่า DCS กลายเป็นบริการที่สำคัญสำหรับเราพอๆ กับตัวฐาน?

ใช่ ๆ. ในบริษัทสมัยใหม่หลายแห่ง Service Discovery เป็นส่วนสำคัญของโครงสร้างพื้นฐาน มีการใช้งานก่อนที่จะมีฐานข้อมูลในโครงสร้างพื้นฐานเสียด้วยซ้ำ กล่าวคือ โครงสร้างพื้นฐานได้รับการเปิดตัว ใช้งานใน DC และเรามี Service Discovery ในทันที หากเป็นกงสุลก็สามารถสร้าง DNS ได้ หากนี่คือ Etcd แสดงว่าอาจมีบางส่วนจากคลัสเตอร์ Kubernetes ซึ่งทุกอย่างจะถูกปรับใช้ สำหรับฉันแล้ว ดูเหมือนว่า Service Discovery จะเป็นส่วนสำคัญของโครงสร้างพื้นฐานสมัยใหม่อยู่แล้ว และพวกเขาคิดถึงมันเร็วกว่าฐานข้อมูลมาก

ขอบคุณ!

ที่มา: will.com