Всем привет. Как называется утилита для бэкапов?

pg_dump!

Спасибо

Из поставки — pg_basebackup. Есть много сторонних, и лучше использовать их.

Погоди, щас ещё накидают и расскажут, что это не бекап.

Спасибо

Можно я буду использовать в тривиальных случаях? Спасибо!

Да пожалуйста (его может вообще использовать каждый, кому не нужны ни business continuity... ни данные, если "повезёт"). ;)

Вот я в чате лет эдак пять. И кажется, я постоянно пропускаю пример потери данных пэгэдампом.

Вот уж я зарекался давать примеры concurrency в чатах (потому что, как выясняется, мало кто способен нажимать на кнопки в указанном порядке)... но вот, специально для Вас — возьмите и воспроизведите: -- Preparation: CREATE SCHEMA db; SET search_path = 'db'; CREATE TABLE t1(id int PRIMARY KEY); CREATE TABLE t2(id int PRIMARY KEY, x int NOT NULL); -- This is just for more fun, not actually required to reproduce the problem: ALTER TABLE t1 ADD FOREIGN KEY (id) REFERENCES t2(id); INSERT INTO t2(id, x) VALUES (1, 1), (2, 1), (3, 1), (4, 1), (5, 1); INSERT INTO t1 VALUES (1), (2), (3); -------------------------------------------------------------------------------- -- Repro: BEGIN TRANSACTION; LOCK TABLE t1; -- Start pg_dump now, e.g.: -- pg_dump -d test_dump -f test_dump.sql -- (it'll hang) ALTER TABLE t2 ALTER COLUMN x TYPE bigint; COMMIT; -- The dump will successfully (!) finish. Check it.

А чё не dd в процессе копирования? Гораздо надёжнее сломается.

Я что, здесь сделал что-то нештатное, извините? Или Вы явно и ото всех требуете не дышать не выполнять DDL, когда делаете дампы? ;)

Можно ещё электошокером в накопитель тыкать. Вполне штатная функция.

Это что, стадия "отрицание"? ;) Мне повторить вопрос?

Да. Отключить пользователей, сдампить и включить назад. Очень просто и надёжно.

И пусть весь мир подождёт (несколько часов, например). Тем не менее, Вы просили пример потери данных — и вот он! Вообще, так можно долго продолжать в духе "не, ну так нельзя делать"... и "ой, а вот этого же тоже нельзя" (если я начну показывать, как снимаются невосстанавливаемые дампы, например — но это мы тут уже видели)? И все эти "нельзя" должны обеспечиваться тем, что DBA постоянно стоит над пользователями и бьёт их по рукам, если что не так, я правильно понимаю? ;)

Нет, не правильно. Человек берёт свою настольную базу и дампит.

так какое средство из коробки? ))))))) сторонние не принмаются

И она не дампится или не восстанавливается, представляете? Потому что кто-то ранее там сделал то, что "нельзя" (с чем админы/программисты 1С даже иногда сталкиваются на практике). Так как насчёт этого, а?

https://t.me/pgsql/478894

Вы, Ярослав, всё ещё не понимаете, что мир состоит не только из DBA, которые лочат таблицы в процессе дампа.

А Вы, Роман, так и не поняли, что: . Дамп — это "игрушка", и те "DBA", кто его использует для DR, такие же "игрушечные" DBA. . Для того, чтобы получилось "не дампится или не восстанавливается", лочить не нужно. У меня начинает появляться впечатление, что Вы просто игнорируете те части моих сообщений, которые Вам не нравятся. ;( > то добрые DBA их регулярно проверяют. Отлично, проверили — не восстанавливается (повторения не помогают). Какие действия, конкретно? Или попытались снять — не снимается (повторения не помогают). Какие действия, конкретно?

Ещё раз. Пишу специально медленно: нет DBA. Есть настольная база, с которой работает пользователь. Или даже два пользователя. Не DDL фигачат, а работают с данными. Есть приложения, которым требуется бекенд с СУБД. И надо развернуть базу на произвольной платформе. И вот среди этих людей ваши "настоящие" DBA с "настоящими" (чем там? DR?) пусть будет DR — ноль целых хрен десятых процента.

Ещё раз. Пишу специально медленно: > Не DDL фигачат, а работают с данными. DDL для того, чтобы такое случилось (не потеря данных в дампе, а именно невозможность снять или восстановить дамп) не нужен. Так что насчёт того, что им делать, если с ними это вдруг случится? > И надо развернуть базу на произвольной платформе. Да, для этого можно использовать дамп — это совсем не DR. > пусть будет DR Так я про него и писал. Вроде, достаточно медленно. ;) > ноль целых хрен десятых процента. Т.е. грамотных специалистов в СУБД там нет. Но, если взять аналогичную ситуацию, то топор не является лучшим хирургическим инструментом, например. ;)

