Работа pg_probackup в Windows #48

ykurenkov · 2019-02-20T05:22:47Z

Посмотрел много видео с конференций о pg_probackup. Прочитал инструкцию на сайте PostgresPro. Настроил бэкапирование:

pg_probackup add-instance -B %BACKUP_DIR% -D %PGDATA% --instance %INSTANCE% pg_probackup backup -B %BACKUP_DIR% --instance %INSTANCE% --backup-mode=FULL --stream --progress -d postgres

В %BACKUP_DIR% появился директорий backups и внутри его %INSTANCE% со структурой директориев с архивами.

pg_probackup show -B %BACKUP_DIR%

Выводит список бэкапов. Всё хорошо. А вот как из этих бэкапов восстанавливаться?

Команда

pg_probackup restore -B %BACKUP_DIR% --instance %INSTANCE%

создаёт %PGDATA% с pg_wal и recovery.conf. Естественно в не пустом %PGDATA% initdb отказывается создавать кластер. Если же сначала создать кластер, то pg_probackup restore сообщает:

ERROR: restore destination is not empty: “D:\PGDATA\test\”

Как же использовать pg_probackup для восстановления?

Вот вывод на консоль pg_probackup restore:

VERBOSE: Thread [0]: Need to switch to segno next to 0/20000000, current LSN 0/20000028
LOG: Thread [0]: Opening WAL segment "D:/IBIS_BACKUPS/PGBACKUPS/wal/IBIS/000000010000000000000020"
INFO: Backup PN61N8 WAL segments are valid
INFO: Backup PN61N8 is valid.
LOG: restoring database from backup 2019-02-19 12:45:26+05
LOG: there is no file tablespace_map
LOG: restore directories and symlinks...
LOG: create directory "pg_wal"
LOG: Start thread for num:3
VERBOSE: Restoring file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/backup_label, is_datafile 0, is_cfs 0
VERBOSE: Restored file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/backup_label : 223 bytes
VERBOSE: Restoring file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/pg_wal/00000001000000000000001A, is_datafile 0, is_cfs 0
VERBOSE: Restored file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/pg_wal/00000001000000000000001A : 16777216 bytes
VERBOSE: Restoring file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/pg_wal/00000001000000000000001B, is_datafile 0, is_cfs 0
VERBOSE: Restored file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/pg_wal/00000001000000000000001B : 16777216 bytes
LOG: restore PN5XJQ backup completed
LOG: restoring database from backup 2019-02-19 14:13:56+05
LOG: there is no file tablespace_map
LOG: restore directories and symlinks...
LOG: Start thread for num:1
VERBOSE: Restoring file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN61N8\database/backup_label, is_datafile 0, is_cfs 0
VERBOSE: Restored file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN61N8\database/backup_label : 223 bytes
LOG: restore PN61N8 backup completed
LOG: ----------------------------------------
LOG: creating recovery.conf
INFO: Restore of backup PN61N8 completed.

pg_probackup из сборки PostgresPro_10.6.1_64.bit.exe
pg_probackup 2.0.24 (Postgres Pro 10.6.1 standard)

The text was updated successfully, but these errors were encountered:

gsmolk · 2019-02-20T16:47:45Z

Спасибо за фидбэк.
Сейчас подготовим бинари 2.0.26

gsmolk · 2019-02-20T19:16:30Z

Готово:
https://oc.postgrespro.ru/index.php/s/ikfqgfjBO5n15aE

gsmolk · 2019-02-21T10:19:53Z

Если возникнут какие-либо вопросы - пишите.

ykurenkov · 2019-02-22T06:07:46Z

Есть не вопросы, а скорее информация. Попробовал присланные бинарники. Поведение под виндой не поменялось pg_probackup в --backup-mode=FULL копирует из %PGDATA% в %BACKUP_DIR%]backups%INSTANCE%\ИМЯ_БЭКАПА\database только pg_wal и создаёт backup_label. Больше никаких файлов кроме нескольких WAL и backup_label там нет.

Собрал с утра под Ubuntu - там при FULL копирует $PGDATA. Но и тут проблема:

INFO: Progress: (1296/1297). Process file "/var/lib/pgpro/std-10/data/base/16384/16407"
INFO: Progress: (1297/1297). Process file "/var/lib/pgpro/std-10/data/base/16384/16385"
INFO: Data files are transfered
INFO: wait for pg_stop_backup()
WARNING:  pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)
HINT:  Check that your archive_command is executing properly.  pg_stop_backup can be canceled safely, but the database backup will not be usable without all the WAL segments.

