Помислих върху написаното от вас и ето няколко идеи за вас:
- Ако имате нужда от резервно копие, което наистина ще бъде последователно до определен момент, тогава трябва да използвате pg_basebackup или pg_barman (вътрешно използва pg_basebackup) - обяснението е в 1. връзката по-долу. Най-новият pg_basebackup 10 предава поточно WAL регистрационни файлове, така че архивирате и всички промени, направени по време на архивиране. Разбира се, това архивиране отнема само целия екземпляр на PG. От друга страна не заключва нито една маса. И ако го направите от отдалечен екземпляр, тогава това причинява само малко натоварване на процесора на PG екземпляр и дисковият IO не е толкова голям, колкото предполагат някои текстове. Вижте връзки 4 за моите преживявания. Възстановяването е съвсем просто - вижте връзка 5.
- Ако използвате pg_dump, трябва да разберете, че нямате гаранция, че вашето архивиране е наистина последователно до момента - отново вижте връзка 1. Има възможност да използвате моментна снимка на базата данни (вижте връзки 2 и 3), но дори и с него не можете да разчитате на 100% консистенция. Използвахме pg_dump само в нашата аналитична база данни, която зарежда нова само 1 пъти на ден (вчерашни дялове от производствена база данни). Можете да го ускорите с паралелна опция (работи само за формат за архивиране на директория). Но недостатъкът е много по-голямото натоварване на екземпляра на PG - по-високо използване на процесора, много по-висок диск IO. Дори ако стартирате pg_dump дистанционно - в такъв случай запазвате само дискови IO за запазване на архивни файлове. Освен това pg_dump трябва да постави заключване за четене на таблици, така че да може да се сблъсква или с нови вмъквания, или с репликация (когато се вземе на реплика). Но когато вашата база данни достигне стотици GB, тогава дори паралелният дъмп може да отнеме часове и в този момент ще трябва да преминете към pg_basebackup така или иначе.
- pg_barman е "удобна версия" на pg_basebackup + тя ви позволява да предотвратите загуба на данни, дори когато вашето PG копие се срине много лошо. Настройването му да работи изисква повече промени, но определено си заслужава. Ще трябва да зададете архивиране на регистрационни файлове на WAL (вижте връзка 6) и ако вашият PG е <10, ще трябва да зададете "max_wal_senders" и "max_replication_slots" (което така или иначе ви трябва за репликация) - всичко е в ръководството на pg-barman, въпреки описанието не е точно страхотно. pg_barman ще предава и съхранява WAL записи дори между резервни копия, така че по този начин можете да сте сигурни, че загубата на данни в случай на много лош срив няма да бъде почти никаква. Но работата може да отнеме много часове, защото описанията не са много добри. pg-barman прави както архивиране, така и възстановяване със своите команди.
Вашата база данни е с размер 5 GB, така че всеки метод за архивиране ще бъде бърз. Но трябва да решите дали имате нужда от възстановяване във времето и почти нулева загуба на данни или не - така че дали ще инвестирате време в настройката на pg-barman или не.
Връзки:
- PostgreSQL, архивиране и всичко трябва да знаете
- Преглед на хартия:14-Serializable Изолиране на моментна снимка в PostgreSQL - относно моментните снимки
- Паралелно изхвърляне на бази данни - пример за използване на моментна снимка
- pg_basebackup опит
- pg_basebackup - възстановяване на резервно копие на tar
- Архивиране на WAL регистрационни файлове с помощта на скрипт
