При частичном восстановлении не могу подключиться к восстанволенному кластеру для вывода из read-only режима #580
Comments
ktulkhu
changed the title
|
Этот файл во всех папках баз одинаковый и просто содержит номер версии постгресса. Скопируйте из другой папки. Да, сейчас в этом месте есть недоработка, но в ближайшие планы включить не получается. issue не закрываем, и когда-нибудь поправим. |
|
Да вот если бы все было так просто. Это первое, что я попробовал сделать, так сказать, "на шару". bash-5.1$ cat /var/lib/pgpro/1c-14/temp/base/14760/PG_VERSION bash-5.1$ psql -h 127.0.0.1 -p 5433 -c 'select pg_wal_replay_resume()' и вот этот файл, я так понимаю, так просто не сфабриковать? В любом случае, хотелось бы хотя бы упоминания об этих "фичах" в документации, я на это дело убил несколько часов, экспериментируя с различными вариантами бэкапа-восстановления, разными базами.. Собирал анамнез.. А это, оказывается, так и должно :). Я до последнего был уверен, что где-то что-то пропустил, либо что-то не так сделал. Иначе это же где-то бы упомянули.. Я даже issues просмотрел почти все и прогнал поиском, прочитал, хоть отдаленно похожее.. В общем, кучу времени угробил зря, получается.. |
|
pg_filenode.map по сложнее, согласен... |
|
Ну ладно, притащил ради спортивного интереса этот файл из оригинального клатсера в этот новый, теперь другая ошибка: psql -h 127.0.0.1 -p 5433 -c 'select pg_wal_replay_resume()' Так оно работет или нет? Я имею в виду частичное восстановление.. Или все-таки я что-то делаю не так? |
|
Ээээ.... а побробуй не --db-include на нужную тебе базу, а --db-exclude на ненужную. Мда, забавно. |
|
Ну, слушай, с --db-exclude - отработало.. Во всяком случае дал подключиться к кластеру, грохнуть "исключенную" базу.. ну и при таком варианте есть и postgres и базы template $ psql -h localhost -p 5433 -l -t | cut -d'|' -f1 | sed -e 's/ //g' Так и что? Так и запишем - работает только при --db-exclude? |
|
Такой баг нужно обязательно чинить, такая важная фича как восстановление 1-й БД... |
|
Слегка настораживает отстутствие информации по этому багу. Либо никто данный функционал не юзает вообще, либо все юзают как раз с --db-exclude, либо это проявляется только с версии 14, с которой я и начал знакомство с продуктом.
если это не сарказм, то не озвучите примерные сроки починки? |
я не разработчик этого продукта. Этой фичей ещё ни разу не пользовался, так как у меня пока получается работать в стратегии 1 БД - 1 кластер |
В схожей ситуации помогло так же добавить к restore --db-include=postgres |
На боевом и резервном сервере установлен pg_probackup-14, и там и там postgrespro-1c-14
В боевом кластере находится две базы: utpfof, utprof-copy, в каталоге /var/lib/pgpro/1c-14/data.
Настроен бэкап кластера в режиме PAGE на резервный сервер, на нем хранятся бэкапы pg_probackup:
в инстансе: --instance=utprof,
в каталоге: -B /backup/pg/probackup,
WAL доставляются в тот же каталог и тот же инстанс.
На момент восстанволения на резервном сервере развернут postgrespro-1c-14, дефолтный кластер в каталоге /data содержит некие базы. Хочу восстановлить на резервном сервере из бэкапа только одну базу utprof, но не в кластер /data (чтобы не затереть существующие базы), а в клатсер /temp, в каталог /var/lib/pgpro/1c-14/temp, для того, чтобы потом из этого восстановленного кластера выгрузить логическим бэкапом базу utprof и загрузить ее в кластер /data.
Пытаюсь выполнить частичное восстановление на резервном сервере локально, в каталог /var/lib/pgpro/1c-14/temp.
При восстановлении использую такую команду:
pg_probackup-14 restore --instance=utprof -B /backup/pg/probackup -D /var/lib/pgpro/1c-14/temp -j 2 --db-include="utprof" --recovery-target-time="2022-12-06 13:30:03" --remote-proto=none --log-level-console=warning --log-level-file=verbose --log-directory=/var/log/pg_probackup --log-filename=restore_time.log
Восстановление проходит успешно (насколько я могу судить), в логе probackup:
2022-12-06 22:47:47 +07 [29796]: INFO: Restored backup files are synced, time elapsed: 4m:57s
2022-12-06 22:47:47 +07 [29796]: LOG: ----------------------------------------
2022-12-06 22:47:47 +07 [29796]: LOG: update recovery settings in postgresql.auto.conf
2022-12-06 22:47:47 +07 [29796]: LOG: Setting restore_command to '"/usr/bin/pg_probackup-14" archive-get -B "/backup/pg/probackup" --instance "utprof" --wal-file-path=%p --wal-file-name=%f'
2022-12-06 22:47:47 +07 [29796]: LOG: creating recovery.signal file
2022-12-06 22:47:47 +07 [29796]: INFO: Restore of backup RMGEJD completed.
Вот этот валидный бэкап
Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status
utprof 14 RMH8G5 2022-12-06 23:00:39+07 PAGE ARCHIVE 1/1 1m:37s 42MB 16MB 3.21 B/C000028 B/D01DE88 OK
utprof 14 RMGEJD 2022-12-06 12:14:25+07 PAGE ARCHIVE 1/1 55s 26MB 16MB 3.60 A/D3000028 A/D40843E0 OK
При запуске кластера postgres (на порту 5433), в логе кластера висит штатное сообщение:
2022-12-06 23:54:09.279 +07 [31199] LOG: pausing at the end of recovery
2022-12-06 23:54:09.279 +07 [31199] HINT: Execute pg_wal_replay_resume() to promote.
При попытке подключиться к кластеру и выполнить указанную команду, получаю ошибку:
bash-5.1$ psql -h 127.0.0.1 -p 5433 -c 'select pg_wal_replay_resume()'
psql: error: connection to server at "127.0.0.1", port 5433 failed: FATAL: "base/14760" is not a valid data directory
DETAIL: File "base/14760/PG_VERSION" does not contain valid data.
HINT: You might need to initdb.
Файл base/14760/PG_VERSION действительно имеет нулевой размер и не содержит данных, но ведь так и задумано, насколько я понимаю?
Но при этом я не могу вернуть кластер из режима readonly, чтобы дропнуть пустую базу, так как он именно из-за нее и не дает мне подключиться к кластеру?
При этом, если восстанавливать все базы в класетере (не частичное восстановление), при тех же параметрах (каталог /temp, другой порт кластера) то все прходит штатно, я подключаюсь к восстановленному кластеру, работаю с базами.
Я вроде все сделал по документации, не могу понять, в чем ошибка.
The text was updated successfully, but these errors were encountered: