Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Горячий дамп / 12 сообщений из 12, страница 1 из 1
19.01.2006, 19:53
    #33492901
SOmni
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
Порылся в форуме, нашел тему, в которой описанная проблема упоминается вскользь. Хотелось бы более подробно. Суть проблемы:
Имеется БД, изменение данных в которой происходит очень активно практически круглые сутки. Хочется делать дамп, но так, чтобы не лочить другие запросы (в документации написано, что дамп не лочит таблицы, тем не менее всё становится заметно тормознее вплоть до появления кучи update/select/insert waiting, что может плохо кончиться), а так же не получить размазанные по времени данные, т.е. дам должен быть как моментальный снимок БД на какой-то момент времени.
Кто-нибудь сталкивался с подобным?

PostgreSQL v 8.0.3
...
Рейтинг: 0 / 0
19.01.2006, 21:15
    #33492977
landy
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
Конфигурация железа какая, скорее всего проблемы с пропускной способностью шины дисковой подсистемы
...
Рейтинг: 0 / 0
20.01.2006, 09:21
    #33493321
SOmni
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
Точно сказать не могу сейчас, посмотреть нужно.
Но всё же вопрос не снят: позволяет ли PG сделать дамп как моментальный снимок БД во время активной работы с этой самой БД, не блокируя другие запросы.

Просто пример: запускаю pg_dump, в соседней консоли наблюдаю, что он просто складывает данные в текстовый файл, а т.к. это происходит минут 10, то вопрос: данные-то там получатся целостные (допуская, что все прочие запросы к БД так же выполняются)?
...
Рейтинг: 0 / 0
20.01.2006, 10:19
    #33493444
landy
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
да - данные целостные, на момент запуска утилиты. Изменения после этого момента в дамп не попадают
...
Рейтинг: 0 / 0
20.01.2006, 13:29
    #33494182
SOmni
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
Интересно, каким образом это происходит: и не лочится и данные в течение 10 минут не изменяются?
...
Рейтинг: 0 / 0
20.01.2006, 14:41
    #33494451
Andrey Daeron
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
SOmniИнтересно, каким образом это происходит: и не лочится и данные в течение 10 минут не изменяются?
Версионность. И типы изолированности транзакций.
Не знаю как в постгресе, а в firebird вроде как нельзя более 2-х конкурентно пишущих транзакций одновременно запускать. Т.е. если одна модифицировала значание, то вторая еще может туда чего-то записать, но 3-я уже нет (может уже и вторая не может). Так что де-факто все таки лочится, хотя и гораздо реже чем у блокировщика.
...
Рейтинг: 0 / 0
20.01.2006, 17:47
    #33494930
SOmni
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
Вобщем, итог, как я понимаю, такой?
В большой быстроменяющейся БД (PostrgeSQL) целостный дамп без блокировки не получить, но точно этого никто не знает, так что нужно тестировать.
...
Рейтинг: 0 / 0
20.01.2006, 17:53
    #33494943
landy
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
SOmniВобщем, итог, как я понимаю, такой?
В большой быстроменяющейся БД (PostrgeSQL) целостный дамп без блокировки не получить, но точно этого никто не знает, так что нужно тестировать.
Почему же?
На *х системах tar -czvf db.tgz /DATA
Прямо в онлайн - потом если этот архив развернуть и запустить postgresql - будет консистентная и непротиворечивая БД - уже тут обсуждалось
...
Рейтинг: 0 / 0
20.01.2006, 18:16
    #33495018
SOmni
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
Нашел. Прочитал. Буду думать.
...
Рейтинг: 0 / 0
20.01.2006, 18:17
    #33495019
4321
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
Andrey Daeron ...вроде как нельзя более 2-х конкурентно пишущих транзакций одновременно запускать. ... Так что де-факто все таки лочится, хотя и гораздо реже чем у блокировщика.не думаю, что тут дело в количестве транзакций(несложно проверить). но факт, что блокировка при апдейте/вставке в уникью завсегда имеет место. (т.е. если вы пишете со вставкой в уникью 2 конкурирующие, или с правкой в этом поле)

мне казалось, что блокировка в пг в этом случае из за неверсионности индекса. но и оракл, как оказалось лочит вторую транзакцию, правящую тот же "уникью" до момента завершения первой.

что же касается обсуждаемого вопроса - дамп не является "пишущей" транзакцией (т.е. писать он конечно пишет, но не в БД, в БД он только читатель) - т.ч. тормоза скорее всего будут только из-за конкуренции дисковых операций (дамп захочет много читать, а если еще и пишете он туда же, а не на другой диск....).
...
Рейтинг: 0 / 0
20.01.2006, 18:28
    #33495053
Andrey Daeron
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
4321 Andrey Daeron ...вроде как нельзя более 2-х конкурентно пишущих транзакций одновременно запускать. ... Так что де-факто все таки лочится, хотя и гораздо реже чем у блокировщика.не думаю, что тут дело в количестве транзакций(несложно проверить). но факт, что блокировка при апдейте/вставке в уникью завсегда имеет место. (т.е. если вы пишете со вставкой в уникью 2 конкурирующие, или с правкой в этом поле)

мне казалось, что блокировка в пг в этом случае из за неверсионности индекса. но и оракл, как оказалось лочит вторую транзакцию, правящую тот же "уникью" до момента завершения первой.

В общем-то звучит вполне логично, из серии, "а что мы будем делать, если потом при коммите окажется нарушение констрейнта?". Правда для firebird'а я слышал другое объяснение - что мол места всего 2 в которые писать можно, одно - в оригигнальном месте - второе log.

4321
что же касается обсуждаемого вопроса - дамп не является "пишущей" транзакцией (т.е. писать он конечно пишет, но не в БД, в БД он только читатель) - т.ч. тормоза скорее всего будут только из-за конкуренции дисковых операций (дамп захочет много читать, а если еще и пишете он туда же, а не на другой диск....).
А вот здесь и будет вопрос о том, где он сможет хранить версии. По версии firebird'а - будет держатся одна версия - на чтение, вторая - на запись, и третья, если будет - уже заблокируется.
Т.е. вредикт по вопросу если в настоящий момент все работает без блокировок, то и при дампе их появление крайне маловероятно.
...
Рейтинг: 0 / 0
21.01.2006, 10:02
    #33495431
Funny_Falcon
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Горячий дамп
Люди !!! Не лочить dump ничего т.к. он только читает!!! Сколько раз пробовал!!! Читает он в
serializable уровне изоляции - ни хрена не видит что делали транзакции __завершившиеся__ после
его начала (могли начаться и раньше) => данные не могут быть противоречивыми, если такими не
были изначально :-)
И индексы в Postgres версионные, только не хранят видимость записи - поэтому
и не возможно кеширование значений в индексе, как у SQL Server.
В общем: дамптись на здоровье :-) если дисковая система позволяет.
Сорри за эмоциональность.
...
Рейтинг: 0 / 0
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Горячий дамп / 12 сообщений из 12, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]