วิธีทำมิรเรอร์ระบบไฟล์ด้วยฮาร์ดลิงก์นับล้าน


11

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

ในระบบไฟล์นี้มีหนึ่งโฟลเดอร์ที่มีฮาร์ดลิงก์นับล้าน (ใช่! MILLIONS!) rsyncต้องใช้เวลามากกว่า 4 วันในการสร้างผู้สร้าง

เราใช้rsyncตัวเลือกต่อไปนี้:

rsync -Havz --progress serverA:/data/cms /data/

มีใครบ้างที่คิดว่าจะเร่งความเร็ว rsync นี้หรือใช้ทางเลือกอื่น เราไม่สามารถใช้งานได้ddเนื่องจากดิสก์เป้าหมายมีขนาดเล็กกว่าแหล่งที่มา

UPDATE: ในฐานะที่เป็นระบบแฟ้มเดิมคือext3เราจะพยายามและdump restoreฉันจะทำให้คุณ up2date


เขี้ยวลากดิน ย่อขนาดซอร์สไฟล์ระบบก่อนจากนั้น dd?
Bittrance

คำตอบ:


3

คุณต้องอัปเกรดทั้งสองฝ่ายเป็น rsync 3. จากรายการเปลี่ยนแปลง:

- A new incremental-recursion algorithm is now used when rsync is talking
  to another 3.x version.  This starts the transfer going more quickly
  (before all the files have been found), and requires much less memory.
  See the --recursive option in the manpage for some restrictions.

เป็นเวลานานกว่า 2 ปีแล้วที่ rsync 3.0.0 เปิดตัว แต่น่าเสียดายที่การแจกแจงแบบองค์กรส่วนใหญ่อ้างอิงจากรหัสที่เก่ากว่าซึ่งหมายความว่าคุณอาจใช้ rsync 2.6

สำหรับการอ้างอิง (ถ้าคนอื่นจะมีปัญหานี้) ถ้าคุณกำลังทำงาน rsync 3 แล้วแล้วคุณจะใช้ตัวเลือกที่จะเข้ากันกับการเรียกซ้ำเพิ่มขึ้น จากหน้าคน:

    Some options require rsync to know the full file list, so  these
    options  disable the incremental recursion mode.  These include:
    --delete-before,   --delete-after,    --prune-empty-dirs,    and
    --delay-updates.

นอกจากนี้ทั้งสองฝั่งต้องใช้งาน rsync 3 เพื่อรองรับการเรียกซ้ำแบบส่วนเพิ่มเพื่อรับการสนับสนุน


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

อุ๊ยตาย ใช่ในกรณีนี้คุณอาจต้องการดูตัวเลือกต่างๆเพื่อเพิ่มความเร็วในการเข้าถึงระบบไฟล์ (เช่นเปลี่ยนเป็น ext4 หากคุณใช้ ext3), เปลี่ยนเป็นดิสก์ที่เร็วกว่าหรือระดับ RAID (หากเป็นตัวเลือก) ฯลฯ น่าเสียดายที่คุณ อาจเป็นจุดที่ระบบไฟล์ไม่สามารถเร็วพอและการสำรองข้อมูลระดับบล็อกอาจเป็นตัวเลือกเดียวของคุณ ฉันมีปัญหานี้พยายาม rsync พูล BackupPC จากเซิร์ฟเวอร์หนึ่งไปยังเซิร์ฟเวอร์อื่น
Steven Pritchard

3

เราได้ใช้ ext * dump ตอนนี้ ทำงานได้ดีและด้านการกู้คืนไม่จำเป็นต้องมีการยืดออก *

เราได้ทำการสำรองข้อมูลออฟไลน์โดยการติดตั้งอุปกรณ์และใช้งานdump vf - /dev/vg0/opt | gzip -c > /mnt/backup/ext3dump.gzแล้ว

นี่คือบรรทัดสุดท้ายที่คุณสามารถเห็นขนาดเวลาความเร็วและหมายเลขไอโหนดสุดท้าย:

DUMP: dumping regular inode 47169535
DUMP: dumping regular inode 47169536
DUMP: Volume 1 completed at: Wed Jun 29 05:42:57 2011
DUMP: Volume 1 54393520 blocks (53118.67MB)
DUMP: Volume 1 took 4:16:43
DUMP: Volume 1 transfer rate: 3531 kB/s
DUMP: 54393520 blocks (53118.67MB)
DUMP: finished in 15403 seconds, throughput 3531 kBytes/sec
DUMP: Date of this level  dump: Wed Jun 29 01:24:29 2011
DUMP: Date this dump completed:  Wed Jun 29 05:42:57 2011
DUMP: Average transfer rate: 3531 kB/s
DUMP: DUMP IS DONE

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

0

คุณสามารถใช้ LVM และรับสแนปชอตของไดรฟ์ข้อมูลจากนั้นซิงค์สแนปชอตเป็นข้อมูลสำรอง

อีกวิธีหนึ่งคุณสามารถรวมสิ่งนี้กับคำตอบอื่น ๆ และใช้dump กับปริมาณสแนปชอตเพื่อหลีกเลี่ยงการใช้โวลุ่มดั้งเดิมออฟไลน์


สิ่งใดก็ตามที่ทำงานในระดับบล็อกไม่ใช่ระดับระบบไฟล์อาจเป็นการปรับปรุงครั้งใหญ่
Marcin

อย่างที่คุณเห็นในคำถามของฉันฉันต้องสะท้อนผ่านเครือข่ายไม่ใช่เฉพาะที่ LVM ยังไม่ใช่กระจกมันเป็นแค่ภาพรวม
โทมัสเบอร์เกอร์

1
@Thomas Berger: ความคิดของฉันคือการที่คุณจะคัดลอก snapshot (ใช้ rsync) ผ่านเครือข่าย และคุณจะกำหนดมิร์เรอร์อย่างไรถ้าภาพรวมของ LVM ไม่ใช่หนึ่ง?
เท็ดดี้

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

@Thomas Berger: ตอนแรกฉันหมายถึงว่าคุณจะซิงค์ปริมาณสแนปชอตจริงไม่ใช่ระบบไฟล์ในสแน็ปช็อต อย่างไรก็ตามตอนนี้ฉันเชื่อว่าโซลูชัน snapshot + dump จะดีกว่า
เท็ดดี้
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.