Бэкап завершается с ошибкой. arrchive_command закомментарена.

WARNING: Cancel request sent
ERROR: pg_stop_backup doesn't answer in 300 seconds, cancel it
WARNING: Backup PN9Y47 is running, setting its status to ERROR
WARNING: backup in progress, stop backup
INFO: Validate backups of the instance 'TEST'
WARNING: Backup PN9Y47 has status ERROR. Skip validation.
WARNING: Some backups are not valid

Включил архивацию WAL

# WAL archiving
archive_mode    = on
archive_timeout = 60            # force a logfile segment switch after this
                                # number of seconds; 0 disables


#archive_command = 'copy /Y %p C:\\IBIS_PGARCHIVE\\//%f'
#max_standby_archive_delay = 10s
archive_command = 'pg_probackup archive-push -B /var/lib/postgresql/PROBAK  --instance TEST --wal-file-path %p --wal-file-name %f'

Прописал archive_command - бэкап выполнился. Что я делаю не так? Из документации на сайте не очевидно, что archive_command надо включать. И не понятно зачем включать архивацию?

gsmolk · 2019-02-22T08:43:06Z

Есть не вопросы, а скорее информация. Попробовал присланные бинарники. Поведение под виндой не поменялось pg_probackup в --backup-mode=FULL копирует из %PGDATA% в %BACKUP_DIR%]backups%INSTANCE%\ИМЯ_БЭКАПА\database только pg_wal и создаёт backup_label. Больше никаких файлов кроме нескольких WAL и backup_label там нет.

А можете выполнить FULL бэкап с опцией --log-level-console=verbose и прислать весь выхлоп?
Выглядит как какая-то локальная проблема, перед передачей бинарей я прогнал на них все тесты, бэкапилось и восстанавливалось всё корректно.

Прописал archive_command - бэкап выполнился. Что я делаю не так? Из документации на сайте не очевидно, что archive_command надо включать. И не понятно зачем включать архивацию?

бэкапу для восстановления в консистентное состояние нужен WAL.
По умолчанию pg_probackup снимает бэкапы в архивном режиме доставки WAL, т.е. он полагается на архивирование:
https://postgrespro.ru/docs/enterprise/9.6/app-pgprobackup#setting-up-archive-backups
Если архивирование не настроено, то можно снять автономную копию с помощью опции '--stream'. В этом случае необходимый WAL будет стримится по протоколу репликации.

ykurenkov · 2019-02-22T11:47:32Z

backup.log

gsmolk · 2019-02-22T12:27:23Z

А какие файлы и директории присутствуют в 'D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNBSN5\database/' ?

ykurenkov · 2019-02-22T12:29:52Z

 Том в устройстве D не имеет метки.
 Серийный номер тома: 8C6C-80CA

 Содержимое папки D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNBSN5

22.02.2019  17:29    <DIR>          .
22.02.2019  17:29    <DIR>          ..
22.02.2019  16:45               665 backup.control
22.02.2019  16:45               439 backup_content.control
22.02.2019  16:45    <DIR>          database
               2 файлов          1 104 байт

 Содержимое папки D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNBSN5\database

22.02.2019  16:45    <DIR>          .
22.02.2019  16:45    <DIR>          ..
22.02.2019  16:45               223 backup_label
22.02.2019  16:45    <DIR>          pg_wal
               1 файлов            223 байт

 Содержимое папки D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNBSN5\database\pg_wal

22.02.2019  16:45    <DIR>          .
22.02.2019  16:45    <DIR>          ..
22.02.2019  16:45        16 777 216 000000010000000000000039
22.02.2019  16:45        16 777 216 00000001000000000000003A
               2 файлов     33 554 432 байт

     Всего файлов:
               5 файлов     33 555 759 байт
               8 папок  1 980 139 986 944 байт свободно

gsmolk · 2019-02-22T12:39:04Z

Пробэкап перед стартом бэкапа составляет массив файлов и директорий, которые содержатся в PGDATA.
У Вас этот массив содержит 0 файлов.
Похоже, что файловая система не дает сделать listing файлов в директории, а pg_probackup это не детектит(что является багом). Какая у Вас ОС? Какие права существуют на директорию PGDATA?

