Re: Re: [pgsql-ru-general] Проблема при бэкапе.

День добрый. Использую Continuous Archiving для бэкапов и столкнулся с
проблемой.

После SELECT pg_start_backup('pgbackup', true); начинаю копирование
данных, в это же время postgres решает очистить несколько файлов. В
результате имею неконсистентный бэкап. И при этом, когда бэкап
разворачивается postgres даже не скажет, что файлов не хватает. Только
потом уже можно узнать, получив приблизительно такую ошибку.

ОШИБКА: не удалось открыть файл "base/16420/32858809": No such file or
directory

Сейчас я делаю сначала копию rsync, и смотрю на его код возврата. В
случае кода, отличного от 0, я перекачиваю еще раз. Это неудобно. Можно
ли вообще как-то избежать данной проблемы? Не связана ли она с autovacuum?

--
Николай Богданов,
инженер ЗАО «Флант»
http://flant.ru/
+7 (495) 721-10-27, доб. 422
+7 (926) 125-39-69

Какая версия PostgreSQL?

Почему бэкап делается не через  http://www.postgresql.org/docs/current/static/app-pgbasebackup.html  ?

restore.conf должен сразу быть настроен и положен в дата директорию, поскольку без него база при запуске ругнется, что не хватает файлов и упадет (еще может говорить, что нужно удалить backup_label, что делать не нужно). При верном restore.conf PostgreSQL начнет подчитывать с основной базы wal-файлы и будет работать в режиме восстановления.

Thu, 03 Apr 2014 11:44:21 +0400 от Николай Богданов <nikolay(dot)bogdanov(at)flant(dot)ru>:
>День добрый. Использую Continuous Archiving для бэкапов и столкнулся с
>проблемой.
>
>После SELECT pg_start_backup('pgbackup', true); начинаю копирование
>данных, в это же время postgres решает очистить несколько файлов. В
>результате имею неконсистентный бэкап. И при этом, когда бэкап
>разворачивается postgres даже не скажет, что файлов не хватает. Только
>потом уже можно узнать, получив приблизительно такую ошибку.
>
>ОШИБКА: не удалось открыть файл "base/16420/32858809": No such file or
>directory
>
>Сейчас я делаю сначала копию rsync, и смотрю на его код возврата. В
>случае кода, отличного от 0, я перекачиваю еще раз. Это неудобно. Можно
>ли вообще как-то избежать данной проблемы? Не связана ли она с autovacuum?
>
>--
>Николай Богданов,
>инженер ЗАО «Флант»
>http://flant.ru/
>+7 (495) 721-10-27, доб. 422
>+7 (926) 125-39-69
>
>
>
>--
>Sent via pgsql-ru-general mailing list (pgsql-ru-general(at)postgresql(dot)org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-ru-general

--
Alexey Vasiliev

Привет, Николай!

2014-04-03 11:44 GMT+04:00 Николай Богданов <nikolay(dot)bogdanov(at)flant(dot)ru>:

> День добрый. Использую Continuous Archiving для бэкапов и столкнулся с
> проблемой.
>
> После SELECT pg_start_backup('pgbackup', true); начинаю копирование
> данных, в это же время postgres решает очистить несколько файлов. В
> результате имею неконсистентный бэкап.
>

Вы где-то ошиблись и что-то делаете не правильно, или копирование WAL или
их применение при разворачивании.

pg_start_backup и последующее применение всех WAL сгенерированных с
начала pg_start_backup до pg_stop_backup
к копии при разворачивании бекапа гарантируют консистентность, независимо
от того, какие файлы там создавались
или очищались в процессе копирования.

--
Sergey Burladyan

03.04.2014 18:24, Sergey Burladyan пишет:
> Привет, Николай!
>
> 2014-04-03 11:44 GMT+04:00 Николай Богданов <nikolay(dot)bogdanov(at)flant(dot)ru
> <mailto:nikolay(dot)bogdanov(at)flant(dot)ru>>:
>
> День добрый. Использую Continuous Archiving для бэкапов и
> столкнулся с проблемой.
>
> После SELECT pg_start_backup('pgbackup', true); начинаю
> копирование данных, в это же время postgres решает очистить
> несколько файлов. В результате имею неконсистентный бэкап.
>
>
> Вы где-то ошиблись и что-то делаете не правильно, или копирование WAL
> или их применение при разворачивании.
>
> pg_start_backup и последующее применение всех WAL сгенерированных с
> начала pg_start_backup до pg_stop_backup
> к копии при разворачивании бекапа гарантируют консистентность,
> независимо от того, какие файлы там создавались
> или очищались в процессе копирования.
>
> --
> Sergey Burladyan

Сергей, я наверное неверно выразился. С WAL-файлами проблем нет.
Проблемы с файлами страниц внутри кластера. Вот кусочек лога
сегодняшнего бэкапа.

+ ssh postgres(at)172(dot)26(dot)1(dot)15 /opt/scripts/start_backup.sh
pg_start_backup
-----------------
14E1/6D000020
(1 строка)

+ rsyncload -a -v --bwlimit=100000 --exclude=pg_xlog --exclude=pg_log
--exclude=server.crt --exclude=server.key
--exclude=/var/lib/postgresql/9.2/main/server.key
rsync://10.0.0.2/root//var/lib/postgresql/9.2/main/ /var/tmp/db
---skip---
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204170"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204171"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204172"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204173"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204174"
(in root)
file has vanished:
"/var/lib/postgresql/9.2/main/base/16420/33204174_fsm" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204175"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204176"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204177"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204178"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204179"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204180"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204181"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204182"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204183"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204184"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204185"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204186"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204187"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204188"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204189"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204190"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204191"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204192"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204193"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204194"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204195"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204196"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204197"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204198"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204199"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204200"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204201"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204202"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204203"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204204"
(in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204205"
(in root)
---skip---
rsync warning: some files vanished before they could be transferred
(code 24) at main.c(1536) [generator=3.0.9]
+ export e=24
+ e=24

То есть после pg_start_backup у меня сам postgres очистил несколько
файликов. После чего я сказал pg_stop_backup и начал восстанавление.
Восстановление базы прошло без проблем, но при определенных запросах
база выдает, что не может найти файл.

Собственно я пытаюсь понять - где я документацию не дочитал.

--
Николай Богданов,
инженер ЗАО «Флант»
http://flant.ru/
+7 (495) 721-10-27, доб. 422
+7 (926) 125-39-69

03.04.2014 16:26, Alexey Vasiliev пишет:
> Какая версия PostgreSQL?
>
> Почему бэкап делается не через
> http://www.postgresql.org/docs/current/static/app-pgbasebackup.html ?
>
> restore.conf должен сразу быть настроен и положен в дата директорию,
> поскольку без него база при запуске ругнется, что не хватает файлов и
> упадет (еще может говорить, что нужно удалить backup_label, что делать
> не нужно). При верном restore.conf PostgreSQL начнет подчитывать с
> основной базы wal-файлы и будет работать в режиме восстановления.
Алексей, спасибо за ответ.

Версии Postgres 9.0 - 9.3.

Бекап делается rsync или bacula, т.к. базы большие и не всегда есть
возможность развернуть рядом копию.

restore.conf генерирую из бэкапа по 2 файлам - backup_label и файл
*.backup из pg_xlog. Зачем он нужен - я знаю.

--
Николай Богданов,
инженер ЗАО «Флант»
http://flant.ru/
+7 (495) 721-10-27, доб. 422
+7 (926) 125-39-69