Jednym z najbardziej oczekiwanych nowych mechanizmów serwera PostgreSQL 17 jest funkcja wykonywania przyrostowych kopii bezpieczeństwa. Umożliwia ona redukcję rozmiaru codziennej fizycznej kopii bezpieczeństwa dzięki uwzględnianiu wyłącznie tych bloków danych, które uległy zmianom od czasu wykonania wcześniejszej kopii bezpieczeństwa. Może to skutkować mniejszym zużyciem pamięci dyskowej oraz krótszym czasem wykonywania.
Należy pamiętać, że aby możliwe było wykonywanie przyrostowych kopii bezpieczeństwa w systemie PostgreSQL 17, niezbędne jest uprzednie aktywowanie procesu WAL Summarizer (parametr summarize_wal = on), który na bieżąco rejestruje w plikach WAL Summary informacje o numerach zmienianych bloków danych. Pliki WAL Summary są przechowywane (przez czas wal_summary_keep_time) w katalogu $PGDATA/pg_wal/summaries i służą do identyfikacji bloków, które muszą być uwzględnione w przyrostowej kopii bezpieczeństwa.
Aby przyrostowa fizyczna kopia bezpieczeństwa mogła być wykorzystana w procesie odtwarzania po awarii, należy ją scalić z wcześniejszą pełną kopią bezpieczeństwa – do tego celu służy nowe narzędzie pg_combinebackup, które „dokleja” do pełnej kopii bezpieczeństwa wszystkie zmienione bloki danych.
Dziś zademonstrujemy wyniki eksperymentów wydajnościowych przeprowadzonych w środowisku serwera bazy danych PostgreSQL, porównujących rozmiary i czasy realizacji kopii bezpieczeństwa oraz odtwarzania bazy danych dla różnych strategii (kopie pełne, kopie przyrostowe). Zwrócimy uwagę na to, jak ilość zmian pojawiających się każdego dnia w bazie danych może uzasadnić sens stosowania strategii przyrostowych.
Środowisko eksperymentalne składa się z bazy danych o rozmiarze około 2 GB, wygenerowanej narzędziem pgbench:
pgbench -i -U postgres -s 135 test
Do symulacji codziennej aktywności użytkowników również wykorzystamy pgbench:
# scenariusz 1: modyfikuje ok. 5% rekordów, dodaje ok. 5% rekordów
pgbench -b simple-update -c 10 -t 70000 test
# scenariusz 2: modyfikuje ok. 0.5% rekordów, dodaje ok. 0.5% rekordów
pgbench -b simple-update -c 10 -t 7000 test
Badane będą dwie strategie realizacji kopii bezpieczeństwa w cyklu tygodniowym. W ramach pierwszej strategii, każdego dnia wykonywana pełna kopia bezpieczeństwa poleceniem:
pg_basebackup -D daily_backup -c fast
Natomiast druga strategia przyjmuje, że w niedzielę wykonywana jest pełna kopia bezpieczeństwa, a w kolejne dni kopie przyrostowe różnicowe, poleceniami:
pg_basebackup -D sunday -c fast
pg_basebackup -D monday -i sunday/backup_manifest -c fast
pg_basebackup -D tuesday -i monday/backup_manifest -c fast
pg_basebackup -D wednesday -i tuesday/backup_manifest -c fast
pg_basebackup -D thursday -i wednesday/backup_manifest -c fast
pg_basebackup -D friday -i thursday/backup_manifest -c fast
pg_basebackup -D saturday -i friday/backup_manifest -c fast
Zmierzymy również czas odtwarzania bazy danych, odpowiednio dla każdej ze strategii. W pierwszym przypadku będzie to po prostu czas kopiowania fizycznej kopii bezpieczeństwa do katalogu Data Directory, a w drugim – czas scalenia pełnej fizycznej kopii bezpieczeństwa z sześcioma przyrostowymi kopiami bezpieczeństwa poleceniem:
pg_combinebackup -o new sunday monday tuesday wednesday thursday friday saturday
Wyniki pomiarów są przedstawione na poniższych wykresach. W przypadku względnie niedużej ilości dziennych modyfikacji danych (modyfikacja 1% danych), zastosowanie przyrostowych kopii bezpieczeństwa pozwala na wyraźne oszczędności czasu i przestrzeni dyskowej. W przypadku znacznych dziennych modyfikacji danych (modyfikacja 10% danych), przyrostowe kopie bezpieczeństwa mogą obejmować prawie wszystkie bloki danych, co nie daje korzyści w stosunku do pełnych kopii bezpieczeństwa. Z kolei zmierzone czasy odtwarzania bazy danych wynosiły: 0,02 s gdy wykorzystywane były pełne kopie bezpieczeństwa oraz ok. 20 sekund w przypadku kopii przyrostowych.
Podsumowując, przed wdrożeniem mechanizmu przyrostowych kopii bezpieczeństwa w PostgreSQL 17 warto przeprowadzić analizę korzyści w kontekście specyfiki własnego środowiska.