ykurenkov · 2019-02-22T12:45:50Z

Полный доступ дан всем пользователям от безисходности. Windows Server 2016 Standart x64.

gsmolk · 2019-02-22T14:16:15Z

А там файлы, случайно, не скрытые?

gsmolk · 2019-02-22T14:40:18Z

Сделал бинарь с дополнительным отладочным сообщением:
https://oc.postgrespro.ru/index.php/s/wxGOJgI4yzlH0O6

Сделайте им, пожалуйста, бэкап и пришлите выхлоп

gsmolk · 2019-02-22T15:15:54Z

И пришлите еще, пожалуйста, скриншот с Advanced Security для PGDATA

gsmolk · 2019-02-24T04:02:36Z

Поставил PostgresPro 10.6.1 на Windows 2016 и запустил бэкап - успешно выполнился, файлы скопированы. Версия с проблемой с правами выглядит всё более вероятной.

gsmolk · 2019-02-24T04:26:38Z

Смог воспроизвести: отобрал у юзера, совершающего бэкап, право на 'List Folder Content', оставив при этом право на чтение.
Со своей стороны, постараемся разобраться, почему это не приводит к ошибке в opendir().

ykurenkov · 2019-02-25T06:19:49Z

Добрый день! А разве не wal-sender этим занимается? Ему же права нужны? Запустил бэкап "Выполнить с правами Администратора". Поведение не поменялось. Ради любопытства запустил

pg_basebackup -U postgres --write-recovery-conf --progress --verbose --pgdata=D:\IBIS_DATA\basebackup -h localhost -p 5433 -U postgres

Он отработал без замечаний. Вкралось сомнение на счёт порта 5433. Прописал его через set-config - не помогло.

ykurenkov · 2019-02-25T06:44:27Z

И еще смущает то, что при запуске с правами Администратора тоже не копирует должным образом.

gsmolk · 2019-02-25T07:53:40Z

Добрый день! А разве не wal-sender этим занимается? Ему же права нужны?

pg_probackup работает не через wal-sender, он работает через файловую систему. Он рекурсивно читает директории - получает списки файлов и директорией и уже открывает и читает файлы и директории.

И еще смущает то, что при запуске с правами Администратора тоже не копирует должным образом.

Администратор тоже может быть поражен в правах, например, я воспроизводил вашу проблему как раз администратором.
А Вы от какого пользователя запускаете бэкап?

ykurenkov · 2019-02-25T08:14:41Z

Я работаю от своего пользователя, имеющего админские права. Все работы выполнял от себя. Это чистый сервер после инсталяции.

gsmolk · 2019-02-25T08:23:14Z

Дайте пользователю Юрий полный доступ к этой директории(уже есть), а также к ее поддиректориям и файлам.

ykurenkov · 2019-02-25T08:29:09Z

Поведение не поменялось. Дал полный доступ. Вот пример свойств base

ykurenkov · 2019-02-25T08:35:27Z

Замечу, что полный доступ я добавил пользователю Юрий от имени пользователя Юрий. И Проводник меня пускает гулять по всей файловой структуре PGDATA

gsmolk · 2019-02-25T08:37:53Z

Можете еще раз выполнить бэкап с --log-level-console=verbose и прислать выхлоп?

ykurenkov · 2019-02-25T08:44:43Z

