การซิงโครไนซ์โครงสร้างโฟลเดอร์ที่มีขนาดใหญ่มาก

เรามีโครงสร้างโฟลเดอร์บนอินทราเน็ตของเราซึ่งมีไฟล์ประมาณ 800,000 ไฟล์แบ่งออกเป็นประมาณ 4,000 โฟลเดอร์ เราจำเป็นต้องซิงโครไนซ์สิ่งนี้กับกลุ่มเครื่องขนาดเล็กใน DMZ ของเรา ความลึกของโครงสร้างตื้นมาก (ไม่ลึกเกินสองระดับ)

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

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

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

มีคนอื่นที่ทำงานในโครงการการประสานขนาดใหญ่ของการเรียงลำดับนี้หรือไม่? มีบางสิ่งที่ออกแบบมาเพื่อจัดการโครงสร้างไฟล์ขนาดใหญ่เช่นนี้เพื่อการซิงโครไนซ์หรือไม่?

หากคุณเชื่อถือระบบไฟล์เวลาที่แก้ไขล่าสุดคุณสามารถเพิ่มความเร็วได้โดยการรวม Rsync เข้ากับยูทิลิตี้ 'find' ของ UNIX / Linux 'find' สามารถรวบรวมรายการของไฟล์ทั้งหมดที่แสดงเวลาที่แก้ไขล่าสุดภายในวันที่ผ่านมาและจากนั้นไพพ์เท่านั้นที่จะย่อรายการไฟล์ / ไดเรกทอรีไปยัง Rsync สิ่งนี้เร็วกว่าการให้ Rsync เปรียบเทียบข้อมูลเมตาของทุก ๆ ไฟล์บนผู้ส่งกับเซิร์ฟเวอร์ระยะไกล

กล่าวโดยย่อคำสั่งต่อไปนี้จะดำเนินการ Rsync เฉพาะในรายการไฟล์และไดเรกทอรีที่มีการเปลี่ยนแปลงใน 24 ชั่วโมงที่ผ่านมา: (Rsync จะไม่รบกวนตรวจสอบไฟล์ / ไดเรกทอรีอื่น ๆ )

find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.

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

find . -name '\.svn' -type d -ctime -0 -print

จะเริ่มในไดเรกทอรีปัจจุบัน (".") และเรียกคืนผ่านไดเรกทอรีย่อยทั้งหมดโดยมองหา:

• ไดเรกทอรีใด ๆ ("-type d"),
• ชื่อ ".svn" ("-name '.svn'"),
• ที่มีการแก้ไขข้อมูลเมตาใน 24 ชั่วโมงที่ผ่านมา ("-ctime -0")

มันพิมพ์ชื่อพา ธ เต็ม ("-print") ของสิ่งที่ตรงกับเกณฑ์เหล่านั้นในการส่งออกมาตรฐาน ตัวเลือก '-name', '-type' และ '-ctime' เรียกว่า "tests" และตัวเลือก '-print' เรียกว่า "action" หน้าคนสำหรับ 'ค้นหา' มีรายการการทดสอบและการกระทำที่สมบูรณ์

หากคุณต้องการให้ฉลาดจริง ๆ คุณสามารถใช้การทดสอบ 'ค้นหา' คำสั่ง '-cnewer' แทน '-ctime' เพื่อทำให้กระบวนการนี้ทนต่อความผิดพลาดและยืดหยุ่นได้มากขึ้น '-cnewer' ทดสอบว่าแต่ละไฟล์ / ไดเร็กทอรีในแผนผังมีการเปลี่ยนแปลงข้อมูลเมตามากกว่าไฟล์อ้างอิงบางไฟล์หรือไม่ ใช้ 'สัมผัส' เพื่อสร้างไฟล์อ้างอิงของ NEXT ที่จุดเริ่มต้นของการวิ่งแต่ละครั้งก่อน 'ค้นหา ... | คำสั่ง rsync ... 'ดำเนินการ นี่คือการใช้งานพื้นฐาน:

#!/bin/sh
curr_ref_file=`ls /var/run/last_rsync_run.*`
next_ref_file="/var/run/last_rsync_run.$RANDOM"
touch $next_ref_file
find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.
rm -f $curr_ref_file

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

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

http://oss.linbit.com/csync2/ได้รับการออกแบบมาสำหรับสิ่งนี้ฉันจะลองดู

หากคุณใช้สวิตช์ -z บน rsync ให้ลองเรียกใช้โดยไม่ใช้ ด้วยเหตุผลบางอย่างที่ฉันเห็นความเร็วนี้ถึงแม้จะมีการแจงนับไฟล์ครั้งแรก

การนำ -z ออกจากคำสั่ง rsync ซึ่งไม่มีการบีบอัดทำให้ "รายชื่อไฟล์ที่รับ" ไปเร็วขึ้นมากและเราต้องถ่ายโอนประมาณ 500 GB ก่อนที่จะใช้เวลาหนึ่งวันด้วยสวิตช์ -z