Благодарение на новите помощни програми barman-cloud-restore и barman-cloud-wal-restore въведен в Barman 2.11 , вече е възможно да се изпълни възстановяването на екземпляр на PostgreSQL, като се използва пълно архивиране, извършено преди с помощта на barman-cloud-wal-archive и barman-cloud-backup команди. Нека заедно да открием как да приложим това в следващата статия.
Заслужава да се отбележи, че в Barman 2.11 всички облачни помощни програми за Barman вече са в отделен пакет, наречен barman-cli-cloud .
Изисквания
1. barman-cli-cloud пакет
2. Екземпляр на PostgreSQL
3. Кофа AWS S3
4. Втора виртуална машина, където да изпълните възстановяването
В тази статия ще тестваме barman-cli-cloud функционалности във виртуална машина с Debian Buster и PostgreSQL 12. За да следвате правилно инструкциите, съдържащи се в тази статия, предполагаме също, че имате:
- конфигурира Postgres да архивира WAL файлове в съществуваща S3 кофа с помощта на
barman-cloud-wal-archive - изпълни резервно копие и го изпрати в същата S3 кофа чрез
barman-cloud-backup
Можете лесно да постигнете това, като следвате инструкциите, съдържащи се в тези предишни статии в блога:
- Barman Cloud – Част 1:Архив на WAL
- Barman Cloud – Част 2:Cloud Backup
Настройте сървъра за възстановяване
В резултат на това имаме S3 кофа на AWS с име barman-s3-test който вече съдържа WAL файловете и архивираните архиви чрез barman-cloud-wal-archive и barman-cloud-backup инструменти, сега трябва правилно да конфигурираме сървър, който ще бъде хост за възстановяване на екземпляра на PostgreSQL.
1. Инсталирайте PostgreSQL 12 от официалното хранилище на PGDG
2. Инсталирайте публичното хранилище 2ndQuadrant
3. Инсталирайте barman-cli-cloud пакет:
[email protected]:~# apt [email protected]:~# apt install barman-cli-cloud
4. Инсталирайте awscli пакет:
[email protected]:~# apt install awscli
5. Конфигурирайте идентификационните данни на AWS с инструмента awscli като потребител на postgres:
[email protected]:~$ aws configure --profile barman-cloudAWS Идентификатор на ключ за достъп [Няма]:AKI******************** AWS секретен ключ за достъп [Няма ]:**************************************** Име на региона по подразбиране [Няма]:eu -west-1Изходен формат по подразбиране [Няма]:json
Изпълнете процедурата за възстановяване
След като сървърът за възстановяване е конфигуриран правилно, ние сме готови да започнем процедурата за възстановяване.
Barman 2.11 въвежда barman-cloud-backup-list команда, която ви позволява да извличате информация за архивите, направени с barman-cloud-backup :
[email protected]:~$ barman-cloud-backup-list \ --profile barman-cloud \ s3://barman-s3-test pg12Backup ID Краен час Начало Wal20200713T120856 2020-07-13 12:09:05 0000000100000000000000C
Вече сме готови да изпълним възстановяването с помощта на barman-cloud-restore команда:
[email protected]:~$ barman-cloud-restore \ --profile barman-cloud \ s3://barman-s3-test \ pg12 20200713T120856 \ /var/lib/postgresql/12/main/След като възстановяването приключи успешно, можем да проверим съдържанието на директорията PGDATA:
[email protected]:~$ ls /var/lib/postgresql/12/main/PG_VERSION глобален pg_hba.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.confbackup_label pg_commit.confbackup_label pg_commitsub. pg_replslot pg_stat pg_tblspc pg_xactСега, за да сме сигурни, че процесът на възстановяване работи правилно, трябва да стартираме възстановения екземпляр на PostgreSQL и да проверим дали всичко работи както се очаква. Този процес изисква някои допълнителни стъпки.
Първо, тъй като сме на система Debian, трябва да копираме файловете, съдържащи конфигурацията на PostgreSQL под
/etc/postgresql/12/main/директория:[email protected]:~$ cp /var/lib/postgresql/12/main/postgresql.conf /etc/postgresql/12/main/[email protected]:~$ cp /var/lib/postgresql /12/main/pg_hba.conf /etc/postgresql/12/main/[email protected]:~$ cp /var/lib/postgresql/12/main/pg_ident.conf /etc/postgresql/12/main/Второ, създайте
recovery.signalфайл:[email protected]:~$ докоснете /var/lib/postgresql/12/main/recovery.signalСлед това деактивирайте
archive_commandза да предотвратите записването на възстановения екземпляр в същата кофа като оригиналния екземпляр:[email protected]:~$ echo \"archive_command ='cd .'\">> /etc/postgresql/12/main/postgresql.confСлед това трябва да конфигурирате PostgreSQL да извлича WAL файловете от най-новата налична времева линия от кофата на S3, като използвате
barman-cloud-wal-restoreвrestore_command:[email protected]:~$ echo \"restore_command ='barman-cloud-wal-restore --profile barman-cloud s3://barman-s3-test pg12 %f %p'\">> / etc/postgresql/12/main/[email protected]:~$ echo \"recovery_target_timeline ='най-нов'\">> /etc/postgresql/12/main/postgresql.confВАЖНО :Преди да продължите, моля, уверете се, че екземплярът на PostgreSQL не се изпълнява и че дестинационната директория (по подразбиране PostgreSQL datadir) е празна.
И накрая, ние сме готови да стартираме новия възстановен екземпляр:
[email protected]:~# systemctl рестартиране [email protected]Страхотен! Както можем да видим от дневника на PostgreSQL, WAL файловете се възстановяват от S3 кофата и екземплярът е стартиран правилно:
[email protected]:~$ less /var/log/postgresql/postgresql-12-main.log...2020-07-13 12:43:25.093 UTC [9458] LOG:стартиране на PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) на x86_64-pc-linux-gnu, компилиран от gcc (Debian 8.3.0-6) 8.3.0, 64-bit2020-07-13 12:43:25.093 UTC [9458] UTC слушане на IPv4 адрес "127.0.0.1", порт 54322020-07-13 12:43:25.095 UTC [9458] LOG:слушане на Unix сокет "/var/run/postgresql/.s.PGSQL.5432"7-2020 13 12:43:25.111 UTC [9459] LOG:системата на базата данни е прекъсната; последно известен в 2020-07-13 12:08:56 UTC2020-07-13 12:43:25.508 UTC [9459] LOG:стартиране на възстановяване на архива2020-07-13 12:43:26.010 UTC] log UTC [9459 възстановен журнал файл "00000001000000000000000C" от archive2020-07-13 12:43:26.052 UTC [9459] LOG:повторението започва в 0/C0000282020-07-13 12:0400000000000000000000000000000000000000000000000 -07-13 12:43:26.054 UTC [9458] LOG:системата на базата данни е готова да приеме връзки само за четене2020-07-13 12:43:26.469 UTC [9459] LOG:възстановен регистрационен файл "0000000100000000000000000000000000000000000000000000000000000000000000000 13 12:43:26.823 UTC [9459] LOG:повторено извършено в 0/D0001B02020-07-13 12:43:27.242 UTC [9459] LOG:възстановен регистрационен файл "000000010000000000" от 3000000000000000000000:0000000000 UTC [9459] LOG:избран нов идентификационен номер на времевата линия:22020-07-13 12:43:27.644 UTC [9459] LOG:възстановяването на архива е завършено2020-07-13 12:43:27.979 UTC [9458] LOG:системата от база данни е готова за работа приемете връзкиЗаключение
Както обикновено с всяка нова версия на Barman, препоръчваме на всеки да актуализира своите системи до най-новата версия. Пълен списък с промени и корекции на грешки е наличен тук.
Моля, имайте предвид, че ако вече използвате
barman-cloud-wal-archiveилиbarman-cloud-backupинсталиран чрез пакет RPM/Apt и надграждате системата си, трябва да инсталиратеbarman-cli-cloudпакет. Това се дължи на факта, че с версията на Barman 2.11 всички инструменти, свързани с облака, са част отbarman-cli-cloudпакет, както е обяснено в началото на статията.Следващите версии на Barman може да подобрят използваемостта и възможностите за автоматизация на командата за възстановяване, например чрез подготовка на
recovery.confилиrecovery.signalфайл като действителния Барман.