INFO: Backup start, pg_probackup version: 2.0.26, backup ID: PNH48Z, backup mode: full, instance: IBIS, stream: true, remote: false
VERBOSE: (query) SELECT pg_catalog.current_setting($1)
VERBOSE: 	(param:0) = block_size
VERBOSE: (query) SELECT pg_catalog.current_setting($1)
VERBOSE: 	(param:0) = wal_block_size
VERBOSE: (query) SELECT pg_catalog.pg_is_in_recovery()
VERBOSE: (query) SELECT pgpro_edition()
VERBOSE: (query) show data_checksums
LOG: This PostgreSQL instance was initialized with data block checksums. Data block corruption will be detected
VERBOSE: (query) SELECT proname FROM pg_proc WHERE proname='ptrack_version'
VERBOSE: (query) SELECT pg_catalog.ptrack_version()
VERBOSE: (query) show ptrack_enable
VERBOSE: (query) SELECT system_identifier FROM pg_catalog.pg_control_system()
LOG: Backup destination is initialized
LOG: Database backup start
VERBOSE: (query) SELECT pg_catalog.pg_start_backup($1, $2, false)
VERBOSE: 	(param:0) = 2019-02-25 13:43:47+05 with pg_probackup
VERBOSE: 	(param:1) = true
INFO: Start transfering data files
LOG: started streaming WAL at 0/47000000 (timeline 1)
VERBOSE: Start thread num: 0
INFO: Data files are transfered
VERBOSE: (query) SET client_min_messages = warning;
VERBOSE: (query) SELECT pg_catalog.pg_create_restore_point($1)
VERBOSE: 	(param:0) = pg_probackup, backup_id PNH48Z
VERBOSE: (query) SELECT pg_catalog.txid_snapshot_xmax(pg_catalog.txid_current_snapshot()), current_timestamp(0)::timestamptz, lsn, labelfile, spcmapfile FROM pg_catalog.pg_stop_backup(false, false)
INFO: wait for pg_stop_backup()
VERBOSE: finished segment at 0/48000000 (timeline 1)
INFO: pg_stop backup() successfully executed
LOG: finished streaming WAL at 0/48000060 (timeline 1)
LOG: Looking for LSN 0/47000160 in segment: 000000010000000000000047
LOG: Found WAL segment: D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNH48Z\database\pg_wal/000000010000000000000047
VERBOSE: Thread [0]: Need to switch to the next WAL segment, page LSN 0/47000000, record being read LSN 0/47000160
LOG: Thread [0]: Opening WAL segment "D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNH48Z\database\pg_wal/000000010000000000000047"
LOG: Found LSN: 0/47000160
LOG: Getting the Recovery Time from WAL
VERBOSE: Thread [0]: Need to switch to the next WAL segment, page LSN 0/47000000, record being read LSN 0/47000160
LOG: Thread [0]: Opening WAL segment "D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNH48Z\database\pg_wal/000000010000000000000047"
INFO: Validating backup PNH48Z
INFO: Progress: (1/3). Process file "D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNH48Z\database/backup_label"
INFO: Progress: (2/3). Process file "D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNH48Z\database/pg_wal/000000010000000000000047"
INFO: Progress: (3/3). Process file "D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNH48Z\database/pg_wal/000000010000000000000048"
INFO: Backup PNH48Z data files are valid
INFO: Backup PNH48Z completed

gsmolk · 2019-02-25T13:51:36Z

Не понимаю, что происходит тогда.
Сделал чистую инсталляцию Server 2016, поставил https://repo.postgrespro.ru/pgpro-10/win/PostgresPro_10.6.1_64bit_Setup.exe
Делаю бэкап тем же пользователем(Administrator), никаких проблем:
https://pastebin.postgrespro.ru/?f310e70cef1eef8c#uHfhRPDDbk4UnFO3cO1DsnN57BIaP4Uremi8HU8vRRc=

Права на PGDATA:

ykurenkov · 2019-02-25T13:55:03Z

"Национальность" винды ведь не должна влиять? Это пока единственное отличие, что я вижу. И кластер у меня в другом месте лежит.

gsmolk · 2019-02-25T14:02:23Z

"Национальность" винды ведь не должна влиять?

Не должна, хотя я уже ни в чем не уверен.

Это пока единственное отличие, что я вижу

И группа, у меня owner PGDATA - группа Administrators.
А попробуйте поставить рядом еще один PostgresPro c дефолтными путем и его забэкапить.

ykurenkov · 2019-02-26T05:35:57Z

set PGDATA="C:\Program Files\PostgresPro\10\data"

Бэкап выполнился.

ykurenkov · 2019-02-26T05:43:38Z

Я не вижу в правах доступа у пользователя Юрий ограничений на выполнение бэкапа. Отмечу, что в "Проводнике" и "FARе" есть доступ ко всему дереву PGDATA в обоих случаях.

gsmolk · 2019-02-26T08:33:34Z

Я, честно говоря, тоже не понимаю. Может это баг в винде какой-то.
С нашей стороны необходимо научиться такое детектить и корректно репортить об отсутствии прав.

gsmolk · 2019-03-26T08:13:30Z

Вы хотите ручку, с помощью которой можно было бы задавать кол-во отротированных файлов, которое необходимо хранить? Мы пока такое не умеем.
Кмк --log-rotation-age=7d решает вашу проблему, нет?

ykurenkov · 2019-03-26T08:49:48Z

