В настоящее время мы запускаем master -> slave, slave, slave, slave, настроенный с использованием postgresql 9.2.8 с потоковой передачей и WAL-E / S3 для обработки сегментов wal.
Должны ли все реплики в настоящее время быть «в восстановлении»? Запуск SELECT pg_is_in_recovery (); на всех из них возвращается истина, что вызывает беспокойство. Мы можем выполнять по ним запросы (при условии, что они не занимают больше 30 секунд).
Я пытаюсь развернуть еще одну реплику одного из существующих ведомых устройств с помощью WAL-E, но в настоящее время я не могу этого сделать, поскольку каждая реплика находится в режиме восстановления. Я не могу запустить pg_basebackup или использовать функции резервного копирования wal-e на репликах.
Эми, мне не хватает чего-то очевидного? Единственное, о чем я могу думать, это примерно 2 месяца назад у нас была проблема, когда наш жесткий диск заполнился на нашем главном устройстве, и он отключился. Мы смогли загрузить его, очистить дисковое пространство и продолжить потоковую передачу / репликацию с мастера.
Если бы я просто запустил 3 сервера postgresql и настроил их в цепочке из 3 серверов (главный -> подчиненный -> подчиненный) с использованием потоковой передачи / архивирования, он работал бы правильно с WAL-E, как я это сделал. Просто по какой-то причине я не могу передать наши существующие производственные реплики для потоковой передачи / архивации на любой другой сервер. В частности, archive_command НИКОГДА не запускается ни на одной из реплик (потому что она застряла в режиме восстановления).
Есть ли у кого-нибудь предложения о том, как я могу дальше отлаживать / диагностировать это? Я пытаюсь найти решение без значительного простоя нашей производственной базы данных (так как я всегда мог просто повторно импортировать БД на новый сервер и снова запустить цепочку, но это займет более 12 часов).
Вот детали конфигурации: https://gist.github.com/Geesu/1a696262e46ba9f0a24c А также local_backup_script.sh: https://gist.github.com/Geesu/3b8b35e108d8e2205da7
Спасибо!
Надеюсь, это все же можно считать ответом на ваш вопрос, хотя я не решил вашу проблему.
Должны ли все реплики в настоящее время быть «в восстановлении»? Запуск SELECT pg_is_in_recovery (); на всех> них возвращает истину, что вызывает беспокойство. Мы можем выполнять по ним запросы
Это нормально. Твой раб является в своего рода восстановлении, хотя и медленном и постоянном, пока он все еще перехватывает сегменты WAL (или потоковую передачу) с другого сервера.
Просто по какой-то причине я не могу передать наши существующие производственные реплики для потоковой передачи / архивации на любой другой сервер. В частности, archive_command НИКОГДА не запускается ни на одной из реплик (потому что она застряла в режиме восстановления).
Вы где-нибудь получаете ошибки? Помните, что потоковая передача инициируется подчиненными ведомыми устройствами: в каком состоянии они находятся? Какие данные у них есть? И записывается ли что-нибудь интересное при попытке потокового подключения? Помните, что встроенная в PostgreSQL потоковая репликация не зависит от системы архивирования (при условии, что в остальном машина, расположенная ниже по потоку, обновлена); вы можете установить соединение от имени пользователя репликации?
Есть ли у кого-нибудь предложения о том, как я могу дальше отлаживать / диагностировать это?
Учитывая несоответствие между производственной версией и вашей пробной версией, это действительно похоже на неправильную конфигурацию, спрятанную где-то, хотя я ничего не знаю о WAL-E. Разница в postgresql.conf, pg_hba.conf (и recovery.conf Я полагаю) было бы скучным, но хорошим началом. То есть между вашими производственными рабами и рабочими, испытательными рабами.
Вы также можете проверить содержимое pg_settings стол. Если это производственные машины с длительным сроком эксплуатации, возможно, настройка еще не применена? И я знаю, что вы смотрели документы на каскадная репликация и его требования, но я привязываю их на всякий случай.