slon - Интернет в облаке

ПРОГРАММА:

ИМЯ

slon - демон Slony-I

СИНТАКСИС

Slon [вариант] ... [название кластера] [Conninfo]

ОПИСАНИЕ

slon - это приложение-демон, которое «запускает» репликацию Slony-I. Экземпляр slon должен быть
запускать для каждого узла в кластере Slony-I.

ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

-d log_level
В log_level определяет, какие уровни отладочных сообщений должны отображаться в Slon, когда
ведение журнала своей активности.

Девять уровней ведения журнала:

· Смертельный

· Ошибка

· Предупреждать

· Конфигурация

· Информация

· Отладка1

· Отладка2

· Отладка3

· Отладка4

Первые пять уровней журнала без отладки (от Fatal до Info): всегда отображается в
журналы. В ранних версиях Slony-I «предложенный» log_level значение было 2, что
вывод списка на всех уровнях вплоть до уровня отладки 2. В Slony-I версии 2 это
рекомендуется установить log_level до 0; большая часть постоянно интересной информации журнала
генерируется на более высоких уровнях.

-s SYNC проверка интервал
В sync_interval, измеряется в миллисекундах, указывает, как часто Slon должен проверять
чтобы увидеть, есть ли SYNC должен быть представлен. По умолчанию 2000 мс. Основной цикл в
sync_Thread_main () спит с интервалами sync_interval миллисекунды между
итераций.

Короткие интервалы проверки синхронизации удерживают источник на «коротком поводке», обновляя его
подписчиков чаще. Если у вас есть повторяющиеся последовательности, которые часто
обновление без есть таблицы, которые затронуты, это предотвращает их
раз, когда обновляются только последовательности, и, следовательно, нет происходит синхронизация

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

-t SYNC интервал Тайм-аут
В конце каждого sync_interval_timeout период тайм-аута, a SYNC будет создан
на "локальном" узле, даже если не было обновлено реплицируемых данных, которые могли бы
вызвали SYNC будут созданы.

Если активность приложения прекращается из-за того, что приложение закрыто, или
поскольку пользователи ушли домой и перестали выпускать обновления, Slon(1)
будет повторяться, просыпаясь каждый sync_interval миллисекунды, а, поскольку обновлений нет
делаются, нет SYNC события будут сгенерированы. Без этого параметра тайм-аута
нет SYNC будут генерироваться события, и казалось бы, что репликация падала
позади.

В sync_interval_timeout значение приведет к созданию SYNC, Даже
хотя реальной работы по репликации не было. Чем ниже этот параметр
установлен, тем чаще Slon(1) сгенерирует SYNC события, когда приложение
не генерирует воспроизводимую активность; это будет иметь два эффекта:

· Система будет выполнять больше работы по репликации.

