ฉันขอแนะนำให้คุณอ่านสำเนารายงานเมื่อต้นปี 2019 โดย Andrey Borodin “การสำรองข้อมูลด้วย WAL-G มีอะไรในปี 2019”
สวัสดีทุกคน! ฉันชื่ออันเดรย์ โบโรดิน ฉันเป็นนักพัฒนาที่ Yandex ฉันสนใจ PostgreSQL มาตั้งแต่ปี 2016 หลังจากที่ฉันได้พูดคุยกับนักพัฒนาและพวกเขาบอกว่าทุกอย่างเรียบง่าย - คุณใช้ซอร์สโค้ดและสร้างมันขึ้นมา แล้วทุกอย่างจะออกมาดี และตั้งแต่นั้นมาฉันก็หยุดไม่ได้ ฉันเขียนเรื่องต่างๆ มากมาย
สิ่งหนึ่งที่ฉันกำลังทำอยู่คือระบบสำรองข้อมูล . โดยทั่วไปแล้ว ที่ Yandex เราทำงานกับระบบสำรองข้อมูลใน PostgreSQL มาเป็นเวลานานมาก และคุณสามารถค้นหารายงานหกชุดบนอินเทอร์เน็ตเกี่ยวกับวิธีที่เราสร้างระบบสำรองข้อมูล และทุกปีพวกเขาจะพัฒนานิดหน่อย พัฒนานิดหน่อย และมีความน่าเชื่อถือมากขึ้น
แต่วันนี้รายงานไม่เพียงแต่เกี่ยวกับสิ่งที่เราได้ทำ แต่ยังเกี่ยวกับความเรียบง่ายและสิ่งที่เป็นอยู่ด้วย มีกี่คนที่ได้ดูรายงานของฉันเกี่ยวกับ WAL-G แล้ว? ดีที่มีคนไม่ดูไม่กี่คน เพราะผมจะเริ่มจากสิ่งที่ง่ายที่สุดก่อน
หากจู่ๆ คุณมีคลัสเตอร์ PostgreSQL และฉันคิดว่าทุกคนมีคลัสเตอร์เหล่านี้อยู่สองสามคลัสเตอร์ และจู่ๆ ก็ยังไม่มีระบบสำรองข้อมูล คุณจะต้องซื้อพื้นที่จัดเก็บข้อมูล S3 หรือพื้นที่จัดเก็บข้อมูลที่เข้ากันได้กับ Google Cloud
ตัวอย่างเช่น คุณสามารถมาที่จุดยืนของเราและรับรหัสส่งเสริมการขายสำหรับ Yandex Object Storage ซึ่งเข้ากันได้กับ S3
จากนั้นสร้างบัคเก็ต มันเป็นเพียงภาชนะสำหรับข้อมูล
สร้างผู้ใช้บริการ
สร้างคีย์การเข้าถึงสำหรับผู้ใช้บริการ: aws-s3-key
ดาวน์โหลด WAL-G เวอร์ชันเสถียรล่าสุด
เวอร์ชันก่อนเผยแพร่ของเราแตกต่างจากเวอร์ชันเผยแพร่อย่างไร ฉันมักจะถูกขอให้ปล่อยตัวเร็ว และหากไม่มีจุดบกพร่องในเวอร์ชันเป็นระยะเวลาที่เพียงพอ เช่น หนึ่งเดือน ฉันก็ปล่อยมันออกมา นี่คือข่าวประชาสัมพันธ์ฉบับนี้ตั้งแต่เดือนพฤศจิกายน และนั่นหมายความว่าทุกเดือนเราพบข้อบกพร่องบางอย่าง ซึ่งโดยปกติแล้วจะอยู่ในฟังก์ชันที่ไม่สำคัญ แต่เรายังไม่ได้เผยแพร่ เวอร์ชันก่อนหน้าคือเฉพาะเดือนพฤศจิกายนเท่านั้น เราไม่พบจุดบกพร่องในนั้น กล่าวคือ มีการเพิ่มจุดบกพร่องเมื่อโครงการดำเนินไป
เมื่อคุณดาวน์โหลด WAL-G แล้ว คุณสามารถเรียกใช้คำสั่ง “รายการสำรอง” แบบง่ายๆ โดยส่งผ่านตัวแปรสภาพแวดล้อม และจะเชื่อมต่อกับ Object Storage และบอกคุณว่าคุณมีข้อมูลสำรองใดบ้าง แน่นอนว่าในตอนแรกคุณไม่ควรมีการสำรองข้อมูล ประเด็นของสไลด์นี้คือเพื่อแสดงให้เห็นว่าทุกอย่างค่อนข้างเรียบง่าย นี่คือคำสั่งคอนโซลที่ยอมรับตัวแปรสภาพแวดล้อมและดำเนินการคำสั่งย่อย
หลังจากนี้ คุณสามารถสำรองข้อมูลครั้งแรกได้ พูดว่า “backup-push” ใน WAL-G และระบุใน WAL-G ตำแหน่ง pgdata ของคลัสเตอร์ของคุณ และเป็นไปได้มากว่า PostgreSQL จะแจ้งให้คุณทราบหากคุณยังไม่มีระบบสำรองข้อมูลว่าคุณต้องเปิดใช้งาน "โหมดเก็บถาวร"
ซึ่งหมายความว่าคุณต้องไปที่การตั้งค่าและเปิด "archive_mode = on" และเพิ่ม "archive_command" ซึ่งเป็นคำสั่งย่อยใน WAL-G แต่ด้วยเหตุผลบางประการ ผู้คนมักใช้แถบสคริปต์ในหัวข้อนี้และล้อม WAL-G กรุณาอย่าทำเช่นนี้. ใช้ฟังก์ชันที่พบใน WAL-G หากคุณขาดอะไรบางอย่างเขียนถึง . WAL-G ถือว่านี่เป็นโปรแกรมเดียวที่ทำงานใน archive_command
เราใช้ WAL-G เพื่อสร้างคลัสเตอร์ High Availability ในการจัดการฐานข้อมูล Yandex เป็นหลัก
และโดยปกติจะใช้ในโทโพโลยีของ Master หนึ่งรายการและการจำลองหลายรายการ ในขณะเดียวกันก็สร้างสำเนาสำรองใน Yandex Object Storage
สถานการณ์ที่พบบ่อยที่สุดคือการสร้างสำเนาของคลัสเตอร์โดยใช้การกู้คืนช่วงเวลา แต่ในกรณีนี้ประสิทธิภาพของระบบสำรองข้อมูลไม่สำคัญสำหรับเรามากนัก เราเพียงแค่ต้องอัปโหลดคลัสเตอร์ใหม่จากข้อมูลสำรอง
โดยปกติแล้ว เราต้องการประสิทธิภาพของระบบสำรองข้อมูลเมื่อเพิ่มโหนดใหม่ ทำไมมันถึงสำคัญ? โดยทั่วไปแล้วผู้คนจะเพิ่มโหนดใหม่ให้กับคลัสเตอร์เนื่องจากคลัสเตอร์ที่มีอยู่ไม่สามารถจัดการโหลดการอ่านได้ พวกเขาจำเป็นต้องเพิ่มแบบจำลองใหม่ หากเราเพิ่มโหลดจาก pg_basebackup ไปยัง Master จากนั้น Master อาจพังทลายลง ดังนั้นจึงเป็นเรื่องสำคัญมากสำหรับเราที่เราสามารถอัปโหลดโหนดใหม่จากไฟล์เก็บถาวรได้อย่างรวดเร็ว ทำให้เกิดภาระบน Master น้อยที่สุด
และอีกสถานการณ์ที่คล้ายกัน นี่เป็นความจำเป็นในการรีสตาร์ท Master เก่าหลังจากเปลี่ยน Cluster Master จากศูนย์ข้อมูลที่ขาดการเชื่อมต่อ
- ด้วยเหตุนี้ เมื่อกำหนดข้อกำหนดสำหรับระบบคัดลอก เราพบว่า pg_basebackup ไม่เหมาะสำหรับเราเมื่อใช้งานในระบบคลาวด์
- เราต้องการที่จะสามารถบีบอัดข้อมูลของเราได้ แต่เกือบทุกระบบสำรองข้อมูลนอกเหนือจากที่มาพร้อมในกล่องจะมีการบีบอัดข้อมูล
- เราต้องการทำให้ทุกอย่างขนานกัน เนื่องจากผู้ใช้ในระบบคลาวด์ซื้อแกนประมวลผลจำนวนมาก แต่ถ้าเราไม่มีการขนานกันในการดำเนินการบางอย่าง คอร์จำนวนมากก็จะไร้ประโยชน์
- เราต้องการการเข้ารหัสเพราะบ่อยครั้งข้อมูลไม่ใช่ของเราและไม่สามารถจัดเก็บเป็นข้อความที่ชัดเจนได้ อย่างไรก็ตาม การสนับสนุน WAL-G ของเราเริ่มต้นด้วยการเข้ารหัส เราทำการเข้ารหัสใน WAL-G เสร็จแล้ว หลังจากนั้นเราถูกถามว่า: “บางทีพวกเราคนใดคนหนึ่งจะพัฒนาโครงการนี้” และตั้งแต่นั้นมา ฉันก็ร่วมงานกับ WAL-G มาเป็นเวลากว่าหนึ่งปีแล้ว
- นอกจากนี้ เรายังจำเป็นต้องมีการควบคุมปริมาณทรัพยากร เนื่องจากเมื่อเวลาผ่านไปโดยใช้ระบบคลาวด์ เราพบว่าบางครั้งผู้คนมีภาระในการซื้อของที่มีความสำคัญในตอนกลางคืน และภาระนี้ไม่สามารถถูกรบกวนได้ นั่นเป็นเหตุผลที่เราเพิ่มการควบคุมปริมาณทรัพยากร
- ตลอดจนรายการและการจัดการ
- และการตรวจสอบ
เราดูเครื่องมือที่แตกต่างกันมากมาย โชคดีที่เรามีตัวเลือกมากมายใน PostgreSQL และทุกที่ที่เราพลาดบางสิ่งบางอย่างไป ฟังก์ชันเล็กๆ น้อยๆ บางอย่าง ฟีเจอร์เล็กๆ น้อยๆ บางอย่าง
และเมื่อตรวจสอบระบบที่มีอยู่แล้ว เราก็ได้ข้อสรุปว่าเราจะพัฒนา WAL-G ตอนนั้นเป็นโครงการใหม่ มันค่อนข้างง่ายที่จะมีอิทธิพลต่อการพัฒนาโครงสร้างพื้นฐานคลาวด์ของระบบสำรองข้อมูล
อุดมการณ์หลักที่เรายึดมั่นคือ WAL-G ควรเรียบง่ายเหมือนกับบาลาไลกา
WAL-G มี 4 คำสั่ง นี้:
WAL-PUSH – เก็บถาวรเพลา
WAL-FETCH – รับเพลา
BACKUP-PUSH - ทำการสำรองข้อมูล
BACKUP-FETCH – รับข้อมูลสำรองจากระบบสำรองข้อมูล
ในความเป็นจริง WAL-G ยังมีการจัดการการสำรองข้อมูลเหล่านี้ เช่น การแสดงรายการและการลบบันทึกและการสำรองข้อมูลในประวัติที่ไม่จำเป็นอีกต่อไปในขณะนี้
ฟังก์ชั่นที่สำคัญอย่างหนึ่งสำหรับเราคือฟังก์ชั่นการสร้างสำเนาเดลต้า
สำเนาเดลต้าหมายความว่าเราไม่ได้สร้างการสำรองข้อมูลแบบเต็มของทั้งคลัสเตอร์ แต่จะสร้างเฉพาะหน้าที่เปลี่ยนแปลงของไฟล์ที่เปลี่ยนแปลงในคลัสเตอร์เท่านั้น ดูเหมือนว่าในทางปฏิบัติแล้วจะคล้ายกับความสามารถในการกู้คืนโดยใช้ WAL มาก แต่เราสามารถสำรองข้อมูลเดลต้าแบบเธรดเดี่ยวของ WAL พร้อมกันได้ ด้วยเหตุนี้ เมื่อเรามีการสำรองข้อมูลพื้นฐานในวันเสาร์ การสำรองข้อมูลแบบเดลต้าทุกวัน และในวันพฤหัสบดีที่เราล้มเหลว เราก็จำเป็นต้องรวบรวมการสำรองข้อมูลเดลต้า 4 ชุดและ WAL 10 ชั่วโมง จะใช้เวลาประมาณเดียวกันเนื่องจากการสำรองข้อมูลเดลต้าจะม้วนขนานกัน
เดลต้าที่ใช้ LSN - หมายความว่าเมื่อสร้างการสำรองข้อมูล เราจะต้องรวมแต่ละหน้าและตรวจสอบ LSN กับ LSN ของการสำรองข้อมูลก่อนหน้า เพื่อให้เข้าใจว่ามีการเปลี่ยนแปลง หน้าใดๆ ที่อาจมีข้อมูลที่เปลี่ยนแปลงควรมีอยู่ในการสำรองข้อมูลเดลต้า
อย่างที่ฉันบอกไปแล้วว่ามีการให้ความสนใจกับความเท่าเทียมค่อนข้างมาก
แต่ API การเก็บถาวรใน PostgreSQL นั้นสอดคล้องกัน PostgreSQL จะเก็บถาวรไฟล์ WAL หนึ่งไฟล์ และเมื่อกู้คืนจะขอไฟล์ WAL หนึ่งไฟล์ แต่เมื่อฐานข้อมูลร้องขอไฟล์ WAL หนึ่งไฟล์โดยใช้คำสั่ง "WAL-FETCH" เราจะเรียกคำสั่ง "WAL-PREFETCH" ซึ่งจะเตรียมไฟล์ 8 ไฟล์ถัดไปเพื่อดึงข้อมูลจากที่เก็บอ็อบเจ็กต์แบบขนาน
และเมื่อฐานข้อมูลขอให้เราเก็บถาวรไฟล์หนึ่ง เราจะดูที่ archive_status และดูว่ามีไฟล์ WAL อื่น ๆ หรือไม่ และเรากำลังพยายามดาวน์โหลด WAL แบบขนานด้วย สิ่งนี้ให้ประสิทธิภาพที่เพิ่มขึ้นอย่างมากและลดระยะห่างในจำนวน WAL ที่ไม่ได้เก็บถาวรลงอย่างมาก นักพัฒนาระบบสำรองข้อมูลจำนวนมากเชื่อว่านี่เป็นระบบที่มีความเสี่ยง เนื่องจากเราต้องอาศัยความรู้ภายในของโค้ดที่ไม่ใช่ PostgreSQL API PostgreSQL ไม่รับประกันการมีอยู่ของโฟลเดอร์ archive_status สำหรับเรา และไม่รับประกันความหมาย การมีอยู่ของสัญญาณความพร้อมสำหรับไฟล์ WAL ที่นั่น อย่างไรก็ตาม เรากำลังศึกษาซอร์สโค้ด เราพบว่าเป็นเช่นนั้น และเรากำลังพยายามใช้ประโยชน์จากมัน และเราควบคุมทิศทางการพัฒนา PostgreSQL หากกลไกนี้เสียกะทันหันเราจะหยุดใช้งาน
ในรูปแบบบริสุทธิ์ เดลต้า WAL ที่ใช้ LSN จำเป็นต้องอ่านไฟล์คลัสเตอร์ใดๆ ที่โหมดเวลาในระบบไฟล์มีการเปลี่ยนแปลงนับตั้งแต่การสำรองข้อมูลครั้งก่อน เราอยู่กับสิ่งนี้มาเป็นเวลานานเกือบปี และในที่สุด เราก็ได้ข้อสรุปว่า เรามีสามเหลี่ยมปากแม่น้ำ WAL
ซึ่งหมายความว่าทุกครั้งที่เราเก็บถาวร WAL บน Master เราไม่เพียงแต่บีบอัด เข้ารหัส และส่งไปยังเครือข่าย แต่เรายังอ่านมันไปพร้อมๆ กันอีกด้วย เราวิเคราะห์และอ่านบันทึกในนั้น เราเข้าใจว่าบล็อกใดมีการเปลี่ยนแปลงและรวบรวมไฟล์เดลต้า
ไฟล์เดลต้าอธิบายช่วงหนึ่งของไฟล์ WAL อธิบายข้อมูลเกี่ยวกับบล็อกที่มีการเปลี่ยนแปลงในช่วง WAL นี้ จากนั้นไฟล์เดลต้าเหล่านี้ก็จะถูกเก็บถาวรเช่นกัน
ที่นี่เรากำลังเผชิญกับความจริงที่ว่าเราขนานทุกอย่างอย่างรวดเร็ว แต่เราไม่สามารถอ่านประวัติตามลำดับแบบคู่ขนานได้ เพราะในบางส่วนเราอาจพบกับจุดสิ้นสุดของบันทึก WAL ก่อนหน้านี้ ซึ่งเรายังไม่มีอะไรจะเชื่อมโยงด้วย เพราะ การอ่านคู่ขนานทำให้เราวิเคราะห์อนาคตซึ่งยังไม่มีอดีตก่อน
ด้วยเหตุนี้ เราจึงต้องใส่ส่วนที่เข้าใจยากลงในไฟล์ _delta_partial เป็นผลให้เมื่อเราย้อนกลับไปในอดีตเราจะรวมชิ้นส่วนของบันทึก WAL เข้าด้วยกันหลังจากนั้นเราจะแยกวิเคราะห์และทำความเข้าใจว่ามีอะไรเปลี่ยนแปลงไปบ้าง
หากในประวัติศาสตร์ของการแยกวิเคราะห์เพลาของเรา มีอย่างน้อยหนึ่งจุดที่เราไม่เข้าใจสิ่งที่เกิดขึ้น ดังนั้นในระหว่างการสำรองข้อมูลครั้งถัดไป เราจะถูกบังคับให้อ่านคลัสเตอร์ทั้งหมดอีกครั้ง เช่นเดียวกับที่เราทำกับ LSN ปกติ - เดลต้าตาม
ผลก็คือ ความทุกข์ทรมานทั้งหมดของเรานำไปสู่ความจริงที่ว่าเราได้เปิดซอร์สไลบรารีการแยกวิเคราะห์ WAL-G เท่าที่ทราบยังไม่มีใครใช้ แต่ถ้าใครอยากเขียนนำไปใช้ก็ถือเป็นสาธารณสมบัติ (ลิงค์อัพเดท. )
ส่งผลให้กระแสข้อมูลทั้งหมดดูค่อนข้างซับซ้อน อาจารย์ของเราเก็บถาวรเพลาและไฟล์เดลต้าเก็บถาวร และแบบจำลองที่สร้างสำเนาสำรองจะต้องได้รับไฟล์เดลต้าในช่วงเวลาที่ผ่านระหว่างการสำรองข้อมูล ในกรณีนี้ บางส่วนของประวัติจะต้องเพิ่มเป็นกลุ่มและแยกวิเคราะห์ เนื่องจากประวัติทั้งหมดไม่เหมาะกับส่วนขนาดใหญ่ และหลังจากนี้แบบจำลองจะสามารถเก็บข้อมูลสำรองเดลต้าทั้งหมดได้
บนกราฟทุกอย่างดูง่ายกว่ามาก นี่คือการดาวน์โหลดจากหนึ่งในคลัสเตอร์จริงของเรา เรามีระบบ LSN ที่ผลิตภายในวันเดียว และเราเห็นว่าการสำรองข้อมูลเดลต้าบน LSN ทำงานตั้งแต่ตีสามถึงห้าโมงเช้า นี่คือโหลดในจำนวนแกนประมวลผล WAL-delta ใช้เวลาประมาณ 20 นาทีที่นี่ นั่นคือมันเร็วขึ้นอย่างเห็นได้ชัด
เนื่องจากเรามีข้อมูลเกี่ยวกับบล็อกที่เปลี่ยนแปลงและเวลาใดในประวัติศาสตร์ของฐานข้อมูล เราจึงตัดสินใจเพิ่มเติมและตัดสินใจรวมฟังก์ชันการทำงาน - ส่วนขยาย PostgreSQL ที่เรียกว่า "pg_prefaulter"
ซึ่งหมายความว่าเมื่อฐานสแตนด์บายดำเนินการคำสั่งกู้คืน ระบบจะแจ้งให้ WAL-G ดึงไฟล์ WAL ถัดไป เราเข้าใจว่าบล็อกข้อมูลใดบ้างที่กระบวนการกู้คืน WAL จะเข้าถึงได้ในอนาคตอันใกล้นี้ และเริ่มการดำเนินการอ่านบนบล็อกเหล่านี้ สิ่งนี้ทำเพื่อเพิ่มประสิทธิภาพของคอนโทรลเลอร์ SSD เพราะม้วน WAL จะไปถึงหน้าที่จำเป็นต้องเปลี่ยน หน้านี้อยู่บนดิสก์และไม่ได้อยู่ในแคชของหน้า และเขาจะรอพร้อมกันเพื่อให้หน้านี้มาถึง แต่บริเวณใกล้เคียงคือ WAL-G ซึ่งรู้ดีว่าในอีกไม่กี่ร้อยเมกะไบต์ถัดไปของ WAL เราจะต้องมีหน้าบางหน้าและในเวลาเดียวกันก็เริ่มอุ่นเครื่อง เริ่มต้นการเข้าถึงดิสก์หลายรายการเพื่อให้ดำเนินการพร้อมกัน วิธีนี้ทำงานได้ดีกับไดรฟ์ SSD แต่น่าเสียดายที่ไม่สามารถใช้ได้กับฮาร์ดไดรฟ์อย่างแน่นอน เนื่องจากเราจะรบกวนการทำงานของมันตามคำแนะนำของเราเท่านั้น
นี่คือสิ่งที่อยู่ในโค้ดตอนนี้
มีคุณสมบัติที่เราต้องการเพิ่ม
ภาพนี้แสดงให้เห็นว่า WAL-delta ใช้เวลาค่อนข้างสั้น และนี่คือการอ่านการเปลี่ยนแปลงที่เกิดขึ้นในฐานข้อมูลระหว่างวัน เราไม่สามารถทำ WAL-delta ได้ไม่เพียงแต่ในเวลากลางคืนเท่านั้น เนื่องจากไม่ได้เป็นแหล่งโหลดที่สำคัญอีกต่อไป เราสามารถอ่าน WAL-delta ได้ทุกนาทีเนื่องจากมีราคาถูก ภายในหนึ่งนาทีเราสามารถสแกนการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นกับคลัสเตอร์ได้ และอาจเรียกได้ว่าเป็น "WAL-delta ทันที"
ประเด็นก็คือเมื่อเรากู้คืนคลัสเตอร์ เราจะลดจำนวนเรื่องราวที่เราต้องสะสมตามลำดับ นั่นคือ ควรลดจำนวน WAL ที่ม้วน PostgreSQL ลง เนื่องจากต้องใช้เวลามาก
แต่นั่นไม่ใช่ทั้งหมด หากเรารู้ว่ามีการเปลี่ยนบล็อคบางส่วนไปสู่จุดที่มีความสอดคล้องในการสำรองข้อมูล เราก็ไม่สามารถเปลี่ยนแปลงได้ในอดีต นั่นคือตอนนี้เรามีการเพิ่มประสิทธิภาพการส่งต่อ WAL-delta แบบไฟล์ต่อไฟล์ ซึ่งหมายความว่า หากในวันอังคารตารางถูกลบออกทั้งหมดหรือไฟล์บางไฟล์ถูกลบออกจากตารางทั้งหมด ดังนั้นเมื่อเดลต้าทบยอดใน pg_basebackup ของวันจันทร์และวันเสาร์ได้รับการกู้คืน เราจะไม่สร้างข้อมูลนี้ด้วยซ้ำ
เราต้องการขยายเทคโนโลยีนี้ไปสู่ระดับเพจ นั่นคือหากบางส่วนของไฟล์เปลี่ยนแปลงในวันจันทร์ แต่จะถูกเขียนทับในวันพุธ จากนั้นเมื่อกู้คืนไปยังจุดหนึ่งในวันพฤหัสบดี เราไม่จำเป็นต้องเขียนสองสามเวอร์ชันแรกของเพจลงดิสก์
แต่นี่ยังคงเป็นแนวคิดที่กำลังพูดคุยกันอย่างแข็งขันภายในตัวเรา แต่ยังไม่ถึงรหัส
เราต้องการสร้างฟีเจอร์อีกหนึ่งอย่างใน WAL-G เราต้องการทำให้ขยายได้เนื่องจากเราต้องรองรับฐานข้อมูลที่แตกต่างกัน และต้องการให้สามารถจัดการการสำรองข้อมูลในลักษณะเดียวกัน แต่ปัญหาก็คือ MySQL API นั้นแตกต่างอย่างสิ้นเชิง ใน MySQL นั้น PITR ไม่ได้อิงตามบันทึก WAL จริง แต่อิงตาม binlog และเราไม่มีระบบการเก็บถาวรใน MySQL ที่จะบอกระบบภายนอกบางระบบว่า Binlog นี้เสร็จสิ้นแล้วและจำเป็นต้องได้รับการเก็บถาวร เราต้องยืนที่ไหนสักแห่งใน cron กับฐานข้อมูลและตรวจสอบว่ามีอะไรพร้อมหรือไม่?
และในทำนองเดียวกัน ในระหว่างการกู้คืน MySQL จะไม่มีคำสั่งการกู้คืนที่สามารถบอกระบบได้ว่าฉันต้องการไฟล์ดังกล่าว ก่อนที่คุณจะเริ่มสร้างคลัสเตอร์ใหม่ คุณต้องทราบว่าต้องใช้ไฟล์ใดบ้าง คุณเองต้องเดาว่าคุณต้องการไฟล์อะไร แต่ปัญหาเหล่านี้อาจจะสามารถหลีกเลี่ยงได้ด้วยวิธีใดวิธีหนึ่ง (ชี้แจง: รองรับ MySQL แล้ว)
ในรายงาน ฉันอยากจะพูดถึงกรณีที่ WAL-G ไม่เหมาะกับคุณด้วย
หากคุณไม่มีการจำลองแบบซิงโครนัส WAL-G ไม่รับประกันว่าส่วนสุดท้ายจะถูกเก็บรักษาไว้ และหากการเก็บถาวรล่าช้ากว่าส่วนสุดท้ายของประวัติศาสตร์ นั่นก็ถือเป็นความเสี่ยง หากไม่มีการจำลองแบบซิงโครนัส ฉันจะไม่แนะนำให้ใช้ WAL-G อย่างไรก็ตาม ส่วนใหญ่จะออกแบบมาสำหรับการติดตั้งบนคลาวด์ ซึ่งหมายถึงโซลูชัน High Availability ที่มีการจำลองแบบซิงโครนัส ซึ่งรับผิดชอบด้านความปลอดภัยของไบต์สุดท้ายที่คอมมิต
ฉันมักจะเห็นผู้คนพยายามเรียกใช้ทั้ง WAL-G และ WAL-E ในเวลาเดียวกัน เรารองรับความเข้ากันได้แบบย้อนหลังในแง่ที่ว่า WAL-G สามารถกู้คืนไฟล์จาก WAL-E และสามารถกู้คืนข้อมูลสำรองที่ทำใน WAL-E ได้ แต่เนื่องจากทั้งสองระบบใช้ wal-push แบบขนาน พวกเขาจึงเริ่มขโมยไฟล์จากกันและกัน หากเราแก้ไขใน WAL-G มันจะยังคงอยู่ใน WAL-E ใน WAL-E จะดูสถานะไฟล์เก็บถาวร ดูไฟล์ที่เสร็จแล้วและเก็บถาวร ในขณะที่ระบบอื่นจะไม่ทราบว่ามีไฟล์ WAL นี้มีอยู่ เนื่องจาก PostgreSQL จะไม่พยายามเก็บถาวรเป็นครั้งที่สอง
เราจะแก้ไขอะไรที่นี่ในฝั่ง WAL-G? เราจะไม่แจ้ง PostgreSQL ว่าไฟล์นี้ถูกถ่ายโอนแบบขนาน และเมื่อ PostgreSQL ขอให้เราเก็บถาวร เราจะรู้อยู่แล้วว่าไฟล์ดังกล่าวที่มีโหมดเวลานี้และด้วย md5 นี้ได้ถูกเก็บถาวรแล้ว และเราจะบอกว่า PostgreSQL - ตกลง ทุกอย่างพร้อมโดยไม่ต้องทำอะไรเลย
แต่ปัญหานี้ไม่น่าจะได้รับการแก้ไขในฝั่ง WAL-E ดังนั้นในปัจจุบันจึงเป็นไปไม่ได้ที่จะสร้างคำสั่งเก็บถาวรที่จะเก็บถาวรไฟล์ทั้งใน WAL-G และ WAL-E
นอกจากนี้ ยังมีกรณีที่ WAL-G ไม่เหมาะกับคุณในตอนนี้ แต่เราจะแก้ไขได้อย่างแน่นอน
ประการแรก ขณะนี้เราไม่มีการตรวจสอบการสำรองข้อมูลในตัว เราไม่มีการตรวจสอบระหว่างการสำรองข้อมูลหรือการกู้คืน แน่นอนว่าสิ่งนี้ถูกนำไปใช้ในระบบคลาวด์ แต่การดำเนินการนี้ทำได้โดยการตรวจสอบล่วงหน้า โดยการกู้คืนคลัสเตอร์ ฉันต้องการให้ฟังก์ชันนี้แก่ผู้ใช้ แต่จากการตรวจสอบ ฉันคิดว่าใน WAL-G จะสามารถกู้คืนคลัสเตอร์และเริ่มต้นคลัสเตอร์ได้ และดำเนินการทดสอบควัน: pg_dumpall ถึง /dev/null และการตรวจสอบดัชนี amcheck
ขณะนี้ใน WAL-G ไม่มีทางที่จะเลื่อนการสำรองข้อมูลหนึ่งรายการจาก WAL ได้ นั่นคือเรารองรับหน้าต่างบางส่วน ตัวอย่างเช่น การจัดเก็บเจ็ดวันที่ผ่านมา จัดเก็บข้อมูลสำรองสิบรายการล่าสุด จัดเก็บข้อมูลสำรองเต็มสามรายการล่าสุด บ่อยครั้งผู้คนมักจะพูดว่า: “เราต้องการข้อมูลสำรองของสิ่งที่เกิดขึ้นในช่วงปีใหม่ และเราต้องการจะเก็บไว้ตลอดไป” WAL-G ยังไม่สามารถทำเช่นนี้ได้ (หมายเหตุ - สิ่งนี้ได้รับการแก้ไขแล้ว อ่านเพิ่มเติม - ตัวเลือกเครื่องหมายสำรองใน )
และเราไม่มีการตรวจสอบหน้าและการตรวจสอบความสมบูรณ์ของส่วนเพลาทั้งหมดเมื่อตรวจสอบ PITR
จากทั้งหมดนี้ ฉันรวบรวมโปรเจ็กต์สำหรับ Google Summer of Code หากคุณรู้จักนักเรียนที่ฉลาดที่ต้องการเขียนอะไรบางอย่างในภาษา Go และได้รับเงินหลายพันดอลลาร์จากบริษัทเดียวที่มีตัวอักษร "G" ให้แนะนำโครงการของเราให้พวกเขา ฉันจะทำหน้าที่เป็นที่ปรึกษาให้กับโครงการนี้ พวกเขาก็ทำได้ หากไม่มีนักเรียนก็จะรับไปทำเองช่วงซัมเมอร์
และเรามีปัญหาเล็กๆ น้อยๆ อื่นๆ อีกมากมายที่เรากำลังค่อยๆ แก้ไข และมีเรื่องแปลก ๆ เกิดขึ้น
ตัวอย่างเช่น หากคุณให้ข้อมูลสำรองว่างกับ WAL-G ข้อมูลสำรองก็จะล้มเหลว เช่น หากคุณบอกเขาว่าเขาต้องสำรองข้อมูลโฟลเดอร์ว่าง ไฟล์ pg_control จะไม่อยู่ที่นั่น และเขาจะคิดว่าเขาไม่เข้าใจอะไรบางอย่าง ตามทฤษฎีแล้ว ในกรณีนี้ คุณต้องเขียนข้อความปกติถึงผู้ใช้เพื่ออธิบายวิธีใช้เครื่องมือ แต่นี่ไม่ใช่คุณลักษณะของการเขียนโปรแกรม แต่เป็นคุณลักษณะของภาษาที่ดีและเข้าใจได้
เราไม่รู้วิธีการสำรองข้อมูลแบบออฟไลน์ หากฐานข้อมูลโกหก เราก็ไม่สามารถสำรองข้อมูลได้ แต่ทุกอย่างง่ายมากที่นี่ เราเรียกการสำรองข้อมูลโดย LSN เมื่อเริ่มต้น ต้องอ่าน LSN ของฐานพื้นฐานจากไฟล์ควบคุม และนี่คือคุณลักษณะที่ยังไม่เกิดขึ้นจริง ระบบสำรองข้อมูลจำนวนมากสามารถสำรองฐานข้อมูลพื้นฐานได้ และก็สะดวก
ขณะนี้เราไม่สามารถจัดการกับการขาดแคลนพื้นที่สำรองข้อมูลได้อย่างเหมาะสม เพราะเรามักจะทำงานกับการสำรองข้อมูลขนาดใหญ่ที่บ้าน และพวกเขาไม่ได้เข้าใกล้มัน แต่ถ้าใครต้องการเขียนโปรแกรมใน Go ในตอนนี้ ให้เพิ่มการจัดการข้อผิดพลาดเมื่อพื้นที่ไม่เพียงพอลงในที่เก็บข้อมูล ฉันจะตรวจสอบคำขอดึงอย่างแน่นอน
และสิ่งสำคัญที่เรากังวลคือเราต้องการการทดสอบการรวมนักเทียบท่าให้ได้มากที่สุดเพื่อตรวจสอบสถานการณ์ต่างๆ ขณะนี้เรากำลังทดสอบสถานการณ์พื้นฐานเท่านั้น ในทุกการคอมมิต แต่เราต้องการตรวจสอบฟังก์ชันการทำงานทั้งหมดที่เรารองรับด้วยการคอมมิตต่อคอมมิต โดยเฉพาะอย่างยิ่ง เราจะได้รับการรองรับเพียงพอสำหรับ PostgreSQL 9.4-9.5 เราสนับสนุนพวกเขาเนื่องจากชุมชนสนับสนุน PostgreSQL แต่เราจะไม่ตรวจสอบการคอมมิตต่อคอมมิตเพื่อให้แน่ใจว่าทุกอย่างจะไม่เสียหาย และสำหรับฉันดูเหมือนว่านี่เป็นความเสี่ยงที่ค่อนข้างร้ายแรง
เรามี WAL-G ทำงานบนคลัสเตอร์มากกว่าหนึ่งพันคลัสเตอร์ในการจัดการฐานข้อมูล Yandex และสำรองข้อมูลหลายร้อยเทราไบต์ทุกวัน
เรามี TODO มากมายในโค้ดของเรา อยากเขียนโปรแกรม มาเลย เรากำลังรอคำขอดึง เรากำลังรอคำถามอยู่
คำถาม
สวัสดีตอนเย็น! ขอบคุณ! ฉันเดาว่าหากคุณใช้ WAL-delta คุณอาจต้องใช้การเขียนแบบเต็มหน้าเป็นอย่างมาก และถ้าเป็นเช่นนั้น คุณได้ทำการทดสอบแล้วหรือยัง? คุณแสดงกราฟที่สวยงาม ถ้าปิด FPW จะสวยขึ้นขนาดไหน?
การเขียนแบบเต็มหน้าเปิดใช้งานสำหรับเราแล้ว เรายังไม่ได้พยายามปิดการใช้งาน นั่นคือฉันในฐานะนักพัฒนายังไม่ได้พยายามปิดมัน ผู้ดูแลระบบที่ได้ค้นคว้าอาจค้นคว้าปัญหานี้แล้ว แต่เราต้องการ FPW แทบไม่มีใครปิดการใช้งานเพราะไม่เช่นนั้นจะไม่สามารถสำรองข้อมูลจากแบบจำลองได้
ขอบคุณสำหรับรายงาน! ฉันมีสองคำถาม คำถามแรกคือจะเกิดอะไรขึ้นกับ tablespaces?
เรากำลังรอคำขอดึง ฐานข้อมูลของเราอยู่บนดิสก์ SSD และ NMVE และเราไม่ต้องการฟีเจอร์นี้จริงๆ ฉันยังไม่พร้อมที่จะใช้เวลาอย่างจริงจังในการทำให้ดีตอนนี้ ฉันสนับสนุนอย่างเต็มที่ว่าเราสนับสนุนสิ่งนี้ มีคนสนับสนุนแต่ก็สนับสนุนในแบบที่เหมาะกับพวกเขา พวกเขาทำทางแยก แต่พวกเขาไม่ได้ดึงคำขอ (เพิ่มในเวอร์ชัน 0.2.13)
และคำถามที่สอง คุณบอกไว้ตั้งแต่แรกแล้วว่า WAL-G ถือว่ามันทำงานโดยลำพังและไม่จำเป็นต้องมีแผ่นปิด ฉันใช้กระดาษห่อเอง ทำไมจึงไม่ควรใช้?
เราอยากให้มันเรียบง่ายเหมือนบาลาไลกา ซึ่งหมายความว่าคุณไม่ต้องการอะไรเลยนอกจากบาลาไลกา เราต้องการให้ระบบเรียบง่าย หากคุณมีฟังก์ชันการทำงานที่ต้องทำในสคริปต์ โปรดบอกเรา เราจะดำเนินการใน Go
สวัสดีตอนเย็น! ขอบคุณสำหรับรายงาน! เราไม่สามารถให้ WAL-G ทำงานร่วมกับการถอดรหัส GPG ได้ มันเข้ารหัสตามปกติ แต่ไม่ต้องการถอดรหัส มันเป็นสิ่งที่ไม่ได้ผลสำหรับเราใช่ไหม? สถานการณ์กำลังตกต่ำ
สร้างปัญหาบน GitHub แล้วมาทำความเข้าใจกัน
นั่นคือคุณไม่เคยเจอสิ่งนี้เหรอ?
มีคุณลักษณะของรายงานข้อผิดพลาดที่เมื่อ WAL-G ไม่เข้าใจว่าเป็นไฟล์ประเภทใด ระบบจะถามว่า “อาจถูกเข้ารหัสหรือไม่” บางทีปัญหาอาจไม่ใช่การเข้ารหัสเลย ฉันต้องการปรับปรุงการบันทึกในหัวข้อนี้ เขาต้องถอดรหัสมัน ขณะนี้เรากำลังดำเนินการในหัวข้อนี้ในแง่ที่ว่าเราไม่ชอบวิธีการจัดระเบียบระบบการรับคีย์สาธารณะและคีย์ส่วนตัว เพราะเราเรียก GPG ภายนอกเพื่อให้มันมอบกุญแจให้กับเรา จากนั้นเราก็นำคีย์เหล่านี้และถ่ายโอนไปยัง GPG ภายในซึ่งเป็น PGP แบบเปิดซึ่งรวบรวมไว้ให้เราภายใน WAL-G และที่นั่นเราเรียกว่าการเข้ารหัส ในเรื่องนี้ เราต้องการปรับปรุงระบบและต้องการรองรับการเข้ารหัส Libsodium (เพิ่มในเวอร์ชัน 0.2.15) แน่นอนว่าการถอดรหัสควรได้ผลเรามาดูกันดีกว่า - คุณต้องการอาการมากกว่าคำสองสามคำ รวมตัวกันที่ห้องวิทยากรบ้างแล้วมาดูระบบกัน (การเข้ารหัส PGP โดยไม่มี GPG ภายนอก - v0.2.9)
สวัสดี! ขอบคุณสำหรับรายงาน! ฉันมีสองคำถาม ฉันมีความปรารถนาแปลกๆ ที่จะทำบันทึก pg_basebackup และ WAL ในผู้ให้บริการสองราย นั่นคือ ฉันต้องการทำระบบคลาวด์หนึ่งและอีกระบบหนึ่ง มีวิธีการทำเช่นนี้หรือไม่?
สิ่งนี้ไม่มีอยู่ในขณะนี้ แต่เป็นแนวคิดที่น่าสนใจ
ฉันแค่ไม่ไว้วางใจผู้ให้บริการรายใดรายหนึ่ง ฉันต้องการให้ผู้ให้บริการรายอื่นเหมือนกัน เผื่อไว้
แนวคิดนี้น่าสนใจ ในทางเทคนิคแล้ว การดำเนินการนี้ไม่ใช่เรื่องยากเลย เพื่อป้องกันไม่ให้ไอเดียนี้สูญหาย ฉันขอให้คุณสร้างปัญหาบน GitHub ได้ไหม
ใช่แน่นอน
จากนั้น เมื่อนักเรียนมาที่ Google Summer of Code เราจะเพิ่มพวกเขาเข้าไปในโปรเจ็กต์เพื่อให้มีงานทำมากขึ้นเพื่อใช้ประโยชน์จากพวกเขาให้มากขึ้น
และคำถามที่สอง มีปัญหาใน GitHub ฉันคิดว่ามันปิดไปแล้ว มีอาการตื่นตระหนกระหว่างการคืนค่า และเพื่อจะเอาชนะมันได้ ท่านจึงแยกการชุมนุม มันถูกต้องในประเด็น. และมีตัวเลือกให้ทำสภาพแวดล้อมที่แปรผันได้ในเธรดเดียว และนั่นคือสาเหตุที่มันทำงานช้ามาก และเราพบปัญหานี้และยังไม่ได้รับการแก้ไข
ปัญหาคือด้วยเหตุผลบางประการที่เก็บข้อมูล (CEPH) จะรีเซ็ตการเชื่อมต่อเมื่อเราใช้งานพร้อมกันในระดับสูง สิ่งที่สามารถทำได้เกี่ยวกับเรื่องนี้? ตรรกะการลองใหม่มีลักษณะเช่นนี้ เรากำลังพยายามดาวน์โหลดไฟล์อีกครั้ง ในหนึ่งรอบ เรามีไฟล์จำนวนหนึ่งที่ไม่ได้ดาวน์โหลด เราจะสร้างไฟล์ที่สองขึ้นมาสำหรับผู้ที่ไม่ได้เข้าสู่ระบบ และตราบใดที่มีการโหลดไฟล์อย่างน้อยหนึ่งไฟล์ต่อการวนซ้ำ เราจะทำซ้ำ ทำซ้ำ และทำซ้ำ เราได้ปรับปรุงตรรกะของการลองใหม่อีกครั้ง - การถอยกลับแบบเอ็กซ์โปเนนเชียล แต่ก็ยังไม่ชัดเจนนักว่าจะทำอย่างไรกับการเชื่อมต่อที่ขาดหายไปจากฝั่งระบบจัดเก็บข้อมูล นั่นคือเมื่อเราอัปโหลดไปยังสตรีมเดียว จะไม่ทำลายการเชื่อมต่อเหล่านี้ เราจะปรับปรุงอะไรได้บ้างที่นี่? เรามีการควบคุมปริมาณเครือข่าย เราสามารถจำกัดการเชื่อมต่อแต่ละรายการตามจำนวนไบต์ที่ส่ง มิฉะนั้นฉันไม่ทราบวิธีจัดการกับความจริงที่ว่าที่เก็บข้อมูลออบเจ็กต์ไม่อนุญาตให้เราดาวน์โหลดหรือดาวน์โหลดจากที่เก็บข้อมูลแบบขนาน
ไม่มีข้อกำหนดมาตรฐานการบริการ? มีเขียนไว้สำหรับพวกเขามิใช่หรือว่าพวกเขาปล่อยให้ตัวเองถูกทรมาน?
ประเด็นก็คือคนที่ถามคำถามนี้มักจะมีห้องนิรภัยเป็นของตัวเอง นั่นคือไม่มีใครมาจาก Amazon หรือ Google Cloud หรือ Yandex Object Storage
บางทีคำถามอาจไม่เหมาะกับคุณอีกต่อไป?
คำถามในกรณีนี้ไม่สำคัญกับใคร หากมีแนวคิดใด ๆ เกี่ยวกับวิธีจัดการกับสิ่งนี้ เรามาทำใน WAL-G กัน แต่จนถึงตอนนี้ฉันยังไม่มีความคิดที่ดีเกี่ยวกับวิธีจัดการกับเรื่องนี้ มี Object Storage บางตัวที่รองรับการแสดงรายการข้อมูลสำรองที่แตกต่างกัน คุณขอให้พวกเขาแสดงรายการออบเจ็กต์ และพวกเขาเพิ่มโฟลเดอร์ที่นั่น WAL-G กลัวสิ่งนี้ - มีบางอย่างที่ไม่ใช่ไฟล์ ฉันไม่สามารถกู้คืนได้ ซึ่งหมายความว่าข้อมูลสำรองไม่ได้รับการกู้คืน ที่จริงแล้ว คุณมีคลัสเตอร์ที่ได้รับการกู้คืนอย่างสมบูรณ์ แต่คลัสเตอร์นั้นส่งคืนสถานะที่ผิดพลาด เนื่องจาก Object Storage ส่งคืนข้อมูลแปลก ๆ บางอย่างที่คลัสเตอร์ยังไม่เข้าใจทั้งหมด
นี่คือสิ่งที่เกิดขึ้นใน Mail cloud
หากคุณสามารถสร้างการสืบพันธุ์ได้...
มีการผลิตซ้ำอย่างต่อเนื่อง...
หากมีการทำซ้ำ ฉันคิดว่าเราจะทดลองใช้กลยุทธ์การลองซ้ำ และหาวิธีลองใหม่และทำความเข้าใจว่าระบบคลาวด์ต้องการอะไรจากเรา บางทีมันอาจจะเสถียรสำหรับเราในการเชื่อมต่อสามครั้งและจะไม่ทำลายการเชื่อมต่อ จากนั้นเราจะไปถึงสามการเชื่อมต่ออย่างระมัดระวัง เพราะตอนนี้เรายกเลิกการเชื่อมต่ออย่างรวดเร็ว เช่น ถ้าเราเปิดตัวการกู้คืนด้วย 16 เธรด หลังจากลองอีกครั้งครั้งแรกจะมี 8 เธรด 4 เธรด 2 เธรดและหนึ่งเธรด แล้วมันก็จะดึงไฟล์มาไว้ในสตรีมเดียว หากมีค่าเวทย์มนตร์บางอย่างเช่น 7,5 เธรดนั้นดีที่สุดในการปั๊ม เราก็จะยังคงอยู่และพยายามสร้าง 7,5 เธรดเพิ่มอีก นี่คือความคิด
ขอบคุณสำหรับรายงาน! ขั้นตอนการทำงานที่สมบูรณ์สำหรับการทำงานกับ WAL-G มีลักษณะอย่างไร ตัวอย่างเช่น ในกรณีที่โง่เขลาเมื่อไม่มีเดลต้าข้ามหน้าต่างๆ และเรานำข้อมูลสำรองเริ่มแรกออก จากนั้นเก็บถาวรเพลาจนกว่าหน้าเราจะเป็นสีฟ้า ตามที่ฉันเข้าใจมีพังทลาย เมื่อถึงจุดหนึ่ง คุณจะต้องสำรองข้อมูลเพจแบบเดลต้า เช่น กระบวนการภายนอกบางอย่างกำลังขับเคลื่อนสิ่งนี้ หรือสิ่งนี้เกิดขึ้นได้อย่างไร
API การสำรองข้อมูลเดลต้านั้นค่อนข้างง่าย มีตัวเลขอยู่จำนวนหนึ่ง – ขั้นตอนเดลต้าสูงสุด นั่นคือสิ่งที่เรียกว่า โดยค่าเริ่มต้นจะเป็นศูนย์ ซึ่งหมายความว่าทุกครั้งที่คุณสำรองข้อมูล ระบบจะดาวน์โหลดข้อมูลสำรองทั้งหมด หากคุณเปลี่ยนเป็นจำนวนบวกใดๆ เช่น 3 ครั้งต่อไปที่คุณสำรองข้อมูล ระบบจะดูประวัติของการสำรองข้อมูลครั้งก่อน เขาเห็นว่าคุณไม่เกินห่วงโซ่ 3 เดลต้าและสร้างเดลต้า
นั่นคือทุกครั้งที่เราเปิดตัว WAL-G มันจะพยายามสำรองข้อมูลทั้งหมดใช่หรือไม่
ไม่ เราใช้ WAL-G และจะพยายามสร้างเดลต้าหากนโยบายของคุณอนุญาต
พูดง่ายๆ ก็คือ ถ้าคุณรันมันโดยมีค่าศูนย์ทุกครั้ง มันจะทำงานเหมือน pg_basebackup หรือไม่?
ไม่ มันจะยังคงทำงานเร็วขึ้นเพราะใช้การบีบอัดและความเท่าเทียม Pg_basebackup จะวางเพลาไว้ข้างๆคุณ WAL-G จะถือว่าคุณได้กำหนดค่าการเก็บถาวรแล้ว และจะแจ้งเตือนหากไม่ได้กำหนดค่าไว้
Pg_basebackup สามารถรันได้โดยไม่ต้องใช้เพลา
ใช่แล้วพวกเขาจะประพฤติตัวเกือบจะเหมือนกัน Pg_basebackup คัดลอกไปยังระบบไฟล์ อย่างไรก็ตาม เรามีฟีเจอร์ใหม่ที่ฉันลืมพูดถึง ตอนนี้เราสามารถสำรองข้อมูลไปยังระบบไฟล์ได้จาก pg_basebackup ฉันไม่รู้ว่าทำไมสิ่งนี้ถึงจำเป็น แต่มันอยู่ที่นั่น
ตัวอย่างเช่น บน CephFS ไม่ใช่ทุกคนที่ต้องการกำหนดค่า Object Storage
ใช่ นั่นอาจเป็นเหตุผลว่าทำไมพวกเขาถึงถามคำถามเกี่ยวกับฟีเจอร์นี้เพื่อที่เราจะได้ทำมันได้ และเราก็ทำมัน
ขอบคุณสำหรับรายงาน! มีคำถามเกี่ยวกับการคัดลอกไปยังระบบไฟล์ ตอนนี้คุณรองรับการคัดลอกไปยังที่จัดเก็บข้อมูลระยะไกลแล้วหรือไม่ เช่น หากมีชั้นวางในศูนย์ข้อมูลหรืออย่างอื่น
ในสูตรนี้ นี่เป็นคำถามที่ยาก ใช่ เรารองรับ แต่ฟังก์ชันการทำงานนี้ยังไม่รวมอยู่ในรุ่นใดๆ กล่าวคือ รุ่นก่อนเผยแพร่ทั้งหมดรองรับสิ่งนี้ แต่เวอร์ชันวางจำหน่ายไม่รองรับ ฟังก์ชั่นนี้ถูกเพิ่มเข้ามาในเวอร์ชั่น 0.2 จะมีการเปิดตัวเร็วๆ นี้ ทันทีที่เราแก้ไขข้อบกพร่องที่ทราบทั้งหมดแล้ว แต่ตอนนี้สามารถทำได้เฉพาะในช่วงก่อนเผยแพร่เท่านั้น มีข้อบกพร่องสองประการในช่วงก่อนเผยแพร่ ปัญหาในการกู้คืน WAL-E เรายังไม่ได้แก้ไข และในเวอร์ชันก่อนเผยแพร่ล่าสุด มีการเพิ่มข้อบกพร่องเกี่ยวกับการสำรองข้อมูลแบบเดลต้า ดังนั้นเราขอแนะนำให้ทุกคนใช้เวอร์ชันที่วางจำหน่าย ทันทีที่ไม่มีข้อบกพร่องในรุ่นก่อนเผยแพร่อีกต่อไป เราสามารถพูดได้ว่าเรารองรับ Google Cloud, สิ่งที่เข้ากันได้กับ S3 และพื้นที่จัดเก็บไฟล์
สวัสดี ขอบคุณสำหรับรายงาน ตามที่ฉันเข้าใจ WAL-G ไม่ใช่ระบบรวมศูนย์เหมือนบาร์เทนเดอร์ใช่ไหม คุณวางแผนที่จะย้ายไปในทิศทางนี้หรือไม่?
ปัญหาคือเราย้ายออกไปจากทิศทางนี้ WAL-G ใช้งานบนโฮสต์พื้นฐาน บนโฮสต์ของคลัสเตอร์ และบนโฮสต์ทั้งหมดในคลัสเตอร์ เมื่อเราย้ายไปหลายพันกลุ่ม เรามีบาร์เทนเดอร์จำนวนมาก และทุกครั้งที่มีบางอย่างพังทลายลง มันเป็นปัญหาใหญ่ เนื่องจากจำเป็นต้องได้รับการซ่อมแซม คุณจึงต้องเข้าใจว่าคลัสเตอร์ใดที่ไม่มีการสำรองข้อมูลในขณะนี้ ฉันไม่ได้วางแผนที่จะพัฒนา WAL-G ในด้านฮาร์ดแวร์กายภาพสำหรับระบบสำรองข้อมูล หากชุมชนต้องการฟังก์ชันบางอย่างที่นี่ ฉันก็ไม่ว่าอะไร
เรามีทีมงานที่รับผิดชอบการจัดเก็บ และเรารู้สึกดีมากที่ไม่ใช่เราที่มีคนพิเศษวางไฟล์ของเราไว้ในที่ที่ปลอดภัย พวกเขาทำการเข้ารหัสที่ชาญฉลาดทุกประเภทเพื่อป้องกันการสูญเสียไฟล์จำนวนหนึ่ง พวกเขามีหน้าที่รับผิดชอบแบนด์วิธเครือข่าย เมื่อคุณมีบาร์เทนเดอร์ คุณอาจพบว่ามีฐานข้อมูลขนาดเล็กที่มีการรับส่งข้อมูลจำนวนมากมารวมตัวกันบนเซิร์ฟเวอร์เดียวกัน ดูเหมือนคุณจะมีพื้นที่ว่างมาก แต่ด้วยเหตุผลบางอย่าง ทุกอย่างไม่พอดีกับเครือข่าย มันอาจจะกลับกลายเป็นอย่างอื่น มีเครือข่ายจำนวนมากมีแกนประมวลผล แต่ไม่มีดิสก์อยู่ที่นี่ และเราเบื่อกับความจำเป็นที่ต้องจัดการบางสิ่งบางอย่าง และเราย้ายไปยังความจริงที่ว่าการจัดเก็บข้อมูลเป็นบริการแยกต่างหาก ซึ่งบุคคลพิเศษที่แยกต่างหากจะต้องรับผิดชอบ
ป.ล. มีการเปิดตัวเวอร์ชันใหม่แล้ว ซึ่งคุณสามารถใช้ไฟล์การกำหนดค่า .walg.json ซึ่งอยู่ในไดเร็กทอรีโฮมของ postgres ตามค่าเริ่มต้น คุณสามารถละทิ้งสคริปต์ทุบตีได้ ตัวอย่าง .walg.json อยู่ในปัญหานี้
วิดีโอ:
ที่มา: will.com