Репликация и балансировка в Postgresql 9.5

Автор:human

Репликация и балансировка в Postgresql 9.5

Настройка репликации Postgresql 9.5 на debian 8

С репликацией у postgresql пока не все просто, но она работает. Рассмотрим всё на примере.

1.Конфигурация

ОС debian 8 jessie
node1 — 10.4.1.161 — postgresql master
node2- 10.4.1.162 — postgresql standby1
node3- 10.4.1.163 — postgresql standby2
10.4.1.180 — ваш пк для проверки баз на репликацию, например через pgadmin3.

2.Добавляем репы postgresq 9.5

Добавляем репы Postgres(на 2 ноды)

3. Настройка нод

Создадим папку для пользователя postgres до установки его (на обе ноды)

Ставим Postgresql 9.5

Создадим ключ для авторизации пользователей postgres(на 2 нодах)

ВНИМАНИЕ!!! СОЗДАЕМ КЛЮЧИ на обоих БЕЗ ПАРОЛЬНОЙ ФРАЗЫ!!!

Переход на NODE1

Переход на NODE2

Переход NODE1

Таким же образом добавим 3 ноду — суть такая — все ноды должны подключаться друг к другу через пользователя postgres,
!!!!!!!!!а также необходимо добавить ключ для подключения postgresql к root!!!!!
Редактим конфиг:

В любой точке файла (только не в конце) поместите следующие строки, которые откроют новому пользователю доступ к этому серверу:

Save (ctrl+o)
Отредактируем конфиг postgres

Найдите в нём следующие параметры, раскомментируйте их и измените их значения таким образом:

Save(ctrl+o)
Далее открываем psql:

Меняем пароль пользователя postgres:

Перезапускаем PostgreSQL:

Мастер настроен!

Переход на NODE2

Останавливаем PostgreSQL:

