Репликация данных между PG-SQL серверами

Можно-ли в PgSQL настроить репликацию данных между двумя серверами?
Цель: Добиться повышения отказоустойчивости и иметь возможность в случае выхода из строя первого сервера задействовать второй (автоматически или вручную). Что-то вроде Mirror в MSSQL.

Возможно будут альтернативные идеи...

Заранее благодарен!

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Репликация для

Репликация для PostgreSQL существует как для балансировки нагрузки так и для отказоустройчивости.
Копать надо в сторону продукта Slony.
Есть одна старая статейка здесь на сайте:
http://postgresql.ru.net/docs/sloniki-privet.html
Ну и конечно английская дока:
http://slony.info/documentation/

Репликация, но по требованию !!!

Slony - это хорошо, но не совсем...
Попытаюсь растолковать ситуацию.
Имеется несколь филиалов.
В цетральном офисе подготавливается информация для филиалов, цены, товар, поставщики и прочее.
Изменения происходят в нескольких таблицах, причем логически достоверны эти данные будут не сразу,
а например в конце рабочего дня, а то может быть и на следующий день.
Потом эта база копируется для проверки, тестирования и только потом ее разрешено синхронизировать с филиалами.
Как видно репликация в реальном времени не реальна (а может я не прав...).
Т.е. синхронизировать базы нужно в определенный момент времени, например ночью в субботу.
"Грубое" восстановление бэкап'а тоже не подходит, филиал работает почти круглосуточно.
Правда есть пауза с 6 до 7 утра, но запускать восстановление базы через cron как-то боязно.
Может кто-то уже имеет опыт ?
Подскажите пожалуйста.
С уважением,
Сергей Гришенков

Сталкивался с

Сталкивался с такой ситуацией - обычно она имеет место на торговых площадках. Причём ситуация не имеет к PostgreSQL никакого отношения. Решается это правильной структурой БД и организацией выгрузок из центральной базы с последующей загрузкой этих выгрузок на филиалы.

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

Если же стурктура БД не продумана (нет полей хранящих время изменения записи), то всё будет гораздо трудней! Тогда вы можете попробовать всё-таки использовать тот же Slony, только вам нужно как-то исхитрится, чтобы репликация не была включена всё время, а включалась только в определённое время (например тривиально поднимать и укладывать TCP/IP соединение от сервера к серверу).

Увы не прокатит

Увы не прокатит, т.к. база - 1С (((

Извините, но

База 1С ничем не отличается от любой другой!
Если не получается выгрузки делать, то как я и писал - поднимайте Slony на репликацию, но эмулируйте отказ соединения между площадками до времени, когда нужно провести синхронизацию.

Есть ещё одна

Есть ещё одна мысль.

Держите 2 базы. Одна текущая - рабочая. Вторую актуализируете восстановлением полного бакапа от главного сервера. Далее делаете подмену: актуализированная становится рабочей, а рабочая старой. Время переключения максимум 5 минут - вам должно хватить за тот час, о котором вы писали.

@admin: а это еще интересней....

@admin:
> Держите 2 базы. Одна текущая - рабочая.
> Вторую актуализируете восстановлением полного бакапа от главного сервера.
> Далее делаете подмену: актуализированная становится рабочей, а рабочая старой.
> Время переключения максимум 5 минут - вам должно хватить за тот час, о котором вы писали.
Тоже надо попробовать эту идею.
База в принципе не очень большая, так что две-три поместятся.
Что имется ввиду - подмена ?
Стоп / Старт базы или смена порта в приложении ?

Я имею в виду

Я имею в виду переименование базы на сервере например. Если это технически невозможно, то можно поднять 2 копии PostgreSQL с одним и тем же именем базы но на на разных портах и переключать порты.

@admin: Была такая же идея, но до использования еще не дошел

@admin
> Причём ситуация не имеет к PostgreSQL никакого отношения.
Ну не совсем так... Например выгрузку/загрузку можно заменить на PITR.
В этом случае на стороне клиента нужно просто перезапустить Postgres.
Хотя задержка будет не большой, но все-таки это задержка...  :-(

> Таким образом вам нужно написать систему скриптов,
> которая будет выгружать новую или изменившуюся информацию
> из таблиц в некий файл, а на стороне филиала скрипт,
> который будет этот файл загружать в базу - вот собственно и всё.
Сделаны скрипты по полному Backup/Restore.
Попробую так сделать, вижу плюс, что не надо останавливать базу и
размер изменению не очень большой.
Минус, надо писать программу опредения изменений в базе.

> Если же стурктура БД не продумана (нет полей хранящих время изменения записи),
> то всё будет гораздо трудней!
Предусмотрено.  :-)

> Тогда вы можете попробовать всё-таки использовать тот же Slony, только вам нужно как-то исхитрится,
> чтобы репликация не была включена всё время, а включалась только в определённое время
> (например тривиально поднимать и укладывать TCP/IP соединение от сервера к серверу).
Почему-то нет у меня веры в slony.... Не могу сказать почему, где-то на уровне подсознания...

Спасибо посмотрю

Спасибо посмотрю

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Back to top

(С) Виктор Вислобоков, 2008-2023