Я запускаю Postgres 9.6 і створюю резервну копію раз у раз, просто зупиняючи кластер і використовуючи його rsyncна рівні файлів. Одного разу я визнав, що деякі старі, вже створені резервні копії файлів для таблиць все ще мають той самий розмір файлу та часову позначку, як їх аналог у джерелі, але rsyncнамагаються створити резервну копію, оскільки вміст цих файлів змінився. Важливо зазначити, що щодо часових позначок у джерелі файли не змінювались днями та навіть тижнями. rsyncвикористовує контрольні суми та обчислюючи хеші MD5 для відповідних файлів, також виявляється різні хеші. Наведений нижче приклад:
Резервне копіювання:
a1171645dc187c498ce05a25b0e5157f 2613.13
-rw------- 12 109 119 1073741824 May 21 04:58 2613.13
Виробництво:
f02c1c2724714af2c5c08f8b67ab0f11 2613.13
-rw------- 1 postgres postgres 1073741824 Mai 21 04:58 2613.13
Точно той самий файл, що стосується розміру та часової позначки, але насправді різного змісту. Після використання rsyncконтрольних сум, файл у резервній копії все ще має той самий розмір і часову позначку, але новий вміст, оскільки цього разу обчислений хеш такий самий, як у виробництві.
Цей файл належить, pg_largeobjectі ця таблиця містить багато даних, звідси і названі суфікси. Більшість цих файлів у послідовності мають старі часові позначки, як та, як описана вище, більше декількох днів без будь-якого запису, і НЕ всі резервні копії та мають такий же хеш MD5, як у моїй резервній копії. Лише кілька файлів раз у раз відрізняються, як у прикладі.
З наступних дуже старих файлів даних, які в основному не змінюються протягом днів / тижнів, наприклад,
2613.13передавались через різні контрольні суми, а 2613.10не:
-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
Будучи pg_largeobjectі тому, що ми фактично видаляємо великі об’єкти з бази даних раз по раз, повторне використання існуючих файлів - це цілком нормально Postgres і, як очікувалося. Але всі мої тести показали, що під час запису часові позначки цих файлів фактично оновлюються і не зберігаються та не скидаються в минуле. Наша файлова система, що використовується, є ext4, тому не повинно виникнути проблем із часовими позначками взагалі.
І ось що мене здивує: якщо Postgres чомусь не скидає часові позначки в минуле або заморожує їх, це звучить як пошкодження даних у моїх резервних копіях.
Отже, чи є така функціональність у Postgres, що записує дані без змін часових міток файлу у файловій системі?
Через відсутність відповіді я поставив своє запитання і в списку розсилки Postgres .