Становимся пользователем postgres(вы должны были заранее,как говорилось выше создать пароль для postgre:

Сливаем данные с node1(мастера):
Под этим пользователем переливаем данные с мастера:

Попросят пароль от пользователя постгрес на 1 сервере(node1). Введем его.

Создадим конфиг рекавери на:

Вставим строки в пустой файл:

Также в recovery.conf можно дописать:

… если вы хотите реплику, отстающую от мастера на заданное количество времени.
Это позволит быстро восстановить данные в случае выполненного случайно drop database.

Правим конфиг подлкючений на 2-й ноде

Настраиваем конфиг

Приводи к такому виду как на первом, только меняем listen_addresses

Запускаем PostgreSQL:

Проверяем висит ли Postgresql на порте

4.Проверка репликации

На мастере говорим:

На реплике(node2)

5.Переключаем реплику в режим мастера

Остановим мастер. Допустим, что-то случилось.

В логе увидим:

При этом в каталоге /var/lib/postgresql/9.5/main файл recovery.conf автоматически будет переименован в recovery.done.
Легко проверить, что в бывшую реплику теперь можно писать. Конечно, если только вы не использовали синхронную репликацию с одной-единственной репликой.
Интересно, что хотя реплику и можно промоутнуть до мастера без перезапуска PostgreSQL, на практике вы, вероятно, все же захотите его перезапустить по следующей причине. Дело в том, что приложение, которое ранее подключилось к этой реплике, так и будет использовать ее в качестве реплики даже после промоута, хотя операции чтения можно было бы размазать по остальным репликам в кластере. Перезапустив PostgreSQL, вы порвете все сетевые соединения, а значит приложению придется подключиться заново, проверить, подключился ли он к мастеру или реплике (запрос SELECT pg_is_in_recovery(); вернет false на мастере и true на репликах), и использовать сетевое соединение соответствующим образом.

6.Переключение на новый мастер оставшихся реплик и восстановление упавшего мастера до реплики.

Переключение остальных реплик на новый мастер, а также восстановление бывшего мастера в качестве реплики происходит одинаково.
Чтобы было чуть меньше путаницы с новым мастером, старым мастером, старой репликой и новой репликой, условимся, что сервера мы называем в соответствии с их текущими ролями. То есть, мастером мы называем новый мастер, бывший репликой до фейловера, а репликой — тот, второй сервер.
В простом и не совсем правильном варианте нужно отредактировать, или создать, если его еще нет, файл /var/lib/postgresql/9.5/main/recovery.conf, указав в нем правильный IP мастера, и сделать sudo service postgresql restart (простой reload не прокатит). Кто-то для того, чтобы не править конфиги и не останавливать СУБД, использует схему с балансировщиком и DNS, но я лично так никогда не делал. В любом случае, этот способ неправильный. Для того, чтобы все хорошо работало во всяких хитрых граничных случаях, реплику следует остановить, сделать pg_rewind, затем запустить реплику.
Утилита pg_rewind находит точку в WAL, начиная с которой WAL мастера и WAL реплики начинают расходиться. Затем она «перематывает» (отсюда и название) WAL реплики на эту точку и накатывает недостающую историю с мастера. Таким образом, реплика и мастер всегда приходят к консистентному состоянию. Плюс к этому pg_rewind синхронизирует файлы мастера и реплики намного быстрее, чем pg_basebackup или rsync.
Если вы считаете, что pg_rewind не требуется при использовании синхронной репликации, вот пример маловероятной, но теоретически возможной ситуации. У вас много серверов с PostgreSQL. Сервера в кластере умирают сравнительно часто, поэтому вы решили автоматизировать фейловер. Умирает мастер, запускается фейловер. Среди реплик находится та, что имеет наиболее длинный WAL, на ней делается pg_ctl promote. В этот момент с очень большой задержкой (скажем, 5 секунд — были какие-то сетевые проблемы) на другую реплику прилетает пакет от уже мертвого мастера, и WAL этой реплики становится длиннее WAL нового мастера. Вы не сможете подключить эту реплику к новому мастеру, все сломалось. Если вы хотите, чтобы фейловер работал в том числе и при таких странных граничных случаях, используйте pg_rewind.
Итак, на реплике говорим:

Типичный вывод:

Перемещаем и правим recovery.conf:

Проверяем IP мастера и наличие строчки:

Запускаем реплику, смотрим в логи. Там обязательно должно быть:

Значит PostgreSQL работает в качестве реплики.
Если вдруг видим что-то вроде:

… значит реплика слишком отстала от мастера, и нужно перенести файлы с мастера при помощи pg_basebackup, как было описано в начале этой статьи.

7.Добавление дополнительного слейва postgresql

Допустим вам понадобилось добавить еще один slave, пусть это будет pg3.domain.local c ip адресом 10.4.1.163. Это всё делается очень просто.

  1. Устанавливаем postgresql там же образом как и 1-ый слейв, также редактируем postgres.conf

Правим конфиг подлкючений на 3-й ноде

Сливаем данные с node1(мастера):
Под этим пользователем переливаем данные с мастера:

Попросят пароль от пользователя постгрес на 1 сервере(node1). Введем его.

Создадим конфиг рекавери на:

Вставим строки в пустой файл:

Не забываем добавить на ТЕКУЩЕМ МАСТЕР сервере новую реплику в разрешенные подключения(ДОБАВИМ СТРОКИ НА МАСТЕР СЕРВЕРЕ, А ЗАОДНО И НАДРУГИХ РЕКПЛИКАХ, НА СЛУЧАЙ ПЕРЕХОДА ИХ В РЕЖИМ МАСТЕРА):

8.Настройка балансировки через PGPOOL2

Если у вас несколько нод, то вы захотите настроить балансировку на них, чтобы подключение шло через одну точку.
Для этого мы будем использовать pgpool2.
Установка. Будем ставить из исходника, но для начала установим и удалим пакет — усвоил это урок из установки Nginx из исходников

Качаем исходники

cd /tmp
wget https://www.pgpool.net/download.php?f=pgpool-II-3.5.4.tar.gz
tar -xvf download.php?f=pgpool-II-3.5.4.tar.gz
cd download.php?f=pgpool-II-3.5.4

Ставим пакеты для сборки

apt-get install libpq-dev make checkinstall -y

Конфигурируем и устанавливаем


Устанавливаем в систему


Переходим в каталог с файлами
cd /usr/local/etc

Настройка. Отредактируем файл pgpool.conf

Удалим все и вставим след конфиг

Заметьте порт у нас 5432, а сам постгрес крутится на 5433, т.е. pgpool2 можно ставить на нады с postgresql.
Отредактим файл подключений pool_hba.conf

Отредактим файл c паролями для подключениями к pgpool2

Туда надо вставить пользователя и его md5 пароль

ВАЖНО!!! Пароль получаем из postgresql

И получим пароль. Вставим его в файл. Применяем права на каталог pgpool и рестартимся.

8.Заключение

Всё мы получили репликацию и балансировку.

Об авторе

human administrator

    2 комментария

    татьянаДата:12:36 пп - Янв 17, 2017

    Очень хорошая статья, спасибо большое. есть несколько вопросов: правильно ли я поняла, что pg pool используется только для балансировки нагрузки? и здесь не рассматривается пример автоматической смены слейва на мастер, в случае падения мастера и обратного восстановления ? Нет ли такой же стать на эту тему?

    humanДата:2:08 пп - Янв 20, 2017

    Татьяна, статья здесь — ответит на ваши вопросы. Я ее автор на хабре https://itc-life.ru/postgresql-cluster-9-6/

    Оставить ответ

    Войти с помощью: 

     

    Яндекс.Метрика