Używam Postgres 9.6 i wykonuję kopię zapasową raz na jakiś czas po prostu zatrzymując klaster i używając rsync na poziomie pliku. Pewnego dnia zauważyłem, że niektóre stare pliki, których kopie zapasowe są już zapisane w tabelach, mają ten sam rozmiar pliku i znacznik czasu, co ich odpowiednik w źródle, ale rsync próbuje wykonać ich kopię zapasową, ponieważ zawartość tych plików zmieniła się. Ważne jest, aby pamiętać, że w przypadku znaczników czasu w źródle pliki nie zmieniały się przez kilka dni lub nawet tygodni. rsync używa sum kontrolnych i obliczanie skrótów MD5 dla danych plików ujawnia również różne skróty. Oto jeden przykład:
Utworzyć kopię zapasową:
a1171645dc187c498ce05a25b0e5157f 2613.13
-rw------- 12 109 119 1073741824 May 21 04:58 2613.13
Produkcja:
f02c1c2724714af2c5c08f8b67ab0f11 2613.13
-rw------- 1 postgres postgres 1073741824 Mai 21 04:58 2613.13
Dokładnie ten sam plik dotyczący rozmiaru i znacznika czasu, ale w rzeczywistości innej zawartości. Po użyciu rsync z sumami kontrolnymi plik w kopii zapasowej ma ten sam rozmiar i znacznik czasu, ale nową zawartość, ponieważ tym razem obliczony skrót jest taki sam jak w produkcji.
Plik należy do pg_largeobject i ta tabela zawiera dużo
dane, stąd nazwane przyrostki. Większość z tych plików w sekwencji
mieć stare znaczniki czasu, takie jak powyżej, bez kilku dni
żadnych zapisów, a NIE wszystkie są zarchiwizowane i mają taki sam skrót MD5 jak
w mojej kopii zapasowej. Tylko kilka plików raz na jakiś czas różni się od tego w
przykład.
Z następujących bardzo starych plików danych, w większości niezmienionych przez kilka dni / tygodni, np. 2613.13 został przesłany z powodu różnych sum kontrolnych 2613.10 nie:
-rw------- 1 postgres postgres 1073741824 Jun 4 04:40 2613
-rw------- 1 postgres postgres 1073741824 Mai 21 04:42 2613.1
-rw------- 1 postgres postgres 1073741824 Mai 21 04:56 2613.10
-rw------- 1 postgres postgres 1073741824 Mai 21 04:57 2613.11
-rw------- 1 postgres postgres 1073741824 Mai 21 04:57 2613.12
-rw------- 1 postgres postgres 1073741824 Mai 21 04:58 2613.13
-rw------- 1 postgres postgres 1073741824 Mai 21 04:59 2613.14
-rw------- 1 postgres postgres 1073741824 Mai 28 04:40 2613.15
-rw------- 1 postgres postgres 686645248 Jun 4 04:42 2613.16
-rw------- 1 postgres postgres 1073741824 Mai 21 04:44 2613.2
-rw------- 1 postgres postgres 1073741824 Mai 21 04:46 2613.3
-rw------- 1 postgres postgres 1073741824 Mai 21 04:47 2613.4
-rw------- 1 postgres postgres 1073741824 Mai 21 04:49 2613.5
-rw------- 1 postgres postgres 1073741824 Mai 21 04:50 2613.6
-rw------- 1 postgres postgres 1073741824 Mai 21 04:52 2613.7
-rw------- 1 postgres postgres 1073741824 Mai 21 04:53 2613.8
-rw------- 1 postgres postgres 1073741824 Jun 4 04:40 2613.9
-rw------- 1 postgres postgres 4407296 Jun 4 04:42 2613_fsm
-rw------- 1 postgres postgres 548864 Jun 4 04:42 2613_vm
Istota pg_largeobject i ponieważ faktycznie usuwamy duże obiekty z
baza danych raz na jakiś czas, ponowne użycie istniejących plików jest całkowicie w porządku
Postgres i zgodnie z oczekiwaniami. Ale wszystkie moje testy pokazały, że podczas pisania
znacznik czasu tych plików jest rzeczywiście zaktualizowany i nie jest przechowywany ani resetowany
tyle w przeszłość. Nasz używany system plików to ext4, więc nie powinien
mieć problem ze znacznikami czasu w ogóle.
I właśnie to mnie zastanawia: jeśli Postgres nie resetuje znaczników czasu do przeszłości lub jakoś zamrozić je z jakiegoś powodu, to brzmi jak uszkodzenie danych w moich kopiach zapasowych.
Czy w Postgresie jest taka funkcjonalność, zapisywanie danych bez zmiany znaczników czasu w systemie plików?
Z powodu braku odpowiedzi zadałem pytanie na temat lista mailingowa Postgres także.