(Конечно, поскольку в базе данных нет нагрузки приложения и нет данных для
повторять, с этой нагрузкой будет очень легко справиться.

· Репликация будет более «актуальной».

(Конечно, поскольку здесь нет воспроизводимой активности,
свидание - это что-то вроде миража.)

По умолчанию 10000 мс, максимум 120000 мс. По умолчанию вы можете ожидать, что каждый узел будет
"сообщить в" с SYNC каждые 10 секунд.

Обратите внимание, что SYNC события также генерируются на абонентских узлах. Поскольку на самом деле они не
генерируя любые данные для репликации на другие узлы, эти SYNC события не страшны
большая ценность.

-g группы размер
Это контролирует максимум SYNC размер группы, sync_group_maxsize; по умолчанию 6. Таким образом,
если конкретный узел отстает на 200 SYNCs, он попытается сгруппировать их вместе
на группы размером не более sync_group_maxsize. Можно ожидать, что это уменьшит
накладные расходы на транзакции из-за меньшего количества транзакций для COMMIT.

Значение по умолчанию 6, вероятно, подходит для небольших систем, которые могут выделять только очень
ограниченные биты памяти для слона. Если у вас много памяти, это будет
разумно увеличить это, так как это увеличит объем работы, выполняемой в каждом
транзакции, и позволит подписчику, который сильно отстает, наверстать больше
быстро.

Процессы Slon обычно остаются небольшими; даже при большом значении этого параметра,
Ожидается, что размер slon вырастет только до нескольких МБ.

Большое преимущество в увеличении этого параметра связано с сокращением
номер транзакции COMMITs; переход от 1 к 2 обеспечит значительный
выгода, но выгода будет постепенно уменьшаться, как только транзакции будут
обработанные становятся достаточно большими. Вряд ли будет материал
разница в производительности между 80 и 90; в этот момент, будет ли «больше»
лучше »будет зависеть от того, будет ли больший набор SYNCs делает ВХОД курсор вести себя
плохо из-за того, что потребляется больше памяти и требуется больше времени для сортировки.

В Slony-I версии 1.0 slon всегда будет пытаться сгруппировать SYNCвместе с этим
максимум, который не будет быть идеальным, если репликация была несколько дестабилизирована
там очень большие обновления (или - одна транзакция, которая обновляет сотни
тысяч строк) или SYNCs прерывается на исходном узле с результатом
что есть несколько SYNCs, которые очень большие. Вы можете столкнуться с проблемой, что
группируя вместе очень большие SYNCs опрокидывает процесс slon. Когда он выбирает
снова, он попытается обработать тот же большой сгруппированный набор SYNCs, и наткнуться на
одна и та же проблема снова и снова, пока администратор не прервет ее и не изменит
-g значение для выхода из этого «тупика».

В Slony-I версии 1.1 и более поздних версиях slon адаптивно `` наращивает ''
от выполнения 1 SYNC одновременно с максимальным размером группы. В результате, если есть
пара SYNCвызывающие проблемы, slon будет (с любыми соответствующими
сторожевого пса) всегда иметь возможность добраться до точки, где он обрабатывает
хлопотный SYNCодин за другим, надеясь, что помощь оператора станет ненужной.

-o желанный синхронизировать время
«Максимальное» время, запланированное для сгруппированных SYNCs.

Если репликация отстает, slon будет постепенно увеличивать количество SYNCs
сгруппированы вместе, ориентируясь на это (в зависимости от времени, затраченного на последний группа
SYNCу) они не должны брать больше указанного желаемое_синхронное_время значения.

Значение по умолчанию для желаемое_синхронное_время составляет 60000 мсек, что соответствует одной минуте.

Таким образом, вы можете ожидать (или, по крайней мере, надеяться!), Что получите COMMIT примерно однажды
в минуту.

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

Общий эффект заключается в улучшении способности Slony-I справляться с вариациями
движение. Начиная с 1 SYNC, и постепенно переходя к большему, даже если есть поворот
быть достаточно большими, чтобы вызвать сбой серверной части PostgreSQL, Slony-I
будет отступать, чтобы начать с одной синхронизации за раз, если это необходимо, так что, если это
если репликация будет развиваться, так и будет.

-c уборка циклы
Значение vac_частота указывает, как часто ВАКУУМНАЯ в циклах очистки.

Установите в ноль, чтобы отключить запускаемую slon уборку. Если вы что-то используете
как pg_autovacuum для запуска вакуума, вам может не понадобиться slon для запуска
пылесосит себя. Если это не так, Slony-I использует таблицы, которые собирают
много мертвых кортежей, которые следует часто пылесосить, особенно pg_listener.

В Slony-I версии 1.1 это немного изменилось; дорожки потока очистки, от
от итерации к итерации, самый ранний идентификатор транзакции, все еще активный в системе. Если
это не меняется от одной итерации к другой, тогда старая транзакция
все еще активен, и поэтому ВАКУУМНАЯ не принесет никакой пользы. Вместо этого поток очистки
просто делает АНАЛИЗ на этих таблицах, чтобы обновить статистику в pg_statistics.

-p PID имя файла
pid_file содержит имя файла, в котором хранится PID (идентификатор процесса) slon.

Это может упростить создание скриптов для мониторинга нескольких процессов slon.
работает на одном хосте.

-f конфиг файл
Файл, из которого можно прочитать конфигурацию slon.

Эта конфигурация обсуждается далее в разделе "Конфигурация времени выполнения Slon" [«Время выполнения
Конфигурация »[недоступно в виде справочной страницы]]. Если будет сложный набор
параметры конфигурации, или если есть параметры, которые вы не хотите быть видимыми
в переменных среды процесса (таких как пароли) может быть удобно
извлечь многие или все параметры из файла конфигурации. Вы можете либо поставить общий
параметры для всех процессов slon в обычно используемом файле конфигурации, что позволяет
командную строку, чтобы указать немного, кроме информации о соединении. В качестве альтернативы,
вы можете создать файл конфигурации для каждого узла.

-a архив каталог
архив_каталог указывает каталог, в который следует поместить последовательность SYNC архив
файлы для использования в доставке журналов [«Доставка журналов - Slony-I с файлами» [недоступно
как страницу руководства]].

-x команду в пробег on журнал архив
команда_on_logarchive указывает команду, которая будет запускаться каждый раз, когда файл SYNC
успешно создан.

См. Дополнительные сведения о «slon_conf_command_on_log_archive» [недоступно для мужчин
страница].

-q выход основанный on SYNC Недвижимости
quit_sync_provider указывает, какой рабочий поток провайдера следует наблюдать в
чтобы прекратить действие после определенного события. Это должно использоваться вместе с
-r вариант ниже ...

Это позволяет вам остановить репликацию slon после определенного момента.

-r выход at мероприятие номер
quit_sync_finalsync указывает номер события, после которого удаленный рабочий поток
для указанного выше провайдера должно прекратиться. Это должно использоваться вместе с
-q вариант выше ...

-l отставать интервал
lag_interval указывает значение интервала, такое как 3 минут or 4 часов or 2 дня
это указывает на то, что этот узел должен отставать от своих поставщиков на указанный интервал
время. Это приводит к тому, что события игнорируются до тех пор, пока они не достигнут возраста, соответствующего
интервал.
Предупреждение

У этого отставания есть обратная сторона; события, требующие, чтобы все узлы
синхронизировать, как это обычно бывает с СЛОНИК ОТКАЗ(7) и СЛОНИК ЕХАТЬ УСТАНОВКА(7)
Придется дождаться этого отстающего узла.

Это может быть не идеальным поведением во время отработки отказа или в то время, когда вы хотите
пробег СЛОНИК ВЫПОЛНИТЬ SCRIPT(7).

ВЫХОД статус

slon возвращает 0 оболочке, если она завершилась нормально. Он возвращается через выход (-1) (который будет
вероятно предоставит возвращаемое значение 127 или 255, в зависимости от вашей системы), если он
обнаруживает фатальную ошибку.

Используйте slon онлайн с помощью сервисов onworks.net