что сделать? Как базу поднять? Или что?

Если вы о репликации, то вот - Maset-Slave репликация

идет речь о astdb.
а разве astdb хранится в mysql?

Нет, она не хранится в MySQL. Но в 1.6 (?) данные о регистрациях будет возможно хранить в реалтайм, семейство sipregs. Как-то совсем недавно обсуждалась схема сихронизации двух серверов (в списках рассылки). Ссылку найти довольно просто.

нет, астдб не хранится в мускуле.
ваще-та, astdb - это обычный файлик. я думаю, если этот файлик реплицировать на слейв-сервер, то ваш кластер вполне будет работать (я смотрел код - оно по каждому чиху файлик записывает).

думаю, при желании можно запросто переписать и на мускуль - там всего несколько функций (чтение, запись, инит и еще какая-то одна-две)

astdb - это старая Berkeley Db 1.85 , драйвера для поддержки которой уже не так просто прикрутить к какому-нибудь скриптовому языку..

все это понятно. во freepbx есть средство для бакапа/восстановления astdb. но вопрос-то такой:

состояние регистрации пиров действительно хранится в astdb?

to switch

Hе первый раз на эту тему говорим. И я опять пытаюсь вас подтолкнуть к имеющемуся(в арсенале астериска) решению.

Как, допустим, я вижу ваше решение:

Я бы использовал Realtime с хранением sip(iax) юзеров в базе (MySQL).

Базу бы развернул в режиме мастер-слейв репликации на обоих серверах. При этом все ваши задачи решаются. При падении основного сервера, его подменяет другой. Даже если падает только база на мастере, ее дублирует база на слейве.
Но есть еще момент. Вы ни разу не спрашивали, как реализовать перевод IP-адреса на слейв. Ведь при падении основного сервера, его IP должен быть присвоен запасному. Вы это учитываете?
Решения ес-но есть ...

2 litnimax: спасибо, я так и подозревал :)

2 cron333:
я, собственно, так и делаю. однако простой репликации БД мало и реалтайм мало чем поможет, ибо:
1) часто приходится править текстовые файлы (основные маршруты, специфические приложения и прочее). Чтобы перенести их в MYSQL нужно удобное средство правки.
2) нужно реплицировать изменения в веб интерфейсе
3) нужно реплицировать каталог TFTP
4) нужно реплицировать ASTDB, и тд и тп.
В общем, чтобы использовать реалтайм в полной мере, нужно переделывать freepbx, а на полноценную доработку нет ни времени, ни людей, ни денег. Не использовать freepbx не можем.
Как я уже писал в форуме, репликация сделана тупо бакапами freepbx, которые раз в сутки записываются на резервный сервер.

я написал скрипт, который мониторит:
- набор IP адресов в локальной сети, которые гарантировано работают (маршрутизатор, контроллеры домена, ДНС и прочее)
- IP адреса серверов, участвующих в кластере
- Разделяемый IP (скрипт ждет, пока не освободится этот ИП)
- Список контрольных пиров, которые регистрируются не на разделяемом IP, а имеют две регистрации непосредственно на основном и резервном IP. по состоянию этих пиров принимается решение о доступности сервиса.
- Список пиров, которые регистрируются на разделяемом IP. По их состоянию определяется, какой сервер в настояещее время носит разделяемый IP.
- состояние пиров межсоединений, оба сервера смотрят друг на друга и имеют зарегистрированный пир

ко всем этим параметрам мониторинга заданы пороговые критерии, при которых принимается решение о переносе разделяемого ИП. Срктура скрипта позволяет переопределять условия, все действия логируются, админ оповещается по почте о произошедшем. На обоих сервера скрипты одинаковые и реплицирутся вместе со всеми остальными данными. Сам скрипт запускается кроном раз в минуту.

В при принятии решения о переносе ИП производятся следующие операции
на основном:
ifconfig eth0:0 del 10.10.1.245 (удаляем разделяемый ИП)
ifconfig eth1 down (отключаем tdmoe интерфейс)
на резервном:
ifconfig eth0 add 10.10.1.245 (добавляем разделяемый ИП)
ifconfig eth1 up (включаем tdmoe интерфейс)

сейчас эта схема проходит тестирование у заказчика (делаю по ночам, когда никто не работает), скрипт показал себя неплохо, переход на резервный сервер осуществляется в течении минуты.
выявленные проблемы:

не всегда отрабатывает ifconfig eth1 down.
после команды ifconfig eth0 add 10.10.1.245 разделяемый ИП может не пинговаться. как бороться - пока ХЗ

Выражу свое мнение, что дело в центосе. Заметил, особенно на 4.4 абсолютная непредсказуемость поведения нетворкинга. ось неадекватно реагирует на команды. Вобщем, может курение конфигов всего этого, поправит дело.