Comments 26
С точки зрения минимизации времени простоя операция возврата мастера на Serv1 не имеет смысла.
0
Вы имеете ввиду оставлять мастер на резерве?
0
Если сервера аппаратно эквивалентны, естественно, нужно Serv2 оставлять мастером.
0
Как раз хотела написать, что железо не обязательно эквивалентно.
Например основной сервер — мощнее и быстрее, а резервный предназначен исключительно для временного перехвата потоков, но не готов к полноценной нагрузке.
Например основной сервер — мощнее и быстрее, а резервный предназначен исключительно для временного перехвата потоков, но не готов к полноценной нагрузке.
0
В таком случае лучше сразу базу с Serv2 копировать на Serv1 и сразу на нем запускать мастер. Даун тайм будет меньше.
0
А если Serv1 даунтаймит не секунду, а 3-4часа? Например проблемы в ДЦ?
Тогда получается, что пока он в оффлайне, запись ведется на Serv2 и при апе 1го у него уже нехилое отставание.
А если не мастерить Serv2, то как не потерять данные? Ведь процесс копирования бд тоже не моментен, и пока Serv2 будет копироваться на Serv1 на него еще успеет набежать.
И вот оно либо бесконечное копирование, либо потеря данных.
Если я не ошибаюсь, то без мастер-режима pg_start_backup и вовсе не заработает (чтоб остановить изменение бинарной data)
Тогда получается, что пока он в оффлайне, запись ведется на Serv2 и при апе 1го у него уже нехилое отставание.
А если не мастерить Serv2, то как не потерять данные? Ведь процесс копирования бд тоже не моментен, и пока Serv2 будет копироваться на Serv1 на него еще успеет набежать.
И вот оно либо бесконечное копирование, либо потеря данных.
Если я не ошибаюсь, то без мастер-режима pg_start_backup и вовсе не заработает (чтоб остановить изменение бинарной data)
0
«Ведь процесс копирования бд тоже не моментен»
Я про это и пишу. Конечно, если Serv1 имеет проблемы со связью или железом, хочешь или не хочешь — придется переводить мастер на Serv2. Но если аппаратно и связь на Serv1 работает или проблема устранилась быстро, лучше сразу делать копирование базы на Serv1. Именно потому, что «процесс копирования бд не моментален». А если учитывать что Serv2 может быть ниже по мощности, можно сразу получить проблемы с доступностью сервиса. Ведь нагрузка на него не будет просто так снижаться.
Просто я советую сразу понимать зачем вы создаете слэйв. Если слэйв стоит на слабом сервере и нужен только для бэкапа — переводить на него мастер просто нельзя. Т.к. он не справится с нагрузкой. А если слэйв предназначен для того, что-бы в случае необходимости перевести на него мастер, аппаратно он должен быть не слабее оригинального мастера.
Я про это и пишу. Конечно, если Serv1 имеет проблемы со связью или железом, хочешь или не хочешь — придется переводить мастер на Serv2. Но если аппаратно и связь на Serv1 работает или проблема устранилась быстро, лучше сразу делать копирование базы на Serv1. Именно потому, что «процесс копирования бд не моментален». А если учитывать что Serv2 может быть ниже по мощности, можно сразу получить проблемы с доступностью сервиса. Ведь нагрузка на него не будет просто так снижаться.
Просто я советую сразу понимать зачем вы создаете слэйв. Если слэйв стоит на слабом сервере и нужен только для бэкапа — переводить на него мастер просто нельзя. Т.к. он не справится с нагрузкой. А если слэйв предназначен для того, что-бы в случае необходимости перевести на него мастер, аппаратно он должен быть не слабее оригинального мастера.
+2
Есть ли возможность сделать slave путем pg_dump/pg_restore? Чтобы совместить приятное (иметь backup) с полезным (избавится от table bloat)
0
Для потоковой репликации необходимо, чтобы два кластера БД совпадали на бинарном уровне. Поэтому, нет, нельзя.
+1
Не думаю, в таком случае могут возникать проблемы со стыковкой WAL-логов. Не будет запускаться слейв, логи будут писать ошибку timeline, например.
rsync'аются же бинарники, которые на мастере после pg_start_backup не меняются.
rsync'аются же бинарники, которые на мастере после pg_start_backup не меняются.
0
Про repmgr знаю.
В начале написала, что предположим ничего нет кроме самого постгреса со встроенной репликацией. И sudo нет. Ничего нет, а делать что то надо :)
А насчет trigger_file… Если честно, то у меня реакция на него так и не заработала. К тому же он всего лишь открывает доступ на запись, но не переводит слейв в состояние мастера, что впоследствие необходимо.
В начале написала, что предположим ничего нет кроме самого постгреса со встроенной репликацией. И sudo нет. Ничего нет, а делать что то надо :)
А насчет trigger_file… Если честно, то у меня реакция на него так и не заработала. К тому же он всего лишь открывает доступ на запись, но не переводит слейв в состояние мастера, что впоследствие необходимо.
+2
Да — с помощью файлового тригера Serv2 можно сделать мастером быстрее. Я с этим эксперементировал.
Но, насколько я помню, что-бы он был полноценным мастером (что-бы к нему можно было подключить slave), все-равно придется менять конфиг и делать перезагрузку.
Но, насколько я помню, что-бы он был полноценным мастером (что-бы к нему можно было подключить slave), все-равно придется менять конфиг и делать перезагрузку.
0
Ещё сделать мастером можно так:
Строчки с wal_level, max_wal_senders, wal_keep_segments, archive_mode, archive_command комментировать на слэйвах не обязательно, тогда и с триггер-файлом должно работать, но сам не пробовал.
$ 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 постгрес сервер. И последующая настройка потоковой это уже отдельное дело.
триггер файл открывает хот-стендбай для записи, а собственно чем отличает мастер от хот-стендбая? именно возможностью записи)) так что тут игра слов… После создания триггер файла вы получаете 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
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
При настройке потоковой репликации, всегда стоит помнить про триггерный файл. провозглашение хот-стендбая в мастер становится делом нескольких секунд.
Архивы WAL рекомендуется бэкапить на отдельный узел, чтобы в случае аппаратных проблем на мастере, хот-стендбай мог их подтянуть для себя.
Используйте pg_basebackup, он делает тоже самое что и pg_start/stop_backup + rsync, но в одной command line.
Архивы WAL рекомендуется бэкапить на отдельный узел, чтобы в случае аппаратных проблем на мастере, хот-стендбай мог их подтянуть для себя.
Используйте pg_basebackup, он делает тоже самое что и pg_start/stop_backup + rsync, но в одной command line.
+1
Для WAL логов вообще хорошо бы скрипт, который следит еще и за связью со слевом, чтобы их случано не потерять часть.
pg_basebackup получается же тоже надо сначала делать, потом отправлять на слейв, потом там разворачивать?
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-архивы и догонит мастера). Все слейв готов))
pg_basebackup выполнит подключение к указанному серверу по протоколу репликации, сделает чекпойинт черезpg_start_backup и начнет передавать данные в ваш каталог дест_дир, по завершению сделает pg_stop_backup. Вам остается сделать chown -R postgres: dest_dir, указать recovery.conf и запуститься. Постгрес прочитает recovery.conf и запустится в соответствии с ним (прочитает нужные wal-архивы и догонит мастера). Все слейв готов))
0
Sign up to leave a comment.
Еще пара слов о потоковой репликации в postgres…