Кстати, как ваш «настоящий» бекап с линукса на виндовс утащить?

Никак. Именно потому, что это backup. А на вопросы Вы так и не ответите, я правильно понял?

Зачем? Если вам нравится называть бекапом нечто, что переживает параллельный DDL — то я не против. Соглашаться с этим определением я не буду.

Да затем, что Вам нравится называть бекапом нечто, что иногда невозможно снять или восстановить. И Вы этот "несущественный" момент ловко игнорируете уже... в третий раз, нет? ;) > Соглашаться с этим определением я не буду. К счастью, определениям не требуется, чтобы с ними был согласен Роман Жарков. ;) Тем не менее, речь-то даже не об этом...

pg_dump is a utility for backing up a PostgreSQL database.

Очередная ошибка в документации (по которой издалека видно, что её писали не DBA, а программисты).

Баг репорт есть?

Ага. Ссылка не проставилась на тред от скорости :)

https://www.postgresql.org/message-id/1599765595731-0.post%40n3.nabble.com

Мда. Кажется, до слова pg_dump никто там не дочитал даже :)

Может быть, но мне уже как-то... https://t.me/pgsql/478971 Но кто угодно может выхватить знамя из рук падшего бойца, в конце-то концов (я только за). ;)

Ненене. Мне нравится считать, что таблица, аккуратно переписанная на бумажку — это бекап.

переписаная двумя людьми после сверки третьим - несомнееенно 😜

Да кто угодно может считать, как хочет — пока с другими людьми не надо общаться. ;) https://xkcd.com/1860/ А вообще, практическая суть тут не в терминологии.

Вы устарели, господа. Нынче модно фотографировать скрин таблицы с монитора на телефон. При этом телефон надо держать вертикально.

так для большой таблицы лучше видео)

с углом 70*

Да много раз бывало. Пропустит какую-нибудь таблицу из-за нетакой строчки...

Где-то тут пролетела проблема строчки длиной ~250 мег. pg_restore кажется спотыкается не осилив аллоцировать больше гига памяти.

На слишком длинных полях "сломается" уже pg_dump. Тоже легко воспроизводится: CREATE SCHEMA db; SET search_path = 'db'; CREATE TABLE t(x bytea); INSERT INTO t(x) SELECT repeat('a', 1000000000)::bytea; -- Trying to dump it: pg_dump: error: Dumping the contents of table "t" failed: PQgetResult() failed. pg_dump: detail: Error message from server: ERROR: invalid memory alloc request size 2000000003 pg_dump: detail: Command was: COPY db.t (x) TO stdout; И это всё, "приплыли".

Ну дамп-то не должен такого делать в теории, поэтому про это хоть можно писать bug reports...

Прекрасное) когда исправят?))))

Проблема в том, что это не проблема пэгэдампа как такового :)

А чья же это проблема? pg_dump такой базы выполнить невозможно, вот в чём суть.

И считается что это нормально?

По крайней мере, в сообществе всем на это как-то ... ;(

А это да (((((

Да чо приплыли. Дампишь всё, кроме данных этой таблицы, для этой таблицы кидаешь COPY всего, кроме проблемных строк, для проблемных строк — пишэшь отдельный update по 50 мегабайт кусками. Первый раз что ли...

Никто не чешэтся. И да, там надо начинать со всяких pluggable toaster и API для стриминга длинеых значений...

При чём тут UPDATE?! Тут кто-то хотел "копию" базы для чего-то там (а то и DR), понимаете? Так что, если использовать именно pg_dump, то в момент, когда это происходит, система костылей и подпорок на основе pg_dump просто накрывается — вот поэтому "приплыли".

Там надо почесать примерно всё.

Ну и да, для восхитительных умниц тех, кто доигрался с дампами, есть https://github.com/lzlabs/pg_dumpbinary (но я лично никогда не пользовался).

Просто прекрасно, ну да jsonb пилить лучше 😂😂😂😂

Ну, вот дамп несдампился или незагрузился — поднимаешься, пишэшь обёртку, в которой всё работает.

Точно, этим дармоедам-DBA на работе делать-то больше нечего ;) Чего только не выдумают, чтобы не пользоваться адекватными инструментами...

Воспроизводится без pg_dump.

Второй день продолжается битва титанов...

Тут пахнет бажиной в COPY

Разумеется, а Вы чего ожидали? Именно из того, что PostgreSQL — не full-ACID RDBMS (когда речь идёт о конкурентном DDL), следует, что у pg_dump всегда будут проблемы в подобных ситуациях. Соответственно, писать bug repots на эту тему бесполезно, если что.

Бекап!