Changes between Version 1 and Version 2 of Rezervni_kopii_i_PITR

Timestamp:

04/29/26 14:52:30 (3 days ago)

Author:

213192

Comment:

--

Rezervni_kopii_i_PITR

@@ -75 +75 @@
 * поголем ризик ако недостасува еден backup
 
-== Logical vs Physical Backup во PostgreSQL
-
-=== Logical Backup – pg_dump
-
-Logical backup работи на логичко ниво и ги извлекува податоците како SQL инструкции. 
-
-Карактеристики:
-* многу брз restore  
-* се користи за репликација и disaster recovery 
-* зависи од иста PostgreSQL верзија
-
-Предности:
-* најбрзо опоравување
-* погоден за production системи 
-
-Недостатоци:
-* помала флексибилност 
-* потребна е конфигурација на WAL 
-
-{{{
-pg_basebackup -U replication_user \ 
-
-  -D /backups/transfermarkt_base \ 
-
-  -Fp -Xs –P 
-
-systemctl start postgresql 
-
-При restore(server crash) 
-}}}
-
-Предложена стратегија за нашата база е да правиме дневен full backup и hourly WAL backup. 
 
 == Point In Time Recovery (PITR)
@@ -140 +108 @@
 
 Point-In-Time Recovery претставува еден од најмоќните механизми за заштита на податоци во PostgreSQL. Комбинирањето на physical backup со continuous WAL archiving овозможува системот да се врати во стабилна состојба по било каква логичка грешка.
+
+== Примери
+
+1. Partial Transaction Corruption во Transfermarkt систем
+
+Во рамки на Transfermarkt базата, постојат повеќе меѓусебно поврзани табели кои ја моделираат логиката на трансфер на играчи: players, clubs и transfers на пример. Процесот на трансфер на играч вклучува повеќе чекори кои треба да се извршат како една атомска операција:
+
+-Се ажурира club_id во табелата players
+-Се намалува budget кај новиот клуб
+-Се додава запис во табелата transfers
+
+Овие операции логички претставуваат една трансакција.
+
+При извршување на трансакцијата, се случил пад на апликацијата и player_club_id е успешно ажуриран, но запис во transfers табелата нема и budget не е ажуриран. Поради ова, базата влегува во неконзистентна состојба, каде играчот е доделен на нов клуб но нема евиденција за трансферот. Наша цел е да ја вратиме базата во првобитната состојба, без да ги изгубиме другите валидни податоци.
+
+-Најпрво, преку логови, ќе го утврдиме точниот момент кога се случил проблемот.
+-Потоа ќе креираме нова база (recovery):
+{{{
+createdb transfermarkt_debug
+}}}
+-PITR: конфигурираме враќање на состојбата непосредно пред грешката:
+{{{
+recovery_target_time = '2026-04-29 16:22:09'
+}}}
+Со ова PostgreSQL ќе ги репродуцира WAL записите се до моментот пред неуспешната трансакција.
+-Потоа ги споредуваме податоците и ја бараме разликата:
+{{{
+-- Неконзистентна состојба (production)
+SELECT * FROM players WHERE id = 101;
+
+-- Конзистентна состојба (recovery)
+SELECT * FROM players WHERE id = 101;
+}}}
+-Преку рачна поправка, наместо целосно враќање на базата, ја враќаме во првобитната состојба со едно query:
+{{{
+UPDATE players
+SET club_id = <старa вредност>
+WHERE id = 101;
+}}}
+
+Со овој едноставен процес ја добивме старата конзистентност на базата и не изгубивме други валидни податоци. Овој пример покажува дека не е секогаш добра опција да се врати цела база, туку понекогаш во комплексни системи е подобро да се користи селективен пристап. Ваков тип на опоравување е важен во системи со чести трансакции и голем број на корисници.
+
+2. Silent Data Corruption (Trigger Bug)
+
+Во оваа база се користат тригери кои вршат автоматизација на одредени полиња по извршување на трансфери. Еден ваков пример е тригер кој треба да ја зголеми вредноста на играчот за 10% (x1.1) по секој трансфер:
+
+{{{
+CREATE TRIGGER update_value
+AFTER UPDATE ON transfers
+}}}
+
+Сепак, се случила грешка и системот наместо *1,1 го множи со *2. Овој bug не се приметува одма, но грешките кои произлегуваат од него се штетни на долгорочен период. За да ја решиме оваа грешка, најпрво ќе се вратиме пред започнување на trigger bug. 
+
+-Кога ќе го откриеме моментот кога triggerот почнал да работи погрешно, креираме recovery база:
+{{{
+createdb transfermarkt_recovery
+}}}
+
+{{{
+recovery_target_time = '2026-04-29 09:00:00'
+}}}
+
+-Дури тогаш почнува recovery процесот. По овој процес market_value е вратен во реални вредности и нема последователни cascade грешки. Ова е пример за една од најопасните категории на грешки во базите на податоци - Silent data corruption, поради тоа што немаат crash, немаат error message и системот си работи нормално. Во системот на Transfermarkt една ваква грешка може да доведе до уништување на статистиката за цела сезона.
+
+3. Huge Data Growth
+
+Transfermarkt системот претставува голема и брзорастечка база на податоци која содржи players, matches, transfers - табели кои од ден во ден се повеќе и повеќе растат.
+
+Ако користиме класичен full logical backup:
+{{{
+pg_dump transfermarkt > full.sql
+}}}
+се појавуваат следниве проблеми:
+-backup трае 4 часа 
+-се користи голем storage простор
+-процесот не е скалабилен за дневно извршување
+
+Затоа ќе користиме комбинирана backup стратегија од full physical backup + incremental backup (WAL)
+
+-Weekly Full Backup: Се прави целосна копија од базата еднаш неделно:
+{{{
+pg_basebackup -U replication_user \
+-D /backup/base_weekly \
+-Fp -Xs -P
+}}}
+Овој backup претставува starting point за recovery.
+
+-WAL Archiving (Incremental backup): Се активира continuous logging на сите промени во базата:
+{{{
+archive_mode = on
+archive_command = 'cp %p /wal_archive/%f'
+}}}
+Ова овозможува секоја промена во базата да биде зачувана во WAL логови.
+
+Сега да видиме едно recovery сценарио ако во четврток се случи crash на системот. Процесот на recovery е:
+-Се враќа последниот full backup (неделниот snapshot)
+-Се replay-ираат WAL логовите од понеделник до четврток
+-Базата се враќа во последната конзистентна состојба
+
+Овој пример покажува дека Full backup сам по себе не е доволен за големи системи, Incremental (WAL-based) backup е неопходен за production средини и дека комбинацијата од двата пристапи овозможува баланс помеѓу перформанси и сигурност.
+
+