Re[4]: [Comm] Репликация базы данных PostgreSQL на двух компьютеров

[=?iso-8859-1?q?iceb_=CE=C1_svitonline=2Ecom?=]

В Срд, 17 Мар 2004, Evgeny Yugov написал(а):

EY> isc> Вовсе нет. Если есть возможность из этого лога получить
EY> текущее
EY> isc> состояние базы - то почему бы его не rsync'нуть ?
EY> А чем вариант rsync в таком случае отличается от pg_dumpall?
EY> Все равно старт/стопать базу прийдется...

А что, лог транзакций в постгресе формируется только по команде,
не в риалтайме ? И для его получения надо базу стопорить ? Так
это не лог тогда называется.
Ну тогда rsync напускать на всю базу. Не бог весть что, но хоть
что-то...

EY>
EY> EY>> isc> PS. И эти люди что-то говорят о преимуществах
EY> перед
EY> EY>> MySQL ...
EY> EY>> А что мускул умеет реплицировать?
EY> isc> Да уж несколько лет как. Я лично его тремя способами
EY> бэкаплю:
EY> isc> 1) репликация - риалтаймовый бэкап
EY> Хм интересно... поподробнее можно?

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

EY>
EY> isc> 2) rsync на дамп и журналы - периодический, раз в час
EY> обычно
EY> isc> 3) некое подобие (2) на виндовую машину - если
EY> поблизости нет
EY> isc> линуксовой
EY>
EY> ps Было бы здорово если бы Вы накидали схемку с коментариями
EY> и
EY> описанием, многие сказали бы спасибо... :o)

Что касается репликации - все (почти) RTFM Справочное
руководство по MySQL версии 4.0.11-gamma где-то на
http://www.mysql.com.

Второй способ - классический, использовался практически на всех
приличных СУБД еще лет 20 назад если не больше. Суть заключается
в следующем:

1) относительно редко выполняется полный дамп базы данных, на
всякий случай с остановом и чеканьем. Получаем большой файл,
который ложим на ленту/съемный диск/другую машину по вкусу.

2) после запуска СУБД ведет т.н. инкрементные журналы, в которых
в реальном времени записываются все изменения, произошедшие со
времени последнего дампа (для первого журнала)
или со времени закрытия предыдущего журнала (для всех последующих).
Получаем много мелких файлов,
причем в ходе работы изменяется только последний. Никакие
рестарты при этом не нужны.
Полученные файлы тоже сохраняются по мере создания, но времени и
ресурсов на это требуется очень немного.

3) goto 1

Понятно, что для сохранения дампа и журналов в сегодняшних
условиях удобно использовать rsync (хотя это не единственно
возможный механизм).

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

Более подробно расписывать - времени нет, сорри. Но думаю идея
понятна, а подробности - для этого дока есть.

-- 
Yura Kalinichenko