Bərpadan sonra məlumatların bütövlüyünün yoxlanılması

Bazanın bərpası həmişə asan olmur: hər şey uğurla keçdi kimi görünür, amma sonra loglarda səhvlər çıxır, bəzi cədvəllər yoxa çıxır və ya məlumatlar qəribə görünür. Ona görə də bərpadan sonra mütləq yoxlamaq lazımdır ki, hər şey həqiqətən qaydasındadırmı.

Bəzən məlumatların bir hissəsi sadəcə bərpa olunmur — məsələn, backup faylı zədələnibsə. Elə olur ki, cədvəllərin strukturu pozulur: xarici açarlar yoxa çıxır, indekslər itir və ya qəribə dəyərlər yaranır. Hətta hər şey normal görünürsə belə, loglar baza ilə bağlı problemlərə işarə edə bilər.

Bütövlüyün yoxlanılması — təmir sonrası texniki baxış kimidir. Bir az vaxt ayırıb hər şeyin işlədiyinə əmin olmaq daha yaxşıdır, nəinki prod-da qəfil problemə rast gəlmək.

Bərpa loglarının analizi

Əgər pg_restore ilə məlumatları bərpa edirsənsə, PostgreSQL mütləq log yaradır. Logda bərpa prosesi ilə bağlı bir çox faydalı info olur, o cümlədən xəbərdarlıqlar və səhvlər. Log faylını göstərməklə komanda nümunəsi belədir:

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

> restore_log.txt 2>&1 hissəsinə fikir ver — bu həm standart çıxışı, həm də səhvləri bir fayla yönləndirir.

Loglarda nəyə baxmalı?

1. Səhvlər. "ERROR" və ya "FATAL" kimi açar sözlərə fikir ver. Məsələn:

   ERROR:  relation "students" does not exist
   

2. Xəbərdarlıqlar. Bəzən "WARNING" xəbərdarlıqları görəcəksən. Onlar kritik olmasa da, oxumaq lazımdır — bəlkə hansısa problemə işarə edir:

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

3. Məlumat uyğunsuzluqları. Əsas obyektlərin bərpa olunub-olunmadığını yoxla: cədvəllər, indekslər, xarici açarlar.

grep ilə tez yoxlama

Əgər log faylı çox uzundursa (bəzən "Müharibə və Sülh" qədər olur), grep ilə açar sözləri axtara bilərsən:

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

Loglardan səhvlərin təhlili

Gəlin logdan real bir nümunəyə baxaq:

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

Bu səhv bizə nə deyir? Bu o deməkdir ki, PostgreSQL enrollments cədvəlinə sətir bərpa etməyə çalışır, amma uyğun course_id courses cədvəlində yoxdur.

Necə həll etməli? Ola bilər ki, courses cədvəlindəki məlumatlar zədələnib və ya bərpa olunmayıb. Ya əskik sətirləri əl ilə əlavə etməlisən, ya da bərpanı təkrarlamalısan.

Bütövlüyü yoxlamaq üçün checksum-lardan istifadə

Backup faylının bərpadan əvvəl və ya sonra zədələnmədiyinə əmin olmaq istəyirsənsə, checksum istifadə edə bilərsən.

Checksum — fayldakı məlumatları təmsil edən kiçik bir ədəddir. Faylda bir bit belə dəyişsə, checksum da dəyişir. Bu, faylın zədələnib-zədələnmədiyini yoxlamağa kömək edir.

Checksum yaratmaq üçün md5sum utilitindən istifadə edə bilərsən. Komanda nümunəsi:

md5sum backup_file.dump

Nəticə belə görünəcək:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Checksum-ların müqayisəsi

Əvvəlcədən faylın checksum-u yazılıbsa, onu indiki ilə müqayisə edə bilərsən:

md5sum -c checksum.md5

checksum.md5 faylında checksum və fayl adı olan sətir olmalıdır:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Checksum uyğun gəlirsə, OK mesajı görəcəksən. Yoxdursa — fayl zədələnib.

Baza səviyyəsində məlumatların yoxlanılması

Checksum və loglar yaxşıdır, amma məlumatların özü qaydasındadırmı? Standart yoxlama addımları bunlardır:

1. Sətir sayının müqayisəsi

Cədvəllərdəki sətir sayını bərpadan əvvəl və sonra müqayisə et. Məsələn:

-- students cədvəlində sətir sayının hesablanması
SELECT COUNT(*) FROM students;

Əgər sətir sayı fərqlidirsə, bərpa tam olmayıb.

2. Açarların bütövlüyünün yoxlanılması

Cədvəllər arası əlaqələri yoxla ki, bütün xarici açarlar işləyir:

-- Kurslara yazılmış tələbələrin yoxlanılması
SELECT *
FROM enrollments e
LEFT JOIN courses c
ON e.course_id = c.course_id
WHERE c.course_id IS NULL;

Əgər sorğu nəticə qaytarırsa, enrollments cədvəlində mövcud olmayan kurslara aid sətirlər var.

3. Məlumatların orijinal ilə müqayisəsi

Əgər məlumatların surəti varsa (məsələn, başqa bazanın dump-u), seçimləri müqayisə edə bilərsən:

-- courses cədvəlindəki məlumatların yoxlanılması
SELECT * FROM courses WHERE course_id NOT IN (
  SELECT course_id FROM courses_backup
);

Real bərpa case-ləri

Praktikadan bir hal: bir dəfə DB admin Bob serverdə nasazlıqdan sonra backup-dan məlumatları bərpa etmək qərarına gəldi. O, bu komandadan istifadə etdi:

pg_restore -U admin -d my_database my_backup.dump

Amma logların analizində bərpa səhvlə bitdi:

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

Bu o demək idi ki, diskdə yer qalmayıb. Diskdə yer boşaldıb bərpanı təkrarladıqdan sonra Bob gördü ki, bütün cədvəllər bərpa olunmayıb. Xoşbəxtlikdən, əvvəlcədən yaradılmış checksum-lar və WAL arxivləşdirmə sayəsində Bob bazanı tam bərpa edə bildi.

Bütövlüyün yoxlanılmasının yekunu

Bərpadan sonra məlumatların bütövlüyünü yoxlamaq üçün bunları et:

1. Logları səhv və xəbərdarlıqlara görə yoxla.
2. Checksum-lardan istifadə et ki, fayllarda zədə yoxdur.
3. Bazadakı məlumatları sətir sayı və əlaqələrin bütövlüyü üzrə müqayisə et.
4. Nəsə düz getmirsə, səhvləri araşdır və bərpa prosesini təkrarla.

İndi sən tam hazır vəziyyətdəsən ki, hərtərəfli yoxlama aparıb məlumatların gözlədiyin kimi bərpa olunduğuna əmin olasan. Axı database admin işində əsas məsələ — backup-una güvənməkdir!