Вы меня правильно поняли. age=7d не решит проблему. Проблема в том, что при ротации теряются вся информация , которая была в логе до момента ротации. Например ротация приоизошла в 3:15, поэтому в 3:16 мы никогда не узнаем, что было в 3:14. Я бы это назвал не ротацией, а обнулением лога.

gsmolk · 2019-03-26T08:54:07Z

Есть другой подход: задаем --log-filename=pg_probackup-%Y-%m-%d.log и получаем отдельный лог файл на каждый день.
Но удаление старых лог файлов станет вашей проблемой.

za-arthur · 2019-03-26T08:54:51Z

Или использовать --log-filename=postgresql-%u.log, тогда будет файл на каждый день недели. В этом случае нет проблем с удалением старых логов.

gsmolk · 2019-03-26T08:55:47Z

Или использовать --log-filename=postgresql-%u.log, тогда будет файл на каждый день недели.

Да, кстати, этот подход решает обе проблемы.

ykurenkov · 2019-03-26T08:57:43Z

А так можно?! Так это именно то, что надо, в идеале! В доке https://postgrespro.ru/docs/postgrespro/11/app-pgprobackup#PG-PROBACKUP-LOGGING-OPTS об этом ничего нет.

ykurenkov · 2019-03-26T08:58:41Z

А --log-rotation-age=1d нужен при этом?

za-arthur · 2019-03-26T08:59:15Z

Да, подробнее смотрите спецификацию strftime: http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html

А --log-rotation-age=1d нужен при этом?

Не нужно.

gsmolk · 2019-03-26T09:05:12Z

В доке об этом написано, но очень неразборчиво:

. Имена файлов обрабатываются по шаблону strftime, так что вы можете использовать спецкоды с % для выбора имён файлов, зависящих от времени.

Видимо нужно дополнить примерами.

za-arthur · 2019-03-26T15:31:06Z

А --log-rotation-age=1d нужен при этом?

Извините, ввел в заблуждение. Этот параметр нужен.

ykurenkov · 2019-03-27T05:54:20Z

Это произошло после прописывания в конфиг log-filename=pg_probackup-%u.log Програма не может создать файл. Файл на NAS.

gsmolk · 2019-03-27T06:33:17Z

Сейчас посмотрим.

ykurenkov · 2019-04-01T04:56:32Z

archive-get

Синтаксис:

pg_probackup archive-get -B каталог_копий --instance имя_экземпляра
--wal-file-path %p --wal-file-name %f'

Перемещает файлы WAL из соответствующего подкаталога каталога резервной копии в каталог журнала предзаписи кластера. Эта команда автоматически устанавливается программой pg_probackup в качестве restore_command в recovery.conf при восстановлении архивных копий. Устанавливать её вручную не нужно.

Запустил recovery для создания slave. В сгенерированном recovery.conf pg_probackup не прописан. Это правильно?

# recovery.conf generated by pg_probackup 2.0.26
standby_mode = 'on'
primary_conninfo = 'user=postgres host=10.20.9.176 port=5433 client_encoding=WIN1251 sslmode=disable sslcompression=1 krbsrvname=postgres target_session_attrs=any'

gsmolk · 2019-04-01T07:16:57Z

А какой командой создавали слейв?

ykurenkov · 2019-04-01T07:51:02Z

%PROBACKUP% restore -B %BACKUP_DIR% --instance %INSTANCE% %SKIP_BLOCK_VALIDATION% %JOBS% --restore-as-replica

gsmolk · 2019-04-01T08:21:51Z

А список бэкапов можете прислать?
%PROBACKUP% show -B %BACKUP_DIR% --instance %INSTANCE%

ykurenkov · 2019-04-01T08:28:45Z

BACKUP INSTANCE 'ny1-10'
========================================================================================================================================
 Instance  Version  ID      Recovery Time           Mode   WAL     Current/Parent TLI   Time    Data    Start LSN     Stop LSN  Status
