ในการพูดคุยของเขา Andrey Borodin จะบอกคุณว่าพวกเขาคำนึงถึงประสบการณ์ของการปรับขนาด PgBouncer อย่างไรเมื่อออกแบบเครื่องมือรวบรวมการเชื่อมต่อ วิธีการที่พวกเขาเปิดตัวในการผลิต นอกจากนี้ เราจะหารือเกี่ยวกับฟังก์ชันของ Pooler ที่เราต้องการเห็นในเวอร์ชันใหม่: สิ่งสำคัญสำหรับเราไม่เพียงแต่ต้องครอบคลุมความต้องการของเราเท่านั้น แต่ยังต้องพัฒนาชุมชนผู้ใช้ด้วย .
วิดีโอ:
สวัสดีทุกคน! ฉันชื่อแอนดรู
ที่ Yandex ฉันกำลังพัฒนาฐานข้อมูลโอเพ่นซอร์ส และวันนี้เรามีหัวข้อเกี่ยวกับการเชื่อมต่อพูลเกอร์การเชื่อมต่อ
หากคุณรู้วิธีโทรหาโปรแกรมสร้างการเชื่อมต่อในภาษารัสเซีย บอกฉันที ฉันต้องการหาคำศัพท์ทางเทคนิคที่ดีซึ่งควรจัดทำขึ้นในเอกสารทางเทคนิค
หัวข้อนี้ค่อนข้างซับซ้อน เนื่องจากในหลายๆ ฐานข้อมูล ตัวพูลเลอร์การเชื่อมต่อมีอยู่แล้วในตัว และคุณไม่จำเป็นต้องรู้ด้วยซ้ำ แน่นอนว่าการตั้งค่าบางอย่างมีอยู่ทั่วไป แต่ใน Postgres สิ่งนี้ใช้ไม่ได้ และในแบบคู่ขนาน (ที่ HighLoad++ 2019) มีรายงานโดย Nikolai Samokhvalov เกี่ยวกับการตั้งค่าการสืบค้นใน Postgres และฉันเข้าใจว่าผู้คนมาที่นี่ซึ่งได้กำหนดค่าคำขออย่างสมบูรณ์แล้ว และนี่คือคนที่ประสบปัญหาระบบที่หายากกว่าที่เกี่ยวข้องกับเครือข่าย การใช้ทรัพยากร และในบางแห่งอาจค่อนข้างยากในแง่ที่ว่าปัญหาไม่ชัดเจน
ยานเดกซ์มี Postgres บริการ Yandex จำนวนมากอยู่ใน Yandex.Cloud และเรามีข้อมูลหลายเพตะไบต์ที่สร้างคำขออย่างน้อยล้านครั้งต่อวินาทีใน Postgres
และเราจัดเตรียมคลัสเตอร์ทั่วไปสำหรับบริการทั้งหมด - นี่คือโหนดหลักหลักของโหนด, แบบจำลองสองแบบปกติ (ซิงโครนัสและอะซิงโครนัส), การสำรองข้อมูล, การปรับขนาดคำขออ่านบนแบบจำลอง
แต่ละโหนดของคลัสเตอร์คือ Postgres ซึ่งนอกเหนือจาก Postgres และระบบการตรวจสอบแล้ว ยังติดตั้งพูลเกอร์การเชื่อมต่ออีกด้วย Connection pooler ใช้สำหรับการฟันดาบและเพื่อวัตถุประสงค์หลัก
จุดประสงค์หลักของการเชื่อมต่อพูลเลอร์คืออะไร?
Postgres ใช้รูปแบบกระบวนการสำหรับการทำงานกับฐานข้อมูล ซึ่งหมายความว่าหนึ่งการเชื่อมต่อคือหนึ่งกระบวนการ หนึ่งแบ็กเอนด์ของ Postgres และมีแคชที่แตกต่างกันจำนวนมากในแบ็กเอนด์นี้ ซึ่งค่อนข้างแพงในการสร้างความแตกต่างสำหรับการเชื่อมต่อที่แตกต่างกัน
นอกจากนี้ยังมีอาร์เรย์ในรหัส Postgres ที่เรียกว่า procArray ประกอบด้วยข้อมูลพื้นฐานเกี่ยวกับการเชื่อมต่อเครือข่าย และอัลกอริธึมการประมวลผล procArray เกือบทั้งหมดมีความซับซ้อนเชิงเส้น โดยทำงานผ่านการเชื่อมต่อเครือข่ายทั้งหมด เป็นวัฏจักรที่ค่อนข้างเร็ว แต่ด้วยการเชื่อมต่อเครือข่ายที่เข้ามามากขึ้น สิ่งต่างๆ จึงมีราคาแพงขึ้นเล็กน้อย และเมื่อสิ่งต่าง ๆ มีราคาแพงขึ้นเล็กน้อย คุณก็จะต้องจ่ายในราคาที่สูงมากสำหรับการเชื่อมต่อเครือข่ายจำนวนมาก
มี 3 แนวทางที่เป็นไปได้:
- ด้านแอพพลิเคชั่น.
- ทางด้านฐานข้อมูล.
- และระหว่างนั่นคือชุดค่าผสมที่เป็นไปได้ทั้งหมด
น่าเสียดายที่ตัวพูลในตัวอยู่ในระหว่างการพัฒนา เพื่อนที่ PostgreSQL Professional ทำสิ่งนี้เป็นส่วนใหญ่ จะปรากฏเมื่อใดนั้นยากที่จะคาดเดาได้ และในความเป็นจริง เรามีทางออก XNUMX ทางสำหรับทางเลือกของสถาปนิก เหล่านี้คือพูลฝั่งแอปพลิเคชันและพูลพร็อกซี
Application-side pool เป็นวิธีที่ง่ายที่สุด และไดรเวอร์ไคลเอนต์เกือบทั้งหมดมีวิธี: เพื่อแสดงการเชื่อมต่อนับล้านของคุณในโค้ดเป็นการเชื่อมต่อหลายสิบรายการไปยังฐานข้อมูล
มีปัญหากับความจริงที่ว่าเมื่อถึงจุดหนึ่งที่คุณต้องการปรับขนาดแบ็กเอนด์ คุณต้องการปรับใช้กับเครื่องเสมือนหลายเครื่อง
จากนั้นคุณก็ยังรู้ว่าคุณมี Availability Zone เพิ่มขึ้นอีกหลายแห่ง มีศูนย์ข้อมูลหลายแห่ง และวิธีการรวมฝั่งไคลเอ็นต์นำไปสู่ตัวเลขจำนวนมาก ขนาดใหญ่มีการเชื่อมต่อประมาณ 10 ครั้ง นี่คือขอบที่สามารถทำงานได้ดี
หากเราพูดถึงพร็อกซีพูลเกอร์ ก็มีพูลเกอร์สองคนที่สามารถทำสิ่งต่างๆ ได้มากมาย พวกเขาไม่ได้เป็นเพียงนักเล่นพูลเท่านั้น พวกมันคือพูลเกอร์ + ฟังก์ชั่นเจ๋ง ๆ นี้ и .
แต่น่าเสียดายที่ไม่ใช่ทุกคนที่ต้องการฟังก์ชันเพิ่มเติมนี้ และนำไปสู่ข้อเท็จจริงที่ว่า poolers สนับสนุนเฉพาะการรวมเซสชัน เช่น ลูกค้าขาเข้าหนึ่งราย ลูกค้าขาออกหนึ่งรายไปยังฐานข้อมูล
สิ่งนี้ไม่เหมาะกับงานของเรา เราจึงใช้ PgBouncer ซึ่งใช้การรวมธุรกรรม เช่น การเชื่อมต่อเซิร์ฟเวอร์จะถูกแมปกับการเชื่อมต่อไคลเอ็นต์เฉพาะในช่วงระยะเวลาของการทำธุรกรรม
และในการโหลดของเรา - มันเป็นเรื่องจริง แต่มีปัญหาหลายประการ.
ปัญหาเริ่มต้นเมื่อคุณต้องการวิเคราะห์เซสชัน เนื่องจากการเชื่อมต่อขาเข้าทั้งหมดเป็นแบบโลคัล ทุกคนมาพร้อมกับลูปแบ็คและการติดตามเซสชันก็เป็นเรื่องยาก
แน่นอน คุณสามารถใช้ application_name_add_host นี่คือวิธีการเพิ่มที่อยู่ IP ของ Bouncer ใน application_name แต่ application_name ถูกตั้งค่าโดยการเชื่อมต่อเพิ่มเติม
ในแผนภูมินี้ เส้นสีเหลืองคือคำขอจริง และเส้นสีน้ำเงินคือคำขอที่ส่งไปยังฐานข้อมูล และความแตกต่างนี้คือการตั้งค่าของ application_name ซึ่งจำเป็นสำหรับการติดตามเท่านั้น แต่ก็ไม่ฟรีเลย
นอกจากนี้ Bouncer ไม่สามารถจำกัดหนึ่งพูล เช่น จำนวนการเชื่อมต่อฐานข้อมูลต่อผู้ใช้ ต่อฐานข้อมูล
สิ่งนี้นำไปสู่อะไร? คุณมีบริการโหลดที่เขียนด้วย C ++ และบริการเล็ก ๆ ใกล้เคียงบนโหนดที่ไม่ได้ทำอะไรผิดกับฐาน แต่ไดรเวอร์ของมันบ้าไปแล้ว มันเปิด 20 การเชื่อมต่อและทุกอย่างจะรอ แม้แต่รหัสของคุณก็ถูกต้อง
แน่นอน เราได้เขียนแพตช์เล็กๆ สำหรับ Bouncer ที่เพิ่มการตั้งค่านี้ เช่น การจำกัดไคลเอ็นต์ในพูล
สามารถทำได้ในฝั่ง Postgres เช่น จำกัดบทบาทในฐานข้อมูลตามจำนวนการเชื่อมต่อ
แต่คุณสูญเสียความสามารถในการเข้าใจสาเหตุที่คุณไม่มีการเชื่อมต่อกับเซิร์ฟเวอร์ PgBouncer ไม่แสดงข้อผิดพลาดในการเชื่อมต่อ แต่จะส่งคืนข้อมูลเดิมเสมอ และคุณไม่สามารถเข้าใจได้: รหัสผ่านของคุณอาจเปลี่ยนไป ฐานข้อมูลอาจล่ม หรืออาจมีบางอย่างผิดปกติ แต่ไม่มีการวินิจฉัย หากไม่สามารถสร้างเซสชันได้ คุณจะไม่รู้ว่าเหตุใดจึงไม่สามารถทำได้
เมื่อถึงจุดหนึ่ง คุณดูกราฟของแอปพลิเคชันและเห็นว่าแอปพลิเคชันไม่ทำงาน
ดูที่ด้านบนและเห็นว่า Bouncer เป็นเธรดเดียว นี่คือจุดเปลี่ยนของชีวิตการรับราชการ คุณเข้าใจว่าคุณกำลังเตรียมปรับขนาดฐานข้อมูลในหนึ่งปีครึ่ง และคุณจำเป็นต้องปรับขนาดตัวรวบรวม
เราได้ข้อสรุปแล้วว่าเราต้องการ PgBouncers เพิ่ม
Bouncer ได้รับการแก้ไขเล็กน้อย
และพวกเขาสร้างมันขึ้นมาเพื่อให้สามารถยก Bouncer ได้หลายตัวด้วยการใช้พอร์ต TCP ซ้ำ และระบบปฏิบัติการได้ถ่ายโอนการเชื่อมต่อ TCP ขาเข้าระหว่างกันโดยอัตโนมัติโดยวิธี Round-robin'om
สิ่งนี้มีความโปร่งใสสำหรับลูกค้า เช่น ดูเหมือนว่าคุณมี Bouncer หนึ่งตัว แต่คุณมีส่วนเชื่อมต่อที่ไม่ได้ใช้งานระหว่าง Bouncer ที่ทำงานอยู่
และเมื่อถึงจุดหนึ่ง คุณอาจสังเกตเห็นว่า Bouncer ทั้ง 3 ตัวนี้กินแกนของพวกมันไป 100% คุณต้องมี Bouncers ค่อนข้างน้อย ทำไม
เพราะคุณมี TLS คุณมีการเชื่อมต่อที่เข้ารหัส และหากคุณเปรียบเทียบ Postgres ที่มีและไม่มี TLS คุณจะพบว่าจำนวนการเชื่อมต่อที่สร้างไว้ลดลงเกือบสองลำดับความสำคัญเมื่อเปิดใช้งานการเข้ารหัส เนื่องจากการจับมือ TLS ใช้ทรัพยากร CPU
และที่ด้านบน คุณจะเห็นฟังก์ชันการเข้ารหัสบางอย่างที่ดำเนินการระหว่างคลื่นของการเชื่อมต่อที่เข้ามา เนื่องจากอุปกรณ์หลักของเราสามารถสลับไปมาระหว่างโซนความพร้อมใช้งาน คลื่นของการเชื่อมต่อที่เข้ามาจึงเป็นสถานการณ์ที่ค่อนข้างปกติ นั่นคือด้วยเหตุผลบางอย่าง หลักเก่าไม่พร้อมใช้งาน โหลดทั้งหมดถูกส่งไปยังศูนย์ข้อมูลอื่น พวกเขาทั้งหมดจะมาทักทาย TLS พร้อมกัน
และการจับมือของ TLS จำนวนมากอาจไม่ทักทาย Bouncer แล้ว แต่บีบคอของเขา เวฟของการเชื่อมต่อขาเข้าอาจไม่รองรับเนื่องจากการหมดเวลา หากคุณพยายามกลับไปที่ฐานโดยไม่มีการถอยกลับแบบเอกซ์โปเนนเชียล พวกมันจะไม่กลับมาซ้ำแล้วซ้ำอีกในคลื่นที่สอดคล้องกัน
นี่คือตัวอย่างของ PgBouncers 16 ตัวที่โหลด 16 คอร์ที่ 100%
เรามาถึง PgBouncer ที่ลดหลั่นกันแล้ว นี่คือการกำหนดค่าที่ดีที่สุดที่เราสามารถทำได้ในการโหลด Bouncer Bouncer ภายนอกของเราทำหน้าที่สำหรับการจับมือ TCP และ Bouncer ภายในทำหน้าที่สำหรับการรวมจริง เพื่อไม่ให้การเชื่อมต่อภายนอกแตกแยกอย่างมาก
ในการกำหนดค่านี้ การรีสตาร์ทแบบซอฟต์เป็นไปได้ คุณสามารถรีสตาร์ท Bouncer ทั้ง 18 ตัวเหล่านี้ทีละตัว แต่การรักษาการกำหนดค่าดังกล่าวนั้นค่อนข้างยาก ผู้ดูแลระบบ DevOps และผู้ที่รับผิดชอบเซิร์ฟเวอร์นี้จริง ๆ จะไม่พอใจกับแผนการนี้มากนัก
ดูเหมือนว่าการปรับปรุงทั้งหมดของเราสามารถส่งเสริมในโอเพ่นซอร์สได้ แต่ Bouncer นั้นรองรับได้ไม่ดีนัก ตัวอย่างเช่น ความสามารถในการเรียกใช้ PgBouncers หลายตัวบนพอร์ตเดียวกันเกิดขึ้นเมื่อเดือนที่แล้ว คำขอดึงคุณลักษณะนี้เกิดขึ้นเมื่อไม่กี่ปีที่ผ่านมา
หรืออีกหนึ่งตัวอย่าง ใน Postgres คุณสามารถยกเลิกคำขอที่ทำงานอยู่ได้โดยส่งความลับไปยังการเชื่อมต่ออื่นโดยไม่ต้องมีการตรวจสอบสิทธิ์เพิ่มเติม แต่ไคลเอนต์บางตัวเพียงแค่ส่งการรีเซ็ต TCP เช่น พวกเขาหยุดการเชื่อมต่อเครือข่าย Bouncer จะทำอย่างไรกับสิ่งนี้? เขาจะไม่ทำอะไร จะดำเนินการตามคำขอต่อไป หากคุณได้รับการเชื่อมต่อจำนวนมากที่มีพื้นฐานมาจากคำขอเล็กๆ น้อยๆ การปิดการเชื่อมต่อจาก Bouncer จะไม่เพียงพอ คุณต้องดำเนินการตามคำขอเหล่านั้นที่ทำงานอยู่ในฐานข้อมูลด้วย
สิ่งนี้ได้รับการแก้ไขแล้วและปัญหายังไม่รวมเข้ากับต้นน้ำของ Bouncer
ดังนั้นเราจึงได้ข้อสรุปว่าเราต้องการตัวรวบรวมการเชื่อมต่อของเราเอง ซึ่งจะได้รับการพัฒนา แพตช์ ซึ่งจะสามารถแก้ไขปัญหาได้อย่างรวดเร็ว และแน่นอนว่าต้องเป็นแบบมัลติเธรด
เรากำหนดให้มัลติเธรดเป็นงานหลัก เราต้องสามารถจัดการกับคลื่นของการเชื่อมต่อ TLS ที่เข้ามาได้ดี
ในการทำเช่นนี้ เราต้องพัฒนาไลบรารีแยกต่างหากที่เรียกว่า Machinarium ซึ่งออกแบบมาเพื่ออธิบายสถานะเครื่องของการเชื่อมต่อเครือข่ายเป็นรหัสซีเรียล หากคุณดูซอร์สโค้ด libpq คุณจะเห็นการเรียกที่ค่อนข้างซับซ้อนที่สามารถส่งผลลัพธ์กลับมาให้คุณและพูดว่า "โทรหาฉันหน่อย ตอนนี้ฉันมี IO อยู่แล้ว แต่เมื่อ IO ผ่านไป ฉันมีภาระในโปรเซสเซอร์ และนี่คือโครงร่างหลายระดับ การโต้ตอบกับเครือข่ายมักอธิบายโดยเครื่องสถานะ กฎมากมายเช่น "ถ้าก่อนหน้านี้ฉันได้รับส่วนหัวของแพ็กเก็ตขนาด N ตอนนี้ฉันกำลังรอ N ไบต์" "ถ้าฉันส่งแพ็กเก็ต SYNC ตอนนี้ฉันกำลังรอแพ็กเก็ตที่มีข้อมูลเมตาของผลลัพธ์" กลายเป็นรหัสตอบโต้ที่ค่อนข้างยากราวกับว่าเขาวงกตถูกแปลงเป็นการสแกนเส้น เราทำให้มันแทนที่จะเป็นเครื่องสถานะ โปรแกรมเมอร์อธิบายเส้นทางการโต้ตอบหลักในรูปแบบของรหัสที่จำเป็นทั่วไป ในรหัสที่จำเป็นนี้ คุณต้องแทรกตำแหน่งที่ลำดับการดำเนินการจำเป็นต้องถูกขัดจังหวะโดยรอข้อมูลจากเครือข่าย ส่งผ่านบริบทการดำเนินการไปยังคอร์รูทีนอื่น (เธรดสีเขียว) วิธีการนี้คล้ายกับการที่เราเขียนเส้นทางที่คาดหวังมากที่สุดในเขาวงกตติดต่อกัน แล้วเพิ่มสาขาเข้าไป
ด้วยเหตุนี้ เราจึงมีหนึ่งเธรดที่ทำให้ TCP ยอมรับและปัดเศษผ่านการเชื่อมต่อ TPC ไปยังผู้ปฏิบัติงานจำนวนมาก
ในกรณีนี้ การเชื่อมต่อไคลเอ็นต์แต่ละครั้งจะทำงานบนโปรเซสเซอร์หนึ่งตัวเสมอ และสิ่งนี้ช่วยให้คุณทำให้มันเป็นมิตรกับแคช
และนอกจากนี้ เราได้ปรับปรุงการรวบรวมแพ็กเก็ตขนาดเล็กให้เป็นแพ็กเก็ตขนาดใหญ่เพียงแพ็กเก็ตเดียว เพื่อกำจัดสแต็ก TCP ของระบบ
นอกจากนี้ เรายังได้ปรับปรุงการรวมธุรกรรมในแง่ที่ว่า Odyssey เมื่อกำหนดค่าแล้ว สามารถส่ง CANCEL และ ROLLBACK ในกรณีที่การเชื่อมต่อเครือข่ายล้มเหลว กล่าวคือ หากไม่มีใครรอคำขอ Odyssey จะบอกฐานข้อมูลว่าอย่าพยายามดำเนินการให้สำเร็จ คำขอที่สามารถสิ้นเปลืองทรัพยากรอันมีค่า
และเมื่อใดก็ตามที่เป็นไปได้ เราจะเชื่อมต่อกับไคลเอนต์เดิม เพื่อหลีกเลี่ยงการติดตั้ง application_name_add_host ใหม่อีกครั้ง หากเป็นไปได้ เราจะไม่มีการรีเซ็ตพารามิเตอร์เพิ่มเติมที่จำเป็นสำหรับการวินิจฉัย
เราทำงานเพื่อผลประโยชน์ของ Yandex.Cloud และถ้าคุณใช้ PostgreSQL ที่มีการจัดการ และคุณติดตั้งตัวพูลเลอร์การเชื่อมต่อไว้ คุณสามารถสร้างการจำลองแบบโลจิคัลภายนอกได้ เช่น ปล่อยเราไว้ถ้าคุณต้องการ โดยใช้การจำลองแบบโลจิคัล คนโกหกที่อยู่นอกกระแสของการจำลองแบบเชิงตรรกะจะไม่ให้
นี่คือตัวอย่างการตั้งค่าการจำลองแบบเชิงตรรกะ
นอกจากนี้ เรายังมีการสนับสนุนการจำลองทางกายภาพภายนอก แน่นอนว่ามันเป็นไปไม่ได้ในระบบคลาวด์เพราะคลัสเตอร์จะให้ข้อมูลเกี่ยวกับตัวมันเองมากเกินไป แต่ในการติดตั้งของคุณ ถ้าคุณต้องการการจำลองแบบทางกายภาพผ่านตัวรวมการเชื่อมต่อใน Odyssey ก็เป็นไปได้
Odyssey มีการตรวจสอบที่เข้ากันได้อย่างสมบูรณ์กับ PgBouncer เรามีคอนโซลเดียวกันที่รันคำสั่งเดียวกันเกือบทั้งหมด หากมีบางอย่างขาดหายไป ส่งคำขอดึงข้อมูล หรืออย่างน้อยมีปัญหาใน GitHub เราจะดำเนินการตามคำสั่งที่จำเป็น แต่เรามีฟังก์ชันหลักของคอนโซล PgBouncer แล้ว
และแน่นอนว่าเรามีข้อผิดพลาดในการส่งต่อ เราจะส่งคืนข้อผิดพลาดที่รายงานโดยฐาน คุณจะได้รับข้อมูลว่าทำไมคุณไม่อยู่ในฐาน ไม่ใช่แค่ว่าคุณไม่ได้อยู่ในนั้น
คุณลักษณะนี้ถูกปิดใช้งานในกรณีที่คุณต้องการความเข้ากันได้กับ PgBouncer 100% เราสามารถทำตัวเหมือน Bouncer ในกรณี
ออกแบบ
คำสองสามคำเกี่ยวกับซอร์สโค้ด Odyssey
เช่น มีคำสั่ง "Pause / Resume" โดยปกติจะใช้เพื่ออัปเดตฐานข้อมูล หากคุณต้องการอัปเกรด Postgres คุณสามารถหยุดชั่วคราวในโปรแกรมรวบรวมการเชื่อมต่อ ทำ pg_upgrade แล้วดำเนินการต่อ และจากฝั่งไคลเอ็นต์ จะดูเหมือนว่าฐานข้อมูลกำลังทำงานช้าลง ฟังก์ชันนี้นำเสนอโดยผู้คนจากชุมชน เธอยังไม่ตาย แต่ในไม่ช้าทุกอย่างจะเป็น (ตายไปแล้ว)
- ตายไปแล้ว
นอกจากนี้หนึ่งในคุณสมบัติใหม่ใน PgBouncer คือการสนับสนุนการพิสูจน์ตัวตน SCRAM ซึ่งบุคคลที่ไม่ได้ทำงานใน Yandex.Cloud นำมาให้เราด้วย ทั้งสองเป็นฟังก์ชันที่ซับซ้อนและมีความสำคัญ
ดังนั้นฉันอยากจะบอกคุณว่า Odyssey ทำมาจากอะไร ในกรณีที่คุณต้องการเขียนโค้ดในตอนนี้
คุณมีฐานดั้งเดิมของ Odyssey ซึ่งอาศัยห้องสมุดหลักสองแห่ง ห้องสมุด Kiwi เป็นการใช้งานโปรโตคอลข้อความ Postgres นั่นคือ native proto 3 ของ Postgres เป็นข้อความมาตรฐานที่ส่วนหน้าและส่วนหลังสามารถแลกเปลี่ยนกันได้ มีการนำไปใช้ในห้องสมุด Kiwi
ไลบรารี Machinarium เป็นไลบรารีการใช้งานเธรด ส่วนเล็ก ๆ ของ Machinarium นี้เขียนด้วยภาษาแอสเซมเบลอร์ แต่ไม่ต้องห่วง มีเพียง 15 บรรทัดเท่านั้น
สถาปัตยกรรมโอดิสซีย์ มีเครื่องหลักที่ใช้คอร์รูทีน เครื่องนี้ใช้การยอมรับการเชื่อมต่อ TCP ที่เข้ามาและกระจายไปยังคนงาน
ภายในผู้ปฏิบัติงานหนึ่งคน ตัวจัดการสำหรับลูกค้าหลายรายสามารถทำงานได้ และในเธรดหลัก คอนโซลและการประมวลผลงาน crone เพื่อลบการเชื่อมต่อที่ไม่จำเป็นอีกต่อไปในพูลกำลังหมุน
Odyssey ได้รับการทดสอบโดยใช้ชุดทดสอบ Postgres มาตรฐาน เราเพิ่งตรวจสอบการติดตั้งผ่าน Bouncer และผ่าน Odyssey เราจะได้ div ที่เป็นโมฆะ มีการทดสอบหลายอย่างที่เกี่ยวข้องกับการจัดรูปแบบวันที่ซึ่งล้มเหลวเหมือนกันทุกประการใน Bouncer และ Odyssey
นอกจากนี้ยังมีไดรเวอร์มากมายที่มีการทดสอบของตัวเอง และเราใช้การทดสอบของพวกเขาเพื่อทดสอบ Odyssey
นอกจากนี้ เนื่องจากการกำหนดค่าแบบเรียงซ้อนของเรา เราจึงต้องทดสอบบันเดิลต่างๆ: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey เพื่อให้แน่ใจว่าหาก Odyssey อยู่ในส่วนใดส่วนหนึ่งของน้ำตก มันยังคงทำงานได้ตามที่คาดไว้ .
คราด
เราใช้ Odyssey ในการผลิต และมันจะไม่ยุติธรรมถ้าฉันบอกว่าทุกอย่างใช้งานได้ ไม่ คือ ใช่ แต่ก็ไม่เสมอไป ตัวอย่างเช่น ในการผลิตทุกอย่างใช้งานได้ จากนั้นเพื่อนของเราจาก PostgreSQL Professional ก็มาบอกว่าหน่วยความจำรั่ว เป็นอย่างนั้นจริง ๆ เราแก้ไขให้แล้ว แต่มันง่าย
จากนั้นเราพบว่าตัวพูลเลอร์การเชื่อมต่อมีการเชื่อมต่อ TLS ขาเข้าและการเชื่อมต่อ TLS ขาออก และการเชื่อมต่อต้องมีใบรับรองไคลเอนต์และใบรับรองเซิร์ฟเวอร์
ใบรับรองเซิร์ฟเวอร์ Bouncer และ Odyssey นั้นอ่านซ้ำโดย pcache แต่ใบรับรองไคลเอ็นต์ไม่จำเป็นต้องอ่านซ้ำจาก pcache เนื่องจากในที่สุด Odyssey ที่ปรับขนาดได้ของเราจะขึ้นอยู่กับประสิทธิภาพของระบบในการอ่านใบรับรองนี้ สิ่งนี้ทำให้เราประหลาดใจเพราะเขาไม่ได้พักผ่อนในทันที ในตอนแรกมันปรับขนาดเป็นเส้นตรง และหลังจากที่มีการเชื่อมต่อเข้ามาพร้อมกัน 20 ครั้ง ปัญหานี้ก็ได้แสดงออกมา
Pluggable Authentication Method คือความสามารถในการรับรองความถูกต้องด้วยเครื่องมือ lunux ในตัว ใน PgBouncer จะดำเนินการในลักษณะที่มีเธรดแยกต่างหากที่รอการตอบกลับจาก PAM และมีเธรด PgBouncer หลักที่ให้บริการการเชื่อมต่อปัจจุบันและสามารถขอให้พวกเขาอยู่ในเธรด PAM
เราไม่ได้ใช้สิ่งนี้ด้วยเหตุผลง่ายๆ เรามีกระแสมากมาย ทำไมเราต้องการมัน?
ด้วยเหตุนี้ สิ่งนี้สามารถสร้างปัญหาได้หากคุณมีการรับรองความถูกต้อง PAM และการรับรองความถูกต้องที่ไม่ใช่ PAM การตรวจสอบความถูกต้อง PAM ระลอกใหญ่อาจทำให้การรับรองความถูกต้องที่ไม่ใช่ PAM ล่าช้าอย่างมาก เป็นหนึ่งในสิ่งที่เรายังไม่ได้แก้ไข แต่หากต้องการแก้ไขก็สามารถทำได้
การคราดอีกประการหนึ่งคือความจริงที่ว่าเรามีหนึ่งเธรดที่ยอมรับการเชื่อมต่อที่เข้ามาทั้งหมด จากนั้นพวกเขาจะถูกโอนไปยังกลุ่มผู้ปฏิบัติงานซึ่งจะมีการจับมือ TLS
ดังนั้น หากคุณมีคลื่นการเชื่อมต่อเครือข่าย 20 คลื่นที่เชื่อมโยงกัน ก็จะได้รับการยอมรับทั้งหมด และในฝั่งไคลเอ็นต์ libpq จะเริ่มรายงานการหมดเวลา ตามค่าเริ่มต้น จะมีเวลา 000 วินาที
หากพวกเขาทั้งหมดไม่สามารถเข้าสู่ฐานได้ในเวลาเดียวกัน พวกเขาก็จะเข้าสู่ฐานไม่ได้ เพราะทั้งหมดนี้สามารถครอบคลุมได้ด้วยการลองใหม่แบบไม่มีเอกซ์โพเนนเชียล
เราลงเอยด้วยการคัดลอกรูปแบบ PgBouncer ที่นี่ เพื่อให้เราได้ควบคุมจำนวนการเชื่อมต่อ TCP ที่เรายอมรับ
หากเราเห็นว่าเรายอมรับการเชื่อมต่อ แต่พวกเขาไม่มีเวลาจับมือกันในตอนท้าย เราจะจัดพวกเขาไว้ในคิวเพื่อไม่ให้ใช้ทรัพยากร CPU สิ่งนี้นำไปสู่ความจริงที่ว่าการจับมือพร้อมกันอาจไม่สามารถทำได้สำหรับการเชื่อมต่อทั้งหมดที่มาถึง แต่อย่างน้อยบางคนจะเข้าสู่ฐานข้อมูลแม้ว่าการโหลดจะแข็งแกร่งพอก็ตาม
แผนงาน
คุณอยากเห็นอะไรในอนาคตใน Odyssey? เราพร้อมที่จะพัฒนาตัวเองในด้านใดบ้างและคาดหวังอะไรจากชุมชน?
สำหรับเดือนสิงหาคม 2019
นี่คือลักษณะของแผนงาน Odyssey ในเดือนสิงหาคม:
- เราต้องการการตรวจสอบความถูกต้องของ SCRAM และ PAM
- เราต้องการส่งต่อคำขออ่านไปยังสแตนด์บาย
- ฉันต้องการรีสตาร์ทออนไลน์
- และความสามารถในการหยุดชั่วคราวบนเซิร์ฟเวอร์
โรดแมปนี้สำเร็จไปแล้วครึ่งหนึ่ง ไม่ใช่เรา และนี่เป็นสิ่งที่ดี เรามาคุยกันว่ายังขาดเหลือและเพิ่มเติมอะไรอีกบ้าง
? เรามีแบบจำลองที่หากไม่ทำตามคำขอก็จะทำให้อากาศร้อนขึ้น เราต้องการให้พวกเขาจัดเตรียมการเฟลโอเวอร์และการสลับโอเวอร์ ในกรณีที่มีปัญหาในศูนย์ข้อมูลใดศูนย์หนึ่ง ฉันต้องการใช้งานที่เป็นประโยชน์ เนื่องจากเราไม่สามารถกำหนดค่าโปรเซสเซอร์กลางตัวเดียวกัน หน่วยความจำเดียวกันด้วยวิธีอื่นได้ เนื่องจากการจำลองแบบจะไม่ทำงานเป็นอย่างอื่น
โดยหลักการแล้วใน Postgres เริ่มจาก 10 เป็นไปได้ที่จะระบุ session_attrs เมื่อทำการเชื่อมต่อ คุณสามารถแสดงรายการโฮสต์ฐานข้อมูลทั้งหมดในการเชื่อมต่อและบอกว่าเหตุใดคุณจึงไปที่ฐานข้อมูล: เขียนหรืออ่านอย่างเดียว และไดรเวอร์เองก็จะเลือกโฮสต์แรกในรายการที่ชอบที่สุด ซึ่งเป็นไปตามข้อกำหนดของ session_attrs
แต่ปัญหาของแนวทางนี้คือไม่สามารถควบคุมความล่าช้าในการจำลองแบบได้ คุณอาจมีแบบจำลองบางประเภทที่ล่าช้าสำหรับบริการของคุณ เพื่อให้ดำเนินการคำขออ่านแบบเต็มรูปแบบบนแบบจำลองได้ อันที่จริง เราจำเป็นต้องสนับสนุนความสามารถในการไม่ทำงานเมื่อไม่สามารถอ่านได้ใน Odyssey
Odyssey ต้องไปที่ฐานข้อมูลเป็นครั้งคราวและขอระยะการจำลองจากหลัก และหากถึงขีดจำกัดแล้ว อย่าปล่อยให้คำขอใหม่เข้าสู่ฐานข้อมูล บอกลูกค้าว่าคุณต้องเริ่มการเชื่อมต่อใหม่ และอาจเลือกโฮสต์อื่นเพื่อดำเนินการตามคำขอ ซึ่งจะทำให้ฐานข้อมูลสามารถกู้คืนการจำลองแบบล่าช้าได้อย่างรวดเร็วและกลับมาอีกครั้งเพื่อตอบกลับด้วยแบบสอบถาม
เป็นการยากที่จะตั้งชื่อวันที่ใช้งานเนื่องจากเป็นโอเพ่นซอร์ส แต่ฉันหวังว่าจะไม่ใช่ 2,5 ปีเหมือนเพื่อนร่วมงานจาก PgBouncer นี่คือคุณลักษณะที่ฉันอยากเห็นใน Odyssey
. ตอนนี้คุณสามารถสร้างคำสั่งที่เตรียมไว้ได้สองวิธี ก่อนอื่น คุณสามารถรันคำสั่ง SQL ซึ่งก็คือ "prepared" เพื่อให้เข้าใจคำสั่ง SQL นี้ เราจำเป็นต้องเรียนรู้วิธีทำความเข้าใจ SQL ในฝั่ง Bouncer สิ่งนี้จะเกินความจำเป็นเพราะมันเกินความจำเป็นเนื่องจากเราต้องการตัวแยกวิเคราะห์ทั้งหมด เราไม่สามารถแยกวิเคราะห์ทุกคำสั่ง SQL
แต่มีคำสั่งที่เตรียมไว้ในระดับโปรโตคอลข้อความใน proto3 และนี่คือจุดที่ข้อมูลที่เตรียมสร้างคำสั่งมาในรูปแบบที่มีโครงสร้าง และเราสามารถสนับสนุนความเข้าใจที่ว่าไคลเอนต์ขอให้สร้างคำสั่งที่เตรียมไว้ในบางการเชื่อมต่อเซิร์ฟเวอร์ และแม้ว่าธุรกรรมจะปิด เรายังคงต้องเชื่อมต่อเซิร์ฟเวอร์และไคลเอ็นต์อยู่เสมอ
แต่นี่คือความคลาดเคลื่อนที่เกิดขึ้นในบทสนทนา เนื่องจากมีคนบอกว่าคุณต้องเข้าใจว่าคำสั่งที่เตรียมไว้ใดที่ไคลเอนต์สร้างและแบ่งปันการเชื่อมต่อเซิร์ฟเวอร์ระหว่างไคลเอนต์ทั้งหมดที่สร้างการเชื่อมต่อเซิร์ฟเวอร์นี้ นั่นคือใครเป็นผู้สร้างคำสั่งที่เตรียมไว้
Andres Freund กล่าวว่าหากลูกค้ามาหาคุณซึ่งได้สร้างคำสั่งที่เตรียมไว้แล้วในการเชื่อมต่อกับเซิร์ฟเวอร์อื่น ให้สร้างมันให้เขา แต่ดูเหมือนจะผิดเล็กน้อยที่จะดำเนินการค้นหาในฐานข้อมูลแทนไคลเอนต์ แต่จากมุมมองของนักพัฒนาที่เขียนโปรโตคอลสำหรับการโต้ตอบกับฐานข้อมูล มันจะสะดวกถ้าเขาได้รับการเชื่อมต่อเครือข่าย ที่มีคำขอเตรียมไว้เช่นนั้น.
และอีกคุณสมบัติหนึ่งที่เราจำเป็นต้องนำไปใช้ ขณะนี้เรามีการตรวจสอบที่เข้ากันได้กับ PgBouncer เราสามารถคืนค่าเวลาดำเนินการแบบสอบถามโดยเฉลี่ย แต่เวลาเฉลี่ยคืออุณหภูมิเฉลี่ยในโรงพยาบาล บางคนหนาว บางคนอุ่น โดยเฉลี่ยแล้วทุกคนมีสุขภาพแข็งแรง มันไม่เป็นความจริง
เราจำเป็นต้องใช้การรองรับเปอร์เซ็นไทล์ ซึ่งจะบ่งชี้ว่ามีคำขอที่ช้าซึ่งใช้ทรัพยากรและทำให้การตรวจสอบยอมรับได้มากขึ้น
สิ่งที่สำคัญที่สุดคือฉันต้องการเวอร์ชัน 1.0 (เวอร์ชัน 1.1 ได้เปิดตัวแล้ว) ความจริงก็คือตอนนี้ Odyssey อยู่ในเวอร์ชัน 1.0rc นั่นคือ ผู้สมัครที่เผยแพร่ และเรคทั้งหมดที่ฉันระบุไว้ได้รับการแก้ไขด้วยเวอร์ชันเดียวกันทุกประการ ยกเว้นการรั่วไหลของหน่วยความจำ
เวอร์ชัน 1.0 มีความหมายอย่างไรสำหรับเรา เรากำลังส่ง Odyssey ไปที่ฐานของเรา มันทำงานอยู่บนฐานข้อมูลของเราแล้ว แต่เมื่อถึงจุด 1 คำขอต่อวินาที เราสามารถพูดได้ว่านี่เป็นเวอร์ชันที่เผยแพร่และเป็นเวอร์ชันที่สามารถเรียกว่า 000
หลายคนในชุมชนขอให้หยุดชั่วคราวเพิ่มเติมและ SCRAM ในเวอร์ชัน 1.0 แต่นั่นหมายความว่าเราจะต้องเปิดตัวเวอร์ชันถัดไปเพื่อใช้งานจริง เพราะทั้ง SCRAM และการหยุดชั่วคราวยังไม่ถูกรวมเข้าด้วยกัน แต่เป็นไปได้มากว่าปัญหานี้จะได้รับการแก้ไขอย่างรวดเร็ว
ฉันกำลังรอคำขอดึงของคุณ และฉันก็อยากจะฟังว่าคุณมีปัญหาอะไรเกี่ยวกับ Bouncer มาหารือกัน บางทีเราสามารถใช้ฟังก์ชันบางอย่างที่คุณต้องการได้
จบในส่วนของฉันแล้ว ฉันอยากฟังความคิดเห็นจากคุณ ขอบคุณ!
คำถาม
ถ้าฉันใส่ชื่อ application_name ของฉันเอง มันจะถูกโยนทิ้งอย่างถูกต้องหรือไม่ รวมถึงการทำธุรกรรมร่วมกันใน Odyssey?
Odyssey หรือ Bouncer?
ในโอดิสซีย์ คนโกหกถูกโยน
เราจะทำชุด
และถ้าการเชื่อมต่อจริงของฉันกระโดดข้ามการเชื่อมต่ออื่น ๆ มันจะถูกส่งหรือไม่?
เราจะสร้างชุดของพารามิเตอร์ทั้งหมดที่ระบุไว้ ฉันไม่สามารถบอกได้ว่า application_name อยู่ในรายการนี้หรือไม่ ดูเหมือนว่าเขาเห็นเขาที่นั่น เราจะตั้งค่าพารามิเตอร์เดียวกันทั้งหมด ด้วยคำขอเดียว ชุดจะทำทุกอย่างที่ไคลเอนต์ติดตั้งระหว่างการเริ่มต้น
ขอบคุณ Andrey สำหรับรายงาน! รายงานดี! ฉันดีใจที่ Odyssey พัฒนาเร็วขึ้นและเร็วขึ้นทุกนาที อยากต่อเหมือนกันครับ เราได้ขอให้คุณมีการเชื่อมต่อแหล่งข้อมูลหลายแหล่งเพื่อให้ Odyssey สามารถเชื่อมต่อกับฐานข้อมูลต่างๆ ในเวลาเดียวกัน เช่น มาสเตอร์สเลฟ จากนั้นเชื่อมต่อกับมาสเตอร์ใหม่โดยอัตโนมัติหลังจากการเฟลโอเวอร์
ใช่ ฉันดูเหมือนจะจำการสนทนานั้นได้ ขณะนี้มีการจัดเก็บหลาย แต่ไม่มีการสลับระหว่างพวกเขา ทางฝั่งของเรา เราต้องสอบถามเซิร์ฟเวอร์ว่าเซิร์ฟเวอร์ยังคงอยู่และเข้าใจว่าเกิดข้อผิดพลาด ใครจะเรียก pg_recovery ฉันมีวิธีมาตรฐานที่จะเข้าใจว่าเราไม่ได้มาหานาย และเราต้องเข้าใจอย่างใดจากความผิดพลาดหรืออย่างไร? นั่นคือแนวคิดนี้น่าสนใจกำลังถูกกล่าวถึง เขียนความคิดเห็นเพิ่มเติม หากคุณมีมือทำงานที่รู้ C โดยทั่วไปแล้วนี่เป็นเรื่องที่ยอดเยี่ยม
ปัญหาของการปรับขนาดในเรพพลิกาก็เป็นที่สนใจของเราเช่นกัน เนื่องจากเราต้องการทำให้การนำคลัสเตอร์ที่เรพลิเคตมาใช้เป็นเรื่องง่ายที่สุดเท่าที่จะเป็นไปได้สำหรับนักพัฒนาแอปพลิเคชัน แต่ในที่นี้ขอความเห็นเพิ่มเติมคือ ทำยังไงดี ทำอย่างไรถึงจะดี
คำถามยังเกี่ยวกับการจำลองแบบ ปรากฎว่าคุณมีต้นแบบและตัวจำลองหลายตัว และเป็นที่ชัดเจนว่าพวกเขาไปที่แบบจำลองน้อยกว่าต้นแบบสำหรับการเชื่อมต่อเนื่องจากอาจมีความแตกต่าง คุณกล่าวว่าความแตกต่างของข้อมูลอาจทำให้ธุรกิจของคุณไม่พึงพอใจและคุณจะไม่ไปที่นั่นจนกว่าจะมีการทำซ้ำ ในเวลาเดียวกัน หากคุณไม่ได้ไปที่นั่นเป็นเวลานาน แล้วเริ่มไป ข้อมูลที่คุณต้องการจะไม่สามารถใช้ได้ทันที นั่นคือถ้าเราไปที่ต้นแบบอย่างต่อเนื่องแคชจะอุ่นขึ้นที่นั่นและแคชจะอยู่ด้านหลังเล็กน้อยในแบบจำลอง
ใช่มันเป็นความจริง. จะไม่มีบล็อกข้อมูลใน pcache ที่คุณต้องการ ในแคชจริง จะไม่มีข้อมูลเกี่ยวกับตารางที่คุณต้องการ จะไม่มีการสืบค้นแยกวิเคราะห์ในแผน ไม่มีอะไรเลย
และเมื่อคุณมีคลัสเตอร์บางประเภท และคุณเพิ่มเรพลิคาใหม่ลงไปที่นั่น ในขณะที่มันเริ่มทำงาน ทุกสิ่งในคลัสเตอร์ก็แย่ เช่น มันเพิ่มแคช
ฉันได้ความคิด แนวทางที่ถูกต้องคือการเรียกใช้การสืบค้นในเรพพลิกาเป็นเปอร์เซ็นต์เล็กน้อยก่อน ซึ่งจะทำให้แคชอุ่นขึ้น โดยคร่าวๆ เรามีเงื่อนไขว่าต้องตามหลังมาสเตอร์ไม่เกิน 10 วินาที และไม่ควรรวมเงื่อนไขนี้ไว้ในคลื่นเดียว แต่ราบรื่นสำหรับลูกค้าบางราย
ใช่ค่ะ น้ำหนักขึ้น
นี่เป็นความคิดที่ดี แต่ก่อนอื่นคุณต้องดำเนินการปิดระบบนี้ ก่อนอื่นเราต้องปิดแล้วเราจะคิดถึงวิธีเปิด นี่เป็นคุณสมบัติที่ยอดเยี่ยมในการเปิดใช้งานอย่างราบรื่น
nginx มีตัวเลือกนี้ slowly start ในคลัสเตอร์สำหรับเซิร์ฟเวอร์ และเขาค่อยๆสร้างภาระ
ใช่ เป็นความคิดที่ดี เราจะลองดูเมื่อเราทำสำเร็จ
ที่มา: will.com