Hồ Sơ MongoShard: Sao Lưu Percona Backup (PBM) Lên S3 & Khôi Phục Từng Giây (PITR)
Trong hướng dẫn sao lưu của MongoShard, chúng tôi giải thích lý do chạy cron mongodump trên Node Primary làm trôi bộ đệm WiredTiger — và cách dùng pbm-agent cắt lát PITR từ Node Secondary đẩy thẳng lên S3.
Bảo Vệ Bộ Đệm Trên MongoShard: Ngăn Chặn Tràn Dữ Liệu Lạnh Vào WiredTiger Lúc Sao Lưu Đêm
Chạy lệnh mongodump truyền thống trực tiếp vào Node Primary buộc mongod quét toàn bộ dữ liệu lịch sử đã nguội từ ổ cứng nạp qua RAM, đẩy các trang BSON nóng ra khỏi bộ nhớ đệm và gây tăng vọt IOPS đọc. Khi cài đặt Percona Backup for MongoDB (pbm-agent) trên toàn cụm Replica Set, chúng tôi để hệ thống tự chọn một Node Secondary khỏe mạnh (hoặc Node ẩn priority: 0) thực hiện nén Zstd và cắt lát Oplog mỗi 10 phút tải lên kho S3.
Mẫu Cấu Hình /etc/pbm_config.yaml Kết Nối S3 & PITR Chuẩn MongoShard
Cấu hình mẫu MongoShard cho hồ sơ percona-backup-mongodb-s3 — kiểm tra lại thông số RAM trước khi khởi động mongod.
# /etc/pbm_config.yaml — Nạp toàn cụm qua lệnh: pbm config --file /etc/pbm_config.yaml
pitr:
enabled: true
oplogSpanMin: 10
compression: zstd
storage:
type: s3
s3:
region: sg-sin-1
endpointUrl: https://sgp1.vultrobjects.com
bucket: mongoshard-prod-pbm
prefix: rs0-prod
credentials:
access-key-id: "THAY_KHOA_TRUY_CAP_S3"
secret-access-key: "THAY_KHOA_BI_MAT_S3"
backup:
compression: zstd
compressionLevel: 6Bảng Quy Chiếu Bậc RAM & Hạ Tầng MongoShard Cho HỒ SƠ 04 • SAO LƯU NHẤT QUÁN & KHÔI PHỤC PITR LÊN S3 (2026-11-12)
Các mốc cấu hình dưới đây được tính toán xác định theo công thức (RAM − 1 GB) × 0.50 của MongoShard và tham chiếu biểu phí công khai ngày 2026-11-12 từ Vultr (https://www.vultr.com/pricing/) cùng InterServer (https://www.interserver.net/vps/).
| Quy Mô Cụm / Bậc Máy Chủ | WiredTiger Cache | Dung Lượng Đáp Ứng | Cấu Hình Tham Chiếu (2026-11-12) |
|---|---|---|---|
| Cơ sở dữ liệu 25 GB (Logical + PITR) | ~9 GB nén Zstd trên S3 | 1-Node rs0 hoặc 3-Node KVM | Hostinger KVM + S3 Object Storage |
| Cơ sở dữ liệu 150 GB (Physical PBM) | ~55 GB nén Zstd trên S3 | Chép trực tiếp tệp .wt | Vultr VPC + Vultr Objects Nội Khu |
| Cơ sở dữ liệu 500 GB+ (Node Ẩn Riêng) | ~185 GB nén Zstd trên S3 | 0% tranh chấp đọc trên Primary | UltaHost VDS + InterServer Storage |
Danh Sách Kiểm Tra Triển Khai Sản Xuất MongoShard (PBM-PITR-BACKUP)
- Chạy dịch vụ systemd pbm-agent đồng bộ cùng phiên bản trên tất cả các thành viên thuộc cụm Replica Set.
- Ưu tiên chế độ Physical Backup (--type=physical) trên Percona Server khi dữ liệu vượt 100 GB để không phải dựng lại cây B-Tree lúc khôi phục.
- Lập lịch pbm cleanup --older-than=14d -y hàng tuần nhằm dọn sạch các mảnh Oplog quá hạn trên kho S3.
- Thực hiện diễn tập khôi phục định kỳ hàng tháng sang một máy chủ KVM độc lập để xác nhận tính toàn vẹn dữ liệu.
Xem Gói Vultr Cho Hồ Sơ PBM-PITR-BACKUP Trên MongoShard ↗ Đối Chiếu Thêm InterServer Cho PBM-PITR-BACKUP Trên MongoShard ↗ Nạp Cấu Hình Này Vào Bộ Tính MongoShard →
Câu Hỏi Kỹ Thuật MongoShard: HỒ SƠ 04 • SAO LƯU NHẤT QUÁN & KHÔI PHỤC PITR LÊN S3
Tại sao công cụ tính MongoShard luôn gắn liền số giờ lưu Oplog với cấu hình PBM PITR?
Cơ chế PITR cắt lát bảng local.oplog.rs mỗi 10 phút đẩy lên S3. Nếu đường truyền tới S3 tạm gián đoạn đúng lúc tải ghi tăng vọt, vòng đệm Oplog NVMe rộng 48h–72h tại chỗ sẽ giữ an toàn chuỗi sự kiện cho đến khi pbm-agent đồng bộ kịp.
Với cụm WiredTiger nặng trên 200 GB, MongoShard khuyến nghị chế độ sao lưu nào?
Từ ngưỡng 100–150 GB trở lên, chúng tôi khuyên dùng Physical Backup trên Percona Server for MongoDB vì quá trình khôi phục chép thẳng tệp vật lý .wt thay vì chèn lại từng tài liệu BSON và đánh lại toàn bộ Index.