Kiểm tra tính toàn vẹn dữ liệu sau khi phục hồi

Phục hồi database — không phải lúc nào cũng dễ: tưởng như mọi thứ đã xong, nhưng rồi trong log lại hiện lỗi, một số bảng biến mất hoặc dữ liệu trông kỳ lạ. Đó là lý do tại sao sau khi phục hồi, nhất định phải kiểm tra xem mọi thứ có thực sự ổn không.

Đôi khi một phần dữ liệu có thể không phục hồi được — ví dụ, nếu file backup bị lỗi. Có lúc cấu trúc bảng bị lệch: khóa ngoại biến mất, index không còn hoặc xuất hiện giá trị lạ. Và kể cả khi nhìn qua thì mọi thứ có vẻ ổn, log vẫn có thể báo hiệu database thực ra chưa hoàn toàn khỏe mạnh.

Kiểm tra tính toàn vẹn — giống như kiểm tra xe sau khi sửa. Tốt hơn là dành chút thời gian để chắc chắn mọi thứ chạy ổn, còn hơn là bất ngờ gặp sự cố trên production.

Phân tích log phục hồi

Khi bạn phục hồi dữ liệu bằng pg_restore, PostgreSQL chắc chắn sẽ tạo log. Log chứa nhiều thông tin hữu ích về quá trình phục hồi, bao gồm cảnh báo và lỗi. Đây là ví dụ lệnh chỉ định file log:

pg_restore -U username -d database_name backup_file.dump > restore_log.txt 2>&1

Lưu ý > restore_log.txt 2>&1 — cái này sẽ chuyển cả output chuẩn và lỗi vào một file.

Tìm gì trong log?

1. Lỗi. Để ý các từ khóa như "ERROR" hoặc "FATAL". Ví dụ:

   ERROR:  relation "students" does not exist
   

2. Cảnh báo. Đôi khi bạn sẽ thấy cảnh báo "WARNING". Dù không nghiêm trọng, vẫn nên đọc — có thể nó báo hiệu vấn đề:

   WARNING:  no privileges could be granted for table "grades"
   

3. Không khớp dữ liệu. Kiểm tra xem các đối tượng chính đã phục hồi chưa: bảng, index, khóa ngoại.

Kiểm tra nhanh bằng grep

Nếu file log quá dài (có khi dài như "Chiến tranh và hòa bình"), bạn có thể dùng grep để tìm từ khóa:

grep -i "error" restore_log.txt
grep -i "warning" restore_log.txt

Giải thích lỗi từ log

Cùng xem ví dụ thực tế từ log:

ERROR:  constraint "fk_student_course" for relation "enrollments" does not exist
DETAIL:  Key (course_id)=(2) is not present in table "courses".

Lỗi này nói gì? Nó nghĩa là PostgreSQL đang cố phục hồi một dòng trong bảng enrollments, nhưng không có course_id tương ứng trong bảng courses.

Giải quyết sao? Có thể dữ liệu trong bảng courses bị lỗi hoặc chưa phục hồi. Bạn sẽ phải tự thêm dòng thiếu hoặc phục hồi lại.

Dùng checksum để kiểm tra toàn vẹn

Nếu bạn muốn chắc chắn file backup không bị lỗi trước hoặc sau khi phục hồi, bạn có thể dùng checksum.

Checksum — là một số nhỏ đại diện cho dữ liệu trong file. Nếu file thay đổi dù chỉ một bit, checksum cũng sẽ khác. Cái này giúp phát hiện file có bị lỗi không.

Để tạo checksum, dùng tool md5sum. Ví dụ lệnh:

md5sum backup_file.dump

Kết quả sẽ như này:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

So sánh checksum

Nếu bạn đã ghi lại checksum của file, bạn có thể so với hiện tại:

md5sum -c checksum.md5

File checksum.md5 nên chứa dòng checksum và tên file:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Nếu checksum khớp, bạn sẽ thấy thông báo OK. Nếu không — file bị lỗi.

Kiểm tra dữ liệu ở mức database

Checksum và log thì tốt, nhưng làm sao kiểm tra chính dữ liệu có ổn không? Đây là danh sách thao tác chuẩn:

1. So sánh số dòng

So sánh số dòng trong bảng trước và sau khi phục hồi. Ví dụ:

-- Đếm số dòng trong bảng students
SELECT COUNT(*) FROM students;

Nếu số dòng khác nhau, phục hồi chưa đủ.

2. Kiểm tra toàn vẹn khóa

Kiểm tra liên kết giữa các bảng để chắc chắn tất cả khóa ngoại hoạt động:

-- Kiểm tra sinh viên đã đăng ký khóa học
SELECT *
FROM enrollments e
LEFT JOIN courses c
ON e.course_id = c.course_id
WHERE c.course_id IS NULL;

Nếu truy vấn trả về kết quả, nghĩa là trong bảng enrollments có dòng không có khóa học tương ứng.

3. So sánh dữ liệu với bản gốc

Nếu bạn có bản sao dữ liệu (ví dụ, dump của database khác), bạn có thể so sánh kết quả truy vấn:

-- Kiểm tra dữ liệu từ bảng courses
SELECT * FROM courses WHERE course_id NOT IN (
  SELECT course_id FROM courses_backup
);

Case thực tế phục hồi

Chuyện thực tế: một lần DBA Bob quyết định phục hồi dữ liệu từ backup sau khi server bị lỗi. Anh ấy chạy lệnh:

pg_restore -U admin -d my_database my_backup.dump

Nhưng khi phân tích log, phục hồi báo lỗi:

ERROR:  could not create file "base/16385/pg_internal.init": No space left on device

Nghĩa là ổ cứng hết chỗ. Sau khi giải phóng dung lượng và phục hồi lại, anh ấy cũng phát hiện không phải tất cả bảng đều được phục hồi. May mắn là nhờ đã tạo checksum trước và bật WAL archive, Bob đã phục hồi hoàn toàn database.

Tổng kết kiểm tra toàn vẹn

Kết thúc kiểm tra tính toàn vẹn dữ liệu sau phục hồi, hãy làm những việc sau:

1. Kiểm tra log xem có lỗi và cảnh báo không.
2. Dùng checksum để chắc file không bị lỗi.
3. So sánh dữ liệu database về số dòng và toàn vẹn liên kết.
4. Nếu có vấn đề, phân tích lỗi và phục hồi lại.

Bây giờ bạn đã sẵn sàng kiểm tra kỹ càng và chắc chắn dữ liệu được phục hồi đúng như mong đợi. Vì điều quan trọng nhất khi quản trị database — là tự tin vào bản backup của mình!