Sự cố Production lúc 2 giờ sángBạn nhận được một cảnh báo giám sát nghiêm trọng: một cơ sở dữ liệu hoặc ứng dụng đã ngừng hoạt động. Bạn đăng nhập vào máy chủ, cố gắng kiểm tra thư mục dữ liệu và terminal trả về một thông báo khó hiểu:
ls: cannot access '/data/mysql': Structure needs cleaning
Lỗi này—về mặt kỹ thuật là EUCLEAN—là một biện pháp bảo vệ. Nó có nghĩa là hệ thống file đã phát hiện sự hư hỏng metadata nghiêm trọng đến mức nó tự khóa lại để ngăn chặn việc mất dữ liệu thêm. Điều này thường xảy ra sau khi mất điện đột ngột, sự cố kết nối SAN, hoặc ổ cứng vật lý bị hỏng vào thời điểm tồi tệ nhất.
Bước 1: Xác định chính xác phân vùng bị hỏngĐừng đoán mò ổ đĩa nào đang bị lỗi. Bạn cần xem log của kernel để biết chính xác chuyện gì đã xảy ra. Chạy lệnh sau để xem các sự kiện hệ thống gần nhất:
dmesg | grep -Ei 'xfs|ext4|error' | tail -n 20
Bạn đang tìm kiếm các địa chỉ phần cứng hoặc mount point cụ thể. Một lỗi điển hình có thể trông như thế này: XFS (sdb1): Internal error xfs_trans_cancel at line 984. Khi bạn thấy tên thiết bị (ví dụ: /dev/sdb1), hãy xác nhận mount point của nó:
df -h | grep /dev/sdb1
Bước 2: Unmount phân vùng mục tiêuCố gắng sửa chữa một hệ thống file đang được mount là cách nhanh nhất dẫn đến việc hủy hoại dữ liệu hoàn toàn. Bạn phải đưa phân vùng về trạng thái ngoại tuyến trước. Nếu đó là ổ đĩa dữ liệu, hãy dừng các dịch vụ liên quan (như Nginx hoặc MySQL) và unmount nó:
sudo umount /dev/sdb1
Nếu hệ thống báo thiết bị đang bận (busy), hãy xác định các tiến trình đang sử dụng nó bằng lsof hoặc fuser:
sudo fuser -mv /mnt/data_folder
Dừng các tiến trình đó và thử unmount lại. Nếu ổ đĩa là phân vùng gốc (/), bạn sẽ cần khởi động từ Live ISO hoặc vào Chế độ cứu hộ (Rescue Mode).
Bước 3: Sửa lỗi XFS (Trường hợp phổ biến nhất)XFS là hệ thống file mặc định cho RHEL, Rocky và CentOS. Nếu đĩa của bạn sử dụng XFS, xfs_repair là công cụ chính của bạn. Hãy bắt đầu với một nỗ lực sửa chữa tiêu chuẩn:
sudo xfs_repair /dev/sdb1
Khi Log ở trạng thái 'Dirty'Nếu hệ thống bị sập gần đây, xfs_repair có thể từ chối chạy. Nó sẽ báo cho bạn biết log chứa dữ liệu chưa được ghi và gợi ý mount ổ đĩa để 'replay' lại. Nếu việc mount thất bại, bạn sẽ bị kẹt. Trong tình huống cụ thể này, bạn có thể cần đến cờ 'Cứu cánh cuối cùng':
sudo xfs_repair -L /dev/sdb1
Cờ -L (Force Log Zeroing) sẽ xóa sạch log của hệ thống file. Điều này giúp phân vùng hoạt động trở lại nhưng có thể phải hy sinh vài giây dữ liệu cuối cùng được ghi trước khi gặp sự cố. Chỉ sử dụng lệnh này nếu việc sửa chữa tiêu chuẩn thất bại.
Bước 4: Sửa lỗi hệ thống file ext4Đối với các hệ thống Ubuntu hoặc Debian sử dụng ext4, hãy sử dụng tiện ích fsck để thay thế. Cờ -f là cần thiết để bắt buộc kiểm tra ngay cả khi hệ thống file tự đánh dấu là 'sạch' (clean):
sudo fsck.ext4 -fy /dev/sdb1
Cờ -y tự động trả lời 'yes' cho mọi lời nhắc sửa chữa. Điều này rất hữu ích vì một ổ đĩa ext4 bị hỏng nặng có thể kích hoạt hàng trăm lời nhắc sửa lỗi riêng lẻ.
Bước 5: Xác minh và Mount lạiSau khi công cụ sửa chữa báo cáo thành công, hãy thử mount lại ổ đĩa. Kiểm tra nội dung thư mục để đảm bảo các file của bạn đã hiển thị:
sudo mount /dev/sdb1 /mnt/data_folder
ls -la /mnt/data_folder
Hãy theo dõi dmesg trong vài phút tới. Nếu lỗi quay trở lại ngay lập tức, khả năng cao là phần cứng bên dưới đang bị hỏng.