В настоящее время у меня есть 1 главный сервер (a) и 3 сервера репликации (b, c, d), которые поступают непосредственно от мастера, я использую команду archive_command - это следующий сценарий: https://gist.github.com/Geesu/8640616
Все серверы - Ubuntu 12.04.4 с PostgreSQL 9.2.6.
И вот файл recovery.conf для каждого из серверов репликации: https://gist.github.com/Geesu/8640635
Что странно, примерно через 6 часов после того, как я запустил серверы репликации, 2 из них сразу же отстали и теперь застревают, пытаясь наверстать упущенное, но они продолжают отставать. Вот насколько они отстают от мастера:
a 20287.825072
b 2.521136
c 19994.51653
Есть ли у кого-нибудь идеи, почему один из серверов почти полностью загружен, а другие продолжают отставать? Я убедился, что a и c обрабатывают сегменты WAL, просто он не может сделать это достаточно быстро.
Некоторые примеры журналов из a и c:
cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E0000009A': No such file or directory
2014-01-26 23:02:14 GMT LOG: record with zero length at 109E/9AE622D8
cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E0000009A': No such file or directory
2014-01-26 23:02:14 GMT LOG: streaming replication successfully connected to primary
2014-01-26 23:03:36 GMT FATAL: could not receive data from WAL stream: SSL error: sslv3 alert unexpected message
cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E000000B9': No such file or directory
2014-01-26 23:03:41 GMT LOG: record with zero length at 109E/B9E797E0
cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E000000B9': No such file or directory
2014-01-26 23:03:41 GMT LOG: streaming replication successfully connected to primary
Может это связано? В конце концов он получит соответствующий сегмент WAL и будет обработан.
Любые предложения о том, как я могу это отладить?
Здесь есть несколько ошибок.
Во-первых, ваш главный сервер отправляет - или пытается - отправить архивы WAL в каждую реплику и рассматривать команду archive_command как успешную только в том случае, если все три получат файл. Это означает, что если один выйдет из строя, два других перестанут получать новый WAL, потому что Pg на главном сервере будет зависать, повторяя один и тот же сегмент снова и снова.
Ваш скрипт не может вернуть $FAIL, поэтому на практике это не работает - он сообщает об успехе, даже если все три сервера не смогли получить файлы WAL. Он будет продолжать работать с файлом WAL, игнорируя тот факт, что предыдущий сбой означает, что вся последовательность бесполезна и не может быть воспроизведена. Это вполне может объяснить, почему реплики не могут найти локальные сегменты WAL; они, вероятно, не смогли скопировать из-за проблем с env-var (RSYNC_RSH), проблемы с известными хостами, проблемы с ключами ssh и т. д.
Я настоятельно рекомендую вам перейти на двухтактную модель. Иметь главный сервер От себя WAL в надежное место хранения. Тогда есть реплики вытащить из этого места. Мастер должен скопировать файл только один раз, и ему не нужно беспокоиться о повторных попытках в разных точках для разных серверов, если некоторые из них не работают, другие догоняют и т. Д. Все более популярным выбором для этого является Amazon S3, хотя Windows Azure Также полезны Block Service (WABS) и OpenStack's Swift. Полезный инструмент для этого - WAL-E, который может служить вашим archive_command и restore_command; он поддерживает все перечисленные магазины.
Удобно, если вы используете S3, у вас может быть политика архивирования, которая прячет старые вещи в Glacier вместо их удаления, а затем удаляет их намного позже. Это дешевый и удобный способ хранить подобные вещи «на всякий случай» - но помните, что он бесполезен, если вы не сохраните также и соответствующую базовую резервную копию!
если ты должен иметь главный толчок ко всем трем бэкэндам, вам нужно быть намного умнее с этим, со сценарием, который отдельно отслеживает, какие серверы получили каждый сегмент WAL, и сообщает об успехе, когда один сервер получил сегмент и все предыдущие сегменты. Вам понадобится фоновое задание, которое будет повторять попытки для отставших серверов. Даже тогда это плохая идея; это сделает ваше архивирование WAL таким же медленным, как и самый медленный сервер, что на самом деле не идеально и может привести к очень сильному заполнению главного сервера. Я уверен, что это можно заставить работать, но ИМО это слишком хрупко и сложно.
В ваших журналах:
2014-01-26 23:03:36 GMT FATAL: не удалось получить данные из потока WAL: ошибка SSL: непредвиденное сообщение предупреждения sslv3
Ваши серверы настроены для потоковой репликации, но у них есть проблемы с SSL. Это ошибка сигнатуры проблемы повторного согласования sslv3 и раннее безмозглое «исправление» OpenSSL для нее. Убедитесь, что вы обновились до последней версии патча OpenSSL, так как это должно решить проблему.
Если это не так, в качестве обходного пути вы можете попробовать ssl_renegotiation_limit=0 в postgresql.conf. Видеть эта ошибка панели запуска.