Перевірка цілісності даних після відновлення

Відновлення бази — це не завжди просто: наче все пройшло успішно, але потім у логах з’являються помилки, якісь таблиці зникають або дані виглядають підозріло. Ось чому так важливо після відновлення обов’язково перевірити, чи все дійсно окей.

Іноді частина даних може просто не відновитись — наприклад, якщо резервна копія виявилась пошкодженою. Буває, що структура таблиць збивається: зникають зовнішні ключі, пропадають індекси або з’являються дивні значення. І навіть якщо на перший погляд все виглядає нормально, логи можуть натякати, що база насправді не зовсім здорова.

Перевірка цілісності — це як техогляд після ремонту. Краще витратити трохи часу і впевнитися, що все працює, ніж потім раптово зіткнутися з проблемою у продакшені.

Аналіз логів відновлення

Коли ти відновлюєш дані за допомогою pg_restore, PostgreSQL обов’язково генерує лог. Лог містить багато корисної інфи про процес відновлення, включаючи попередження і помилки. Ось приклад команди з вказанням файлу для логів:

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

Зверни увагу на > restore_log.txt 2>&1 — це перенаправляє як стандартний вивід, так і помилки в один файл.

Що шукати у логах?

1. Помилки. Звертай увагу на ключові слова типу "ERROR" або "FATAL". Приклад:

   ERROR:  relation "students" does not exist
   

2. Попередження. Іноді ти можеш побачити попередження "WARNING". Хоч вони і не критичні, все ж варто їх прочитати — можливо, вони сигналізують про проблеми:

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

3. Неспівпадіння даних. Перевір, чи відновились всі ключові об’єкти: таблиці, індекси, зовнішні ключі.

Швидка перевірка за допомогою grep

Якщо файл логів занадто довгий (а вони бувають довгі як "Війна і мир"), ти можеш використати grep, щоб шукати ключові слова:

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

Розбір помилок з логів

Давай подивимось на реальний приклад з лога:

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

Що ця помилка нам каже? Вона означає, що PostgreSQL намагається відновити рядок у таблиці enrollments, але для нього не існує відповідного course_id у таблиці courses.

Як вирішити? Можливо, дані у таблиці courses були пошкоджені або не відновились. Тобі доведеться або вручну додати відсутні рядки, або повторити відновлення.

Використання контрольних сум для перевірки цілісності

Якщо ти хочеш бути впевненим, що файл резервної копії не пошкоджений до чи після відновлення, можеш використати контрольні суми.

Контрольна сума — це маленьке число, яке представляє дані у файлі. Якщо файл змінюється хоча б на один біт, його контрольна сума теж зміниться. Це допомагає визначити, чи був файл пошкоджений.

Для створення контрольної суми можна використати утиліту md5sum. Ось приклад команди:

md5sum backup_file.dump

Результат буде виглядати так:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Порівняння контрольних сум

Якщо ти заздалегідь записав контрольну суму файлу, можеш порівняти її з поточною:

md5sum -c checksum.md5

Файл checksum.md5 має містити рядок з контрольною сумою і ім’ям файлу:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Якщо контрольна сума співпадає, ти побачиш повідомлення OK. Якщо ні — файл пошкоджений.

Перевірка даних на рівні бази

Контрольні суми і логи — це круто, але як перевірити, що самі дані окей? Ось список стандартних дій:

1. Порівняння кількості рядків

Порівняй кількість рядків у таблицях до і після відновлення. Наприклад:

-- Підрахунок кількості рядків у таблиці students
SELECT COUNT(*) FROM students;

Якщо кількість рядків відрізняється, відновлення пройшло не повністю.

2. Перевірка цілісності ключів

Віднови зв’язки між таблицями, щоб впевнитися, що всі зовнішні ключі працюють:

-- Перевірка студентів, записаних на курси
SELECT *
FROM enrollments e
LEFT JOIN courses c
ON e.course_id = c.course_id
WHERE c.course_id IS NULL;

Якщо запит повертає результат, значить, у таблиці enrollments є рядки з відсутніми курсами.

3. Порівняння даних з оригіналом

Якщо у тебе є копія даних (наприклад, дамп іншої бази), ти можеш порівняти вибірки:

-- Перевірка даних з таблиці courses
SELECT * FROM courses WHERE course_id NOT IN (
  SELECT course_id FROM courses_backup
);

Реальні кейси відновлення

Випадок з практики: якось адміністратор СУБД Bob вирішив відновити дані з резервної копії після збою сервера. Він виконав команду:

pg_restore -U admin -d my_database my_backup.dump

Але при аналізі логів відновлення завершилось помилкою:

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

Це означало, що на диску закінчилось місце. Після звільнення дискового простору і повторного відновлення даних він також виявив, що не всі таблиці були відновлені. На щастя, завдяки заздалегідь згенерованим контрольним сумам і налаштуванню WAL архівації Bob зміг повністю відновити базу даних.

Підсумки перевірки цілісності

На завершення перевірки цілісності даних після відновлення зроби наступне:

1. Перевір логи на наявність помилок і попереджень.
2. Використовуй контрольні суми, щоб впевнитися у відсутності пошкоджень файлів.
3. Порівняй дані бази на кількість рядків і цілісність зв’язків.
4. Якщо щось пішло не так, досліди помилки і повтори процес відновлення.

Тепер ти повністю готовий провести ретельну перевірку і впевнитися, що дані відновлені саме так, як ти і очікував. Бо головне у справі адміністрування баз даних — це впевненість у своїй резервній копії!