========================================================================================================================================
 ny1-10    10       PP9OJ4  2019-04-01 11:46:20+05  FULL   STREAM  1 / 0               4710s   323GB   D3/E000028  D3/424BCBE8  OK
 ny1-10    10       PP8SO1  2019-04-01 00:07:37+05  FULL   STREAM  1 / 0               4072s   322GB   D2/A000028  D2/25AF1DF8  CORRUPT
 ny1-10    10       PP6Y01  2019-03-30 23:59:18+05  DELTA  STREAM  1 / 0               3582s  3861MB  CF/A2000028  CF/E401A790  OK
 ny1-10    10       PP53C1  2019-03-29 23:59:14+05  DELTA  STREAM  1 / 0               3572s  3702MB  CD/61000108  CD/8315DB10  OK
 ny1-10    10       PP38O0  2019-03-28 23:59:49+05  DELTA  STREAM  1 / 0               3608s  3611MB  CA/F9000028  CB/1E04B7F8  OK
 ny1-10    10       PP1E01  2019-03-27 23:56:30+05  DELTA  STREAM  1 / 0               3404s  2557MB  C8/5A000028  C8/701FCE20  OK
 ny1-10    10       POZJC2  2019-03-26 23:52:42+05  DELTA  STREAM  1 / 0               3175s    62GB  C5/F70066A0   C6/B064870  OK
 ny1-10    10       POYTMQ  2019-03-26 14:54:29+05  DELTA  STREAM  1 / 0               4289s   228GB  B7/3600F988  B8/A241DCE0  OK
 ny1-10    10       POVU00  2019-03-25 00:01:46+05  FULL   STREAM  1 / 0               3724s   314GB  81/73000028  81/8B0CC8D8  OK

Восстанавливал из бэкапа днем 29-го числа.

gsmolk · 2019-04-01T08:38:45Z

Ага, понятно.
Дело в том, что при восстановлении из STREAM бэкапа restore_command не прописывается автоматически, т.к. pg_probackup предполагает, что архива нет, хотя теперь это поведение уже не кажется разумным.
Вы делаете бэкап с мастера или с реплики? Если с мастера, то эту проблему можно легко решить, убрав опцию --stream у команды backup. После этого бэкапы будут сниматься в режиме ARCHIVE и при их восстановлении restore_command будет прописываться автоматически.

ykurenkov · 2019-04-01T08:42:19Z

Бэкап делается с мастера. Я реплики создаю с помощью pg_basebackup. Чтобы не грузить мастер созданием реплики решил создать её из бэкапа.

О ключе --stream понял.

gsmolk · 2019-04-01T08:58:29Z

Бэкап делается с мастера. Я реплики создаю с помощью pg_basebackup. Чтобы не грузить мастер созданием реплики решил создать её из бэкапа.

Это разумно.
Есть еще один нюанс: мы не сохраняем в бэкапе libpq пароли, которые Вы указали во время бэкапирования. Соответственно, если Вы восстановили бэкап с опцией --restore-as-replica, то там будет добавлен полный primary_conninfo за исключением пароля.

ykurenkov · 2019-04-01T09:05:14Z

Отсутствие passord= я уже заметил.

ykurenkov · 2019-04-01T09:07:45Z

Запустил validate на бэкап со статусом CORRUPT. Теперь он OK. Был какой-то сбой в сети во время бэкапа.

gsmolk · 2019-04-01T09:11:58Z

Запустил validate на бэкап со статусом CORRUPT. Теперь он OK. Был какой-то сбой в сети во время бэкапа.

Да, CORRUPT бэкап всегда можно попытаться ревалидировать.

gsmolk · 2019-04-09T19:19:24Z

Это произошло после прописывания в конфиг log-filename=pg_probackup-%u.log Програма не может создать файл. Файл на NAS.

Пофиксили в pg_probackup_5.exe

gsmolk · 2019-04-09T19:24:29Z

https://oc.postgrespro.ru/index.php/s/bhYnR77byJXJrqb

gsmolk · 2019-04-09T19:25:50Z

Закрываем issue?

ykurenkov · 2019-04-10T05:34:38Z

Думаю, что можно и закрыть.

ykurenkov · 2019-04-25T10:52:30Z

2019-04-22 23:00:01 RTZ 4 (зима): INFO: Backup start, pg_probackup version: 2.0.27, backup ID: PQDJC1, backup mode: delta, instance: ny1-10, stream: true, remote: false
2019-04-22 23:00:04 RTZ 4 (зима): ERROR: cannot stat file "D:/IBIS_DATA/ny1-10/base/15520165/15522614": Permission denied
2019-04-22 23:00:04 RTZ 4 (зима): WARNING: Backup PQDJC1 is running, setting its status to ERROR
2019-04-22 23:00:04 RTZ 4 (зима): WARNING: backup in progress, stop backup

