The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Горячий бэкап PostgreSQL "
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Скрипты, настройки и файлы конфигурации. (Public)
Изначальное сообщение [Проследить за развитием треда]

"Горячий бэкап PostgreSQL " 
Сообщение от anonymous Искать по авторуВ закладки(??) on 02-Июн-04, 09:23  (MSK)
Нужно несколько раз в день, делать бэкап PostgreSQL базы (размер данных около 1 Гб.). pg_dump[all] слишком долго выполняется и при этом сервер ощутимо тормозит.

Готовых решений для горячего бэкапа pgsql не нашел, поэтому думаю применить следующую методику:

while (перебираем все таблицы){
    Ставим эксклюзивный лок на таблицу
    Копируем все файлы этой таблицы и индексы.
    Снимаем лок.
}

Насколько такая схема оправдана, не будет ли проблем ? Слишком просто все
получается.

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

  Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "Горячий бэкап PostgreSQL " 
Сообщение от Delhin Искать по авторуВ закладки on 03-Июн-04, 09:57  (MSK)
>while (перебираем все таблицы){
>    Ставим эксклюзивный лок на таблицу
>    Копируем все файлы этой таблицы и индексы.
>    Снимаем лок.
>}
>
>Насколько такая схема оправдана, не будет ли проблем ? Слишком просто все
>
>получается.

а получаем в итоге невосстановимый бекап ;)
1-ая таблица - справочник
N-ая таблица - данные с внешним ключем указывающим на 1-ую таблицу

За период времени с лока 1-ой таблицы до лока N-ой таблицы есть вероятность добавления записей в 1-ую таблицу и в записей в N-ую таблицу
т.е. мы в N-ой таблице получим записи которые потом не сможем восстановить, т.к. в справочной таблице их не будет и ограничение по внешнему ключу даст ексепшен. Вот и все собственно %)
Тут единственный выход все делать в одной SERIALIZABLE транзакции.
>
>Другая идея - реплицировать данные на второй сервер, но чувствую что проблем
>здесь будет горяздо больше, и не только с надежностью, но и
>с быстродействием.
тут уже стоит подумать и посмотреть поподробнее, имхо это будет путь более правильный и маштабирыемый.

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Горячий бэкап PostgreSQL " 
Сообщение от dev emailИскать по авторуВ закладки(??) on 08-Июн-04, 14:42  (MSK)
>Нужно несколько раз в день, делать бэкап PostgreSQL базы (размер данных около
>1 Гб.). pg_dump[all] слишком долго выполняется и при этом сервер ощутимо
>тормозит.

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

В постгресовской рассылке был анонс системы репликации (slony1). Говорят, что работает очень быстро. Может, попробовать реплицировать базу на второй сервер и с него уже брать pg_dump?

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх


Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру