Еще пара слов о потоковой репликации в postgres…



    Асинхронная потоковая репликация — полезная штука. Для нее нынче есть много различных утилит, можно выстроить большую, мощную и верную систему.

    Но предположим, что у Вас небольшая задача, пара серверов и встроенная postgres-репликация. О ее настройке материалов достаточно, и о действиях в случае отказа мастера тоже можно найти.

    А вот с вопросом восстановления мастера оказалась беда, поэтому делюсь с Вами собранным по кусочкам с просторов интернета руководством к действию, опробованным и протестеным мною на связках серверов Debian GNU/Linux и FreeBSD 8.2 с PostgreSQL 9.1



    Для начала мы имеем:

    Serv1 — Мастер
    Serv2 — Слейв

    Падение Мастера


    Предположим, что БД на Serv1 (мастере) обвалилась, погибла и восставать сама никак не будет. При этом Serv2 стабильно работает в режиме слейва.

    Тогда на Serv2 в postgresql.conf надо раскомментировать
    wal_level = hot_standby
    max_wal_senders = 2
    wal_keep_segments = 64
    archive_mode = on
    archive_command = 'cp %p $LOG_DIR/archive/%f Serv1'


    в $HOME переименовать recovery.conf в recovery.done
    Если кто не знает о содержании файла recovery.conf
    standby_mode = 'on'
    primary_conninfo = 'host=master_host port=master_port user=master_user'
    restore_command = 'cp $LOG_DIR/archive/%f %p'
    trigger_file = '$HOME/trigger'


    Рестартнуть Serv2. Так Serv2 станет мастером.

    Восстановление прежнего Мастера


    Теперь у нас Serv2 работает в режиме мастера, Serv1 отключен.

    Надо сделать Serv1 слейвом следующим образом:

    На Serv2 выполнить:
    psql -c "SELECT pg_start_backup('label', true)"
    rsync -avzh --progress $HOME/ Serv1:$HOME/ --exclude postmaster.pid
    psql -c "SELECT pg_stop_backup()"


    В конфиге postgresql.conf на Serv1 закомментировать то, что раскомментировали на Serv2, а именно:
    #wal_level = hot_standby
    #max_wal_senders = 2
    #wal_keep_segments = 64
    #archive_mode = on
    #archive_command = 'cp %p $LOG_DIR/archive/%f Serv2'


    И раскомментировать:
    hot_standby = on


    В $HOME переименовать recovery.done в recovery.conf

    Запустить postgres на Serv1.
    Теперь Serv1 работает в режиме слейва.

    Проверить работу слейва можно выполнив на нем
    ps aux | grep receiver

    и получив результат вида
    postgres: wal receiver process  (postgres)


    Переключение обратно на Мастер


    ( см. первый пункт и делаем наоборот )

    Сейчас экс-мастер Serv1 является слейвом Serv2. Оба стабильно работают, копия слейва верна, расхождение минимально.

    Для становления мастером Serv1:

    На нем в postgresql.conf раскомментировать
    wal_level = hot_standby
    max_wal_senders = 2
    wal_keep_segments = 64
    archive_mode = on
    archive_command = 'cp %p $LOG_DIR/archive/%f'


    Остановить Serv2 (который пока что мастер) а на Serv1 в $HOME переименовать recovery.conf в recovery.done

    Теперь Serv1 вновь является работающим мастером.

    Для прицепления слейвом Serv2:

    На Serv1 выполнить:
    psql -c "SELECT pg_start_backup('label', true)"
    rsync -avzh --progress $HOME/ Serv2:$HOME/ --exclude postmaster.pid
    psql -c "SELECT pg_stop_backup()"


    На Serv2 в postgresql.conf закомментировать:
    #wal_level = hot_standby
    #max_wal_senders = 2
    #wal_keep_segments = 64
    #archive_mode = on
    #archive_command = 'cp %p $LOG_DIR/archive/%f'


    И раскомментировать:
    hot_standby = on


    Так же на Serv2 в $HOME переименовать recovery.done в recovery.conf

    Запустить postgres на Serv2. Теперь Serv2 снова работающий слейв.

    Готово. Теперь все на своих местах: Serv1 — master, Serv2 — slave.



    Заранее прошу прощения за долю копипаста и низкоуровневое разжевывание, но целостно и доступно для простых смертных эта информация в сети не нашлась, так что, надеюсь, найдет применение (:
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 26
    • 0
      С точки зрения минимизации времени простоя операция возврата мастера на Serv1 не имеет смысла.
      • 0
        Вы имеете ввиду оставлять мастер на резерве?
        • 0
          Если сервера аппаратно эквивалентны, естественно, нужно Serv2 оставлять мастером.
          • 0
            Как раз хотела написать, что железо не обязательно эквивалентно.
            Например основной сервер — мощнее и быстрее, а резервный предназначен исключительно для временного перехвата потоков, но не готов к полноценной нагрузке.
            • 0
              В таком случае лучше сразу базу с Serv2 копировать на Serv1 и сразу на нем запускать мастер. Даун тайм будет меньше.
              • 0
                А если Serv1 даунтаймит не секунду, а 3-4часа? Например проблемы в ДЦ?
                Тогда получается, что пока он в оффлайне, запись ведется на Serv2 и при апе 1го у него уже нехилое отставание.

                А если не мастерить Serv2, то как не потерять данные? Ведь процесс копирования бд тоже не моментен, и пока Serv2 будет копироваться на Serv1 на него еще успеет набежать.

                И вот оно либо бесконечное копирование, либо потеря данных.

                Если я не ошибаюсь, то без мастер-режима pg_start_backup и вовсе не заработает (чтоб остановить изменение бинарной data)
                • +2
                  «Ведь процесс копирования бд тоже не моментен»

                  Я про это и пишу. Конечно, если Serv1 имеет проблемы со связью или железом, хочешь или не хочешь — придется переводить мастер на Serv2. Но если аппаратно и связь на Serv1 работает или проблема устранилась быстро, лучше сразу делать копирование базы на Serv1. Именно потому, что «процесс копирования бд не моментален». А если учитывать что Serv2 может быть ниже по мощности, можно сразу получить проблемы с доступностью сервиса. Ведь нагрузка на него не будет просто так снижаться.

                  Просто я советую сразу понимать зачем вы создаете слэйв. Если слэйв стоит на слабом сервере и нужен только для бэкапа — переводить на него мастер просто нельзя. Т.к. он не справится с нагрузкой. А если слэйв предназначен для того, что-бы в случае необходимости перевести на него мастер, аппаратно он должен быть не слабее оригинального мастера.
      • 0
        Есть ли возможность сделать slave путем pg_dump/pg_restore? Чтобы совместить приятное (иметь backup) с полезным (избавится от table bloat)
        • +1
          Для потоковой репликации необходимо, чтобы два кластера БД совпадали на бинарном уровне. Поэтому, нет, нельзя.
          • 0
            Не думаю, в таком случае могут возникать проблемы со стыковкой WAL-логов. Не будет запускаться слейв, логи будут писать ошибку timeline, например.

            rsync'аются же бинарники, которые на мастере после pg_start_backup не меняются.
          • +1
            Жесть какая…
            > в $HOME переименовать recovery.conf в recovery.done
            Прочитайте документацию за что отвечает
            > trigger_file = '$HOME/trigger'

            Кроме того, люди же придумали barman и repmgr для минимизации вот этого механического турка.
            • +2
              Про repmgr знаю.
              В начале написала, что предположим ничего нет кроме самого постгреса со встроенной репликацией. И sudo нет. Ничего нет, а делать что то надо :)

              А насчет trigger_file… Если честно, то у меня реакция на него так и не заработала. К тому же он всего лишь открывает доступ на запись, но не переводит слейв в состояние мастера, что впоследствие необходимо.
              • 0
                Да — с помощью файлового тригера Serv2 можно сделать мастером быстрее. Я с этим эксперементировал.
                Но, насколько я помню, что-бы он был полноценным мастером (что-бы к нему можно было подключить slave), все-равно придется менять конфиг и делать перезагрузку.
                • 0
                  > с помощью файлового тригера Serv2 можно сделать мастером быстрее

                  Не сделать мастером, а просто открыть возможность записи.
                  • 0
                    Да — неточно выразился.
                • 0
                  Ещё сделать мастером можно так:
                  $ pg_ctl -D /path/to/data/dir promote

                  Строчки с wal_level, max_wal_senders, wal_keep_segments, archive_mode, archive_command комментировать на слэйвах не обязательно, тогда и с триггер-файлом должно работать, но сам не пробовал.
                  • 0
                    У меня pg_clt почему то оказался не в комплекте ))

                    А с триггер файлом см выше: он дает право на запись и только. НЕ делая мастером
                    • 0
                      pg_ctl не может быть «не в комплекте», скорей всего он не прописан в PATH (наверное у вас RHEL/CentOS), поищите, найдется.
                      триггер файл открывает хот-стендбай для записи, а собственно чем отличает мастер от хот-стендбая? именно возможностью записи)) так что тут игра слов… После создания триггер файла вы получаете standalone постгрес сервер. И последующая настройка потоковой это уже отдельное дело.
                      • 0
                        мастер от хот-стендбая отличается возможностью отдавать(иметь стендбаи)
                        • 0
                          начиная с 9.2 стендбай тоже умеет отдавать.
                          With 9.2, a standby can also send replication changes, allowing cascading replication.
                          wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.2#Replication_improvements
                          • 0
                            речь про 9.1
                            в 9.2 там доработали кой чего, да
                • +1
                  При настройке потоковой репликации, всегда стоит помнить про триггерный файл. провозглашение хот-стендбая в мастер становится делом нескольких секунд.
                  Архивы WAL рекомендуется бэкапить на отдельный узел, чтобы в случае аппаратных проблем на мастере, хот-стендбай мог их подтянуть для себя.
                  Используйте pg_basebackup, он делает тоже самое что и pg_start/stop_backup + rsync, но в одной command line.
                  • 0
                    Для WAL логов вообще хорошо бы скрипт, который следит еще и за связью со слевом, чтобы их случано не потерять часть.

                    pg_basebackup получается же тоже надо сначала делать, потом отправлять на слейв, потом там разворачивать?
                    • 0
                      c pg_basebackup получается так. Вы заходите на свой сервер который хотите сделать слейвом, создаете там каталог «dest_dir» в котором будет жить реплика и выполняете там pg_basebackup -P -v -h master_ip -U postgres -D dest_dir (не забываем про pg_hba.conf на мастере)
                      pg_basebackup выполнит подключение к указанному серверу по протоколу репликации, сделает чекпойинт черезpg_start_backup и начнет передавать данные в ваш каталог дест_дир, по завершению сделает pg_stop_backup. Вам остается сделать chown -R postgres: dest_dir, указать recovery.conf и запуститься. Постгрес прочитает recovery.conf и запустится в соответствии с ним (прочитает нужные wal-архивы и догонит мастера). Все слейв готов))
                      • 0
                        ну то есть без принудительного разворота, да. Надо будет попробовать вкорячить.
                        • 0
                          Вспомнила еще момент :)

                          pg_basebackup требует пустую датадир и железобетонно копирует все. А rsync таки мержит. При больших объемах rsync определенно экономит время

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