Я не знаю, что делает postgresql, что лочит иногда вот так эксклюзивно файл. Иногда сталкиваюсь с подобным явлением. Под виндой. Бывает, что лочит на несколько дней. Обычно это лечат перезагрузкой, если долго не отпускает. Попадётся мне живьем, надо oid2name посмотреть что это. Соответственно и pg_probackup не может выполнить бэкап.

gsmolk · 2019-04-25T11:07:27Z

@ykurenkov, спасибо за фидбэк!
Можете открыть новый issue и перенести это туда?

ykurenkov closed this as completed Apr 10, 2019

Работа pg_probackup в Windows #48

Работа pg_probackup в Windows #48

Comments

ykurenkov commented Feb 20, 2019 • edited Loading

gsmolk commented Feb 20, 2019

gsmolk commented Feb 20, 2019

gsmolk commented Feb 21, 2019

ykurenkov commented Feb 22, 2019

gsmolk commented Feb 22, 2019 • edited Loading

ykurenkov commented Feb 22, 2019

gsmolk commented Feb 22, 2019

ykurenkov commented Feb 22, 2019

gsmolk commented Feb 22, 2019 • edited Loading

ykurenkov commented Feb 22, 2019

gsmolk commented Feb 22, 2019

gsmolk commented Feb 22, 2019

gsmolk commented Feb 22, 2019

gsmolk commented Feb 24, 2019

gsmolk commented Feb 24, 2019 • edited Loading

ykurenkov commented Feb 25, 2019

ykurenkov commented Feb 25, 2019

gsmolk commented Feb 25, 2019 • edited Loading

ykurenkov commented Feb 25, 2019

gsmolk commented Feb 25, 2019

ykurenkov commented Feb 25, 2019

ykurenkov commented Feb 25, 2019

gsmolk commented Feb 25, 2019

ykurenkov commented Feb 25, 2019

gsmolk commented Feb 25, 2019 • edited Loading

ykurenkov commented Feb 25, 2019 • edited Loading

gsmolk commented Feb 25, 2019

ykurenkov commented Feb 26, 2019

ykurenkov commented Feb 26, 2019

gsmolk commented Feb 26, 2019

gsmolk commented Mar 26, 2019

ykurenkov commented Mar 26, 2019

gsmolk commented Mar 26, 2019 • edited Loading

za-arthur commented Mar 26, 2019 • edited Loading

gsmolk commented Mar 26, 2019

ykurenkov commented Mar 26, 2019

ykurenkov commented Mar 26, 2019

za-arthur commented Mar 26, 2019

gsmolk commented Mar 26, 2019

za-arthur commented Mar 26, 2019 • edited Loading

ykurenkov commented Mar 27, 2019 • edited Loading

gsmolk commented Mar 27, 2019

ykurenkov commented Apr 1, 2019 • edited Loading

gsmolk commented Apr 1, 2019

ykurenkov commented Apr 1, 2019

gsmolk commented Apr 1, 2019

ykurenkov commented Apr 1, 2019

gsmolk commented Apr 1, 2019 • edited Loading

ykurenkov commented Apr 1, 2019

gsmolk commented Apr 1, 2019

ykurenkov commented Apr 1, 2019

ykurenkov commented Apr 1, 2019

gsmolk commented Apr 1, 2019

gsmolk commented Apr 9, 2019

gsmolk commented Apr 9, 2019

gsmolk commented Apr 9, 2019

ykurenkov commented Apr 10, 2019

ykurenkov commented Apr 25, 2019

gsmolk commented Apr 25, 2019

ykurenkov commented Feb 20, 2019 •

edited

Loading

gsmolk commented Feb 22, 2019 •

edited

Loading

gsmolk commented Feb 22, 2019 •

edited

Loading

gsmolk commented Feb 24, 2019 •

edited

Loading

gsmolk commented Feb 25, 2019 •

edited

Loading

gsmolk commented Feb 25, 2019 •

edited

Loading

ykurenkov commented Feb 25, 2019 •

edited

Loading

gsmolk commented Mar 26, 2019 •

edited

Loading

za-arthur commented Mar 26, 2019 •

edited

Loading

za-arthur commented Mar 26, 2019 •

edited

Loading

ykurenkov commented Mar 27, 2019 •

edited

Loading

ykurenkov commented Apr 1, 2019 •

edited

Loading

gsmolk commented Apr 1, 2019 •

edited

Loading