Pull to refresh

Comments 26

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

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

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

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

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

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

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

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

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

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

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

А с триггер файлом см выше: он дает право на запись и только. НЕ делая мастером
pg_ctl не может быть «не в комплекте», скорей всего он не прописан в PATH (наверное у вас RHEL/CentOS), поищите, найдется.
триггер файл открывает хот-стендбай для записи, а собственно чем отличает мастер от хот-стендбая? именно возможностью записи)) так что тут игра слов… После создания триггер файла вы получаете standalone постгрес сервер. И последующая настройка потоковой это уже отдельное дело.
мастер от хот-стендбая отличается возможностью отдавать(иметь стендбаи)
речь про 9.1
в 9.2 там доработали кой чего, да
При настройке потоковой репликации, всегда стоит помнить про триггерный файл. провозглашение хот-стендбая в мастер становится делом нескольких секунд.
Архивы WAL рекомендуется бэкапить на отдельный узел, чтобы в случае аппаратных проблем на мастере, хот-стендбай мог их подтянуть для себя.
Используйте pg_basebackup, он делает тоже самое что и pg_start/stop_backup + rsync, но в одной command line.
Для WAL логов вообще хорошо бы скрипт, который следит еще и за связью со слевом, чтобы их случано не потерять часть.

pg_basebackup получается же тоже надо сначала делать, потом отправлять на слейв, потом там разворачивать?
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-архивы и догонит мастера). Все слейв готов))
ну то есть без принудительного разворота, да. Надо будет попробовать вкорячить.
Вспомнила еще момент :)

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

Articles