Здравствуйте, wraithik, Вы писали:
W>Подскажите, есть способ делать бекапы баз остановки работы пользовтелей.
А как ты это представляешь.
Вот ты начинаешь копировать данные в момент Х, а за это время пользователи вносят изменения в объеме dX.
Должен ли этот dX попасть в бекап?
1) если нет, и вам нужна консистентность на момент X, то придется заблокировать всех (делает pg_dump)
2) если да, то надо записать состояние X, заблокировав dX, а потом дозаписать dX, блокируя изменения в (X/dX). (так делает pg_basebackup)
W>pd_dump падает на блокировках.
С какой ошибкой то?
W>Нужен способ копировать базу данных в середине рабочего дня.
Репликация же и\или pg_basebackup
насколько я понимаю вы, как и большинство, пришли в постгрес с MSSQL. К сожалению, области администрирования он работает категорически не так, как MSSQL. Все ваши привычки и ментальные модели скорее всего ошибочны.
1) В MSSQL единица администрирования — база данных. Есть даже self-contained базы, которые содержат все настройки, в том числе безопасности. В Postgres — единица администрирования — сервер. Все настройки безопасности, отказоустойчивости, быстродействия выполняются на уровне сервера в PG.
2) WAL в MS SQL свой для каждой базы, в PG один для сервера. Поэтому и бекап удобный и полноценный в PG есть только на уровне сервера (pg_basebackup)
3) Контролей целостности данных в PG примерно на порядок меньше, чем в MS SQL, поэтому для каждого продуктивного сервера PG нужна реплика. Иначе вы рано иди поздно данные потеряете.
Итого: в проде PG у вас будет мастер и реплика. Если вы снимаете pg_dump с реплики, то реплкика временно останавливает накатку логов, но мастер при этом не блокируется.
Здравствуйте, wraithik, Вы писали:
W>Подскажите, есть способ делать бекапы баз остановки работы пользовтелей. W>pd_dump падает на блокировках. W>Нужен способ копировать базу данных в середине рабочего дня.
С какими параметрами запускаете pg_dump и какая точно ошибка?
У pg_dump есть параметр --lock-wait-timeout=timeout. Пробовали его выставлять?
G>>Вот ты начинаешь копировать данные в момент Х, а за это время пользователи вносят изменения в объеме dX. G>>Должен ли этот dX попасть в бекап? G>>1) если нет, и вам нужна консистентность на момент X, то придется заблокировать всех (делает pg_dump)
Gt_>да ладно. быть не может что бы так проигрывал конкурентам. PG классический версионник, в чем там может быть сложность вычитать таблицу на момент X без блокировок ?
Да вычитать то не проблема. Проблема в том, что за время бекапа таблица не должна поменяться. А то ты скопировал первые 1000 строк, другой пользователь сфорировал из них частичные суммы дописал в конец, а пока копировал вторую тысячу первую тысячу удалил.
Gt_>в доке тоже говориться что без локов обходиться: Gt_>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). Gt_>https://www.postgresql.org/docs/current/app-pgdump.html
Внезапно написанное не означает что без локов. Написанное означает что ты можешь выполнить запрос на чтение или запись и он выполнится. Не уточняя что иногда может выполнится после окончания бекапа.
pg_dump такто навешивает локи на таблицы во время бекапа, а некоторых режимах просто падает если таблица поменяется за время бекапа.
Здравствуйте, gandjustas, Вы писали:
G>Вот ты начинаешь копировать данные в момент Х, а за это время пользователи вносят изменения в объеме dX. G>Должен ли этот dX попасть в бекап? G>1) если нет, и вам нужна консистентность на момент X, то придется заблокировать всех (делает pg_dump) G>2) если да, то надо записать состояние X, заблокировав dX, а потом дозаписать dX, блокируя изменения в (X/dX). (так делает pg_basebackup)
Эмм,
1. в момент старта бэкапа
-- Выполнить checkpoint
-- Записать в WAL метку "начало бэкапа"
2. В момент окончания бэкапа записать в WAL метку "конец бэкапа"
3. Добавить к бэкапу фрагмент лога между метками "начало бэкапа" и "конец бэкапа".
Ни в какой момент ничего не блокируется
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подскажите, есть способ делать бекапы баз остановки работы пользовтелей.
pd_dump падает на блокировках.
Нужен способ копировать базу данных в середине рабочего дня.
Здравствуйте, BlackEric, Вы писали:
BE>Здравствуйте, wraithik, Вы писали:
W>>Подскажите, есть способ делать бекапы баз остановки работы пользовтелей. W>>pd_dump падает на блокировках. W>>Нужен способ копировать базу данных в середине рабочего дня.
BE>С какими параметрами запускаете pg_dump и какая точно ошибка? BE>У pg_dump есть параметр --lock-wait-timeout=timeout. Пробовали его выставлять?
По факту криво смотрел. Падало по памяти. Все поправил.
G>Вот ты начинаешь копировать данные в момент Х, а за это время пользователи вносят изменения в объеме dX. G>Должен ли этот dX попасть в бекап? G>1) если нет, и вам нужна консистентность на момент X, то придется заблокировать всех (делает pg_dump)
да ладно. быть не может что бы так проигрывал конкурентам. PG классический версионник, в чем там может быть сложность вычитать таблицу на момент X без блокировок ? в доке тоже говориться что без локов обходиться: 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). https://www.postgresql.org/docs/current/app-pgdump.html
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, wraithik, Вы писали:
W>>Подскажите, есть способ делать бекапы баз остановки работы пользовтелей. G>А как ты это представляешь.
G>Вот ты начинаешь копировать данные в момент Х, а за это время пользователи вносят изменения в объеме dX. G>Должен ли этот dX попасть в бекап? G>1) если нет, и вам нужна консистентность на момент X, то придется заблокировать всех (делает pg_dump) G>2) если да, то надо записать состояние X, заблокировав dX, а потом дозаписать dX, блокируя изменения в (X/dX). (так делает pg_basebackup)
Данные на момент запуска pg_dump, все что изменилось в процессе выгрузки — не должно попасть в выгрузку.
W>>pd_dump падает на блокировках. G>С какой ошибкой то?
Оказалось вообще не блокировка, но будем наблюдать.
W>>Нужен способ копировать базу данных в середине рабочего дня. G>Репликация же и\или pg_basebackup
G>насколько я понимаю вы, как и большинство, пришли в постгрес с MSSQL. К сожалению, области администрирования он работает категорически не так, как MSSQL. Все ваши привычки и ментальные модели скорее всего ошибочны.
Да, верно, в MS SQL это было очень просто.
G>1) В MSSQL единица администрирования — база данных. Есть даже self-contained базы, которые содержат все настройки, в том числе безопасности. В Postgres — единица администрирования — сервер. Все настройки безопасности, отказоустойчивости, быстродействия выполняются на уровне сервера в PG. G>2) WAL в MS SQL свой для каждой базы, в PG один для сервера. Поэтому и бекап удобный и полноценный в PG есть только на уровне сервера (pg_basebackup) G>3) Контролей целостности данных в PG примерно на порядок меньше, чем в MS SQL, поэтому для каждого продуктивного сервера PG нужна реплика. Иначе вы рано иди поздно данные потеряете.
G>Итого: в проде PG у вас будет мастер и реплика. Если вы снимаете pg_dump с реплики, то реплкика временно останавливает накатку логов, но мастер при этом не блокируется.
Спасибо, попробую.
pg_basebackup — весь сервер дампит, фактически создавая его копию, типа как в MS SQL дамп базы данных?
Здравствуйте, wraithik, Вы писали:
W>Здравствуйте, gandjustas, Вы писали:
G>>1) В MSSQL единица администрирования — база данных. Есть даже self-contained базы, которые содержат все настройки, в том числе безопасности. В Postgres — единица администрирования — сервер. Все настройки безопасности, отказоустойчивости, быстродействия выполняются на уровне сервера в PG. G>>2) WAL в MS SQL свой для каждой базы, в PG один для сервера. Поэтому и бекап удобный и полноценный в PG есть только на уровне сервера (pg_basebackup) G>>3) Контролей целостности данных в PG примерно на порядок меньше, чем в MS SQL, поэтому для каждого продуктивного сервера PG нужна реплика. Иначе вы рано иди поздно данные потеряете.
W>pg_basebackup — весь сервер дампит, фактически создавая его копию, типа как в MS SQL дамп базы данных?
Да, см п1
pg_basebackup делает просто копию всех файлов и одновемеенно тянет wal, получается копия консистентная на момент конца бекапа. Но всего сервера, так как wal общий.
pg_dump делает копию консистентную на момент начала бекапа, нужен в основном для переноса базы и\или апгрейда.
Практика показывает что для обной базы (одного набора баз, если микросервисы) лучше иметь отдельный инстанс постгри. При этом очень легко поднять несколько инстансов на одном сервере и настройками разрулить, чтобы они не падали по OOM
Gt_>>да ладно. быть не может что бы так проигрывал конкурентам. PG классический версионник, в чем там может быть сложность вычитать таблицу на момент X без блокировок ? G>Да вычитать то не проблема. Проблема в том, что за время бекапа таблица не должна поменяться. А то ты скопировал первые 1000 строк, другой пользователь сфорировал из них частичные суммы дописал в конец, а пока копировал вторую тысячу первую тысячу удалил.
выглядит что вы даже в общих чертах не представляете как работают версионные субд и постгре в частности.
вот тут говорится, что там обычная транзакция
pg_dump runs in a transaction-snapshot mode transaction
Gt_>>>да ладно. быть не может что бы так проигрывал конкурентам. PG классический версионник, в чем там может быть сложность вычитать таблицу на момент X без блокировок ? G>>Да вычитать то не проблема. Проблема в том, что за время бекапа таблица не должна поменяться. А то ты скопировал первые 1000 строк, другой пользователь сфорировал из них частичные суммы дописал в конец, а пока копировал вторую тысячу первую тысячу удалил.
Gt_>выглядит что вы даже в общих чертах не представляете как работают версионные субд и постгре в частности.
Gt_>вот тут говорится, что там обычная транзакция
Gt_> pg_dump runs in a transaction-snapshot mode transaction
Gt_>https://github.com/postgres/postgres/blob/master/src/bin/pg_dump/pg_dump.c
более того, в постгресе можно шарить один и тот же снапшот между разными соединениями и бэкапить из многих потоков / процессов параллельно.
pg_dump так тоже умеет делать насколько я помню
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Вот ты начинаешь копировать данные в момент Х, а за это время пользователи вносят изменения в объеме dX. G>>Должен ли этот dX попасть в бекап? G>>1) если нет, и вам нужна консистентность на момент X, то придется заблокировать всех (делает pg_dump) G>>2) если да, то надо записать состояние X, заблокировав dX, а потом дозаписать dX, блокируя изменения в (X/dX). (так делает pg_basebackup) S>Эмм, S>1. в момент старта бэкапа S>-- Выполнить checkpoint S>-- Записать в WAL метку "начало бэкапа" S>2. В момент окончания бэкапа записать в WAL метку "конец бэкапа" S>3. Добавить к бэкапу фрагмент лога между метками "начало бэкапа" и "конец бэкапа". S>Ни в какой момент ничего не блокируется
это все здорово но pg_dump так не делает
он элементарно стартует read-only repeatable read транзакцию
после этого все чтение внутри этой транзакции читается из снапшота созданного на момент ее старта, новые изменения ей не видны
этот снапшот можно использовать из других соединений тоже если передать его id — бэкапить в несколько потоков
никакой фрагмент лога никуда не добавляется, если кто-то что-то закоммитил за время бэкапа — в бэкап не попадает
Здравствуйте, VladiCh, Вы писали: VC>это все здорово но pg_dump так не делает VC>он элементарно стартует read-only repeatable read транзакцию VC>после этого все чтение внутри этой транзакции читается из снапшота созданного на момент ее старта, новые изменения ей не видны VC>этот снапшот можно использовать из других соединений тоже если передать его id — бэкапить в несколько потоков VC>никакой фрагмент лога никуда не добавляется, если кто-то что-то закоммитил за время бэкапа — в бэкап не попадает
Но этот способ, как мы знаем из ТС, падает на блокировках.
Я всего лишь объяснял, как сделать бэкап, не падая на блокировках, и не жертвуя консистентостью бэкапа. Способ вполне себе дедовский. Описан, например, в Гарсиа-Молина раздел 17.5.2, стр. 872.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, VladiCh, Вы писали: VC>>это все здорово но pg_dump так не делает VC>>он элементарно стартует read-only repeatable read транзакцию VC>>после этого все чтение внутри этой транзакции читается из снапшота созданного на момент ее старта, новые изменения ей не видны VC>>этот снапшот можно использовать из других соединений тоже если передать его id — бэкапить в несколько потоков VC>>никакой фрагмент лога никуда не добавляется, если кто-то что-то закоммитил за время бэкапа — в бэкап не попадает S>Но этот способ, как мы знаем из ТС, падает на блокировках. S>Я всего лишь объяснял, как сделать бэкап, не падая на блокировках, и не жертвуя консистентостью бэкапа. Способ вполне себе дедовский. Описан, например, в Гарсиа-Молина раздел 17.5.2, стр. 872.
ничего там не падает на блокировках, ваш ТС чего-то напутал
Здравствуйте, wraithik, Вы писали:
W>Подскажите, есть способ делать бекапы баз остановки работы пользовтелей. W>pd_dump падает на блокировках. W>Нужен способ копировать базу данных в середине рабочего дня.
