Добрый день.

Господа, выручайте, в связи с ограничением времени на разработку - возникла запарка.
Есть задача разработать, встраиваемую систему управления неким оборудованием (ОС - Win XP Embedded).
В качестве хранилища будет использоваться PostgreSQL.
Для повышения отказоустойчивости необходимо организовать failover.
Т.к. система встраиваемая, управление failover-ом предполагается возложить на один из программных модулей системы.
На вскидку выплывает след решение:
при старте (постгри) необходимо договориться кто будет мастером, кто слейвом.
затем работаем в соответсвии с проведенными выборами и одновременно мониторим
друг друга на предмет отзывчивости.
Собственно вопрос: может кто решал уже такую задачу, что посоветуете?
Ну а если не решал, ткните носом в механизм исполнения пользовательского кода
при старте/стопе постгри.

С уважением, Константин.

>непонятно: ну договорились, ну мониторите, а что с базой?
>У каждого сервера будет своя?
>как будет поддерживаться актуальное состояние баз на обоих серверах?
У каждого своя. Есть процесс который "кладет" в базу исходные данные для обработки.
Он же и будет их "раскладывать" на оба сервера, остальные процессы ведомой "железки" будут "спать".

>вы уверены что вам нужен пг в embedded системе? здесь, на форуме, неоднократно упоминалось о >том, что пг не самый лучший вариант для использования во встраиваимых системах.
На самом деле, встраиваемые машинки не так уж и слабы: AMD Geode 700, 512Mb, 40Gb.
Если можно поподробней чем плож пг на таком железе...

С уважением, Константин.

>вы уверены что вам нужен пг в embedded системе? здесь, на форуме, неоднократно упоминалось о >том, что пг не самый лучший вариант для использования во встраиваимых системах
Просмотрел темы с ключ. словом embeddded и понял что там хотели другого.
Нам необходим полноценный пг, на полноценной железке, с реализацией файловера...
ОСь уже готова, ничего лишнего: ядро,tcpip, session manager, pgsql - время загрузки ~30c.

С уважением, Константин.

Похвально, но вот о том, что будет за база, Вы ни слова не сказали. Тут не телепаты тусуются.[/quot]
Так ведь вопрос то был не о базе а о способах организации файловера.

>Похвально, но вот о том, что будет за база, Вы ни слова не сказали. Тут не телепаты тусуются.
Так ведь вопрос то был не о базе а о способах организации файловера.
Структура базы еще не определена и окончательно "нарисуется" когда будет определен алгоритм организации файловер-а.
Концептуально структура самой базы не так уж и сложна и важна.

>Я имел ввиду не структуры базы, а ее предназначение. Вот что важно. Если у вас одни выборки будут, >тут и думать особо не чего, решением будем, скажем, carp. Если преобладают изменения, решать уже >о периодической синхронизации или же репликации. И так далее и тому подобное...
Нет, не только выборки, carp-ы, pgpool-ы... уже отвергнуты.
Есть три процесса осуществляющие взаимодействие с ПГ: процесс В/В (работает с аппаратурой) в осовном "кладет" считанные с датчиков данные в БД (иногда читает: конфигурацию или когда придет команда "поуправлять" объектом), сам процесс ядра - мозги (и пишет и читает) и процесс ГУИ (в основном читает).
Процессы на мастере будут "раскладывать" данные и на себя и на слейв, а на слейве процессы будут спать до времени Ч (краха мастера).
Вообщем пришли к выводу, что нужна своя реализация т.к. файловер нужен не только в БД, а также и на все процессы (кто-то "спит", кто-то работает в "параллеле").
Пока не могу быстро найти, как в постгресе "дернуть" пользовательский триггер или функцию при старте сервера...

С уважением, Константин.

>Никак. Равно как и на логине пользователя. Стандартное решение - на клиенте после коннекта чего-нить дергать, или cron'ить.
Жаль, значит придется смотреть на pgAgent.