Thread: Проблема при бэкапе.
День добрый. Использую 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.bogdanov@flant.ru>:
--
Alexey Vasiliev
Почему бэкап делается не через 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.bogdanov@flant.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general
проблемой.
После 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@postgresql.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.bogdanov@flant.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.bogdanov@flant.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@172.26.1.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