Добрый день. Изучаю postgresql 12. Делаю бэкап базы ''. Пока

Question

Добрый день. Изучаю postgresql 12. Делаю бэкап базы ''. Пока

делается бэкап, в исходной БД делаю изменения : удаляю/добавляю таблицы, добавляю/удаляю столбцы в таблицах. В документации сказано "Программа pg_dump не препятствует доступу других пользователей к базе данных (ни для чтения, ни для записи)." Но при это я вижу что транзакции висят до тех пор пока pg_dump не отработает. Правда изменения я делаю через pgAdmin. Подскажите я не понимаю или делаю что-то не так ?

#backend #devops #pgsql #programming #russian

0

07.10.2020

11 ответов

7 просмотров

Wadik Wadkovich Автор вопроса

Danil S.
Какой у вас тип изоляции транзакций ?

Опа, не знаю. Вообще по дэфолту стоит, туда не лез

0

07.10.2020

Danil S.

Wadik Wadkovich
Опа, не знаю. Вообще по дэфолту стоит, туда не лез

Там случайно нет пометки, что имеется в виду uncommitted write\read ?

0

07.10.2020

Wadik Wadkovich Автор вопроса

Danil S.
Там случайно нет пометки, что имеется в виду uncom...

https://postgrespro.ru/docs/postgresql/12/app-pgdump Читаю тут, вроде нету нечего

0

07.10.2020

Yaroslav Schekin

> Делаю бэкап базы > Программа pg_dump Это не backup, это дамп (и да, документацию я читал, если что). Т.е. использовать их в целях Disaster Recovery практически невозможно в нетривиальных ситуациях. > "Программа pg_dump не препятствует доступу других пользователей к базе данных (ни для чтения, ни для записи)." Это просто неправда (ошибка/неточность в документации). pg_dump блокирует практически весь DDL. > Подскажите я не понимаю или делаю что-то не так ? Вы чересчур доверяете документации. ;( Я Вам больше скажу: pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers). Каждое предложение здесь — неправда, строго говоря.

0

07.10.2020

Wadik Wadkovich Автор вопроса

Yaroslav Schekin
> Делаю бэкап базы > Программа pg_dump Это не bac...

> Это не backup, это дамп (и да, документацию я читал, если что). Т.е. использовать их в целях Disaster Recovery практически невозможно в нетривиальных ситуациях. Не понял этого. Я не могу восстановить базу из этого дампа на другом сервере ?

0

07.10.2020

Yaroslav Schekin

Wadik Wadkovich
> Это не backup, это дамп (и да, документацию я чи...

Скорее всего (но не факт), что сможете. А вообще, дайте я процитирую себя же из -hackers по этому поводу: ;) The whole point of the [Backup and Restore] chapter is backwards. If the data is valuable, one wants to prevent (or recover) from its loss. Backups are just a *mean* for that, while data loss avoidance is the *goal*. Enters disaster recovery (and more broadly business continuity). Two metrics are fundamental to that: RPO and RTO. Using pg_dump, one cannot even get predictable values for those in any non-trivial case. Therefore, "25.1. SQL Dump" should not be first and foremost in the chapter (if mentioned at all); and the whole chapter better be written with the above in mind. At least, it would be nice if dumps were called dumps, not backups, as well as the process of making those was called dumping in "25.1. SQL Dump".

0

07.10.2020

Eugeny

А точно транзакции висят? Какие именно? Ddl будет висеть. И все, что после него.

0

07.10.2020

Wadik Wadkovich Автор вопроса

Eugeny
А точно транзакции висят? Какие именно? Ddl будет ...

Да, получается DDL и висели

0

07.10.2020

Eugeny