netwind,

ориентируйтесь на официальную документацию. рестарт сервиса ненужен, достаточно "pg_ctl promote".

netwind,

Вам нужно чтобы слейв перед promote содержал теже данные что и мастер? В таком случае, сначала тормозните мастера, слейв накатит данные, разорвет соединение с выключившимся мастером, и далее делайте promote.

Если мастер упал внезапно, то тут возможны самые разные варианты и прогнозы в зависимости от конфига, нагрузки и лага)))

netwindвот тут, например, не понятно чем завершилось обсуждение.
какая все же разница между restart и promote в контексте сохранности данных ?

http://comments.gmane.org/gmane.comp.db.postgresql.general/163686

разницы никакой нет, в обоих случаях стендбай будет согласован с мастером (eventually consistent). за исключением случаев когда стендбай гасят через pg_ctl -m immediate stop или kill -9

netwinddaevyЕсли мастер упал внезапно, то тут возможны самые разные варианты и прогнозы в зависимости от конфига, нагрузки и лага)))
горячий резерв подразумевает защиту от внештатной ситуации и в частности внезапное зависание мастера.

ну так какие именно варианты ?

если мастер внезапно отказал, то
1. потеря последних закомиченных транзакции в рамках 3*wal_write_delay (при synchronous_commit = off). если вы поэксперементируете с fsync или full_pages_writes то последствия будут и того печальней. клиент уже получил ответ об успехе. а на мастер умер и на стендбай ничего не приехало.

2. асинхронная репликация. имеем длинный лаг где-нибудь около ~1Gb вызванный "сетевыми проблемами" или высокой "дисковой нагрузкой". тут мастер падает, данные предназначенные к отправке wal_sender'ом никуда не отправляются. в итоге осиротевший стендбай отстает от мастера на величину лага.

как вам? :)
не читайте "некие руководства", читайте официальную документацию. там это все описано и объяснено куда лучше чем я вам тут пишу.

netwindгорячий резерв

горячий резерв не панацея, иначе бы не было скриптов на которые ссылаются здесь )))

netwindMaxim Bogukскачаный будет проигран безусловно и без вариантов...
но это скачаный... которые не обязательно соответствует последнему на мастере (если у вас асинхронная репликация)

ну так в какой момент вернется завершится программа pg_ctl promote ? Сразу или подождет пока имеющиеся данные в WAL накатятся?

Понятно, что ответ был дал эксперимент, но не могу это смоделировать просто так, потому что нужна еще и нагрузка нормальная.

вот вам эксперимент,

netwind,

очередь используется всегда, даже когда ио не заморжено и операции исполняются в соответствии с тем как поставлены в очередь.
можете взять blktrace и убедиться воочию

netwinddaevy, ну так ведь WAL cначала скачивается и все те операции записаны во внутренней "очереди" в самом WAL.
Они не видны для устройства, потому что их туда еще не отсылали.
какой именно механизм гарантирует (или не гарантирует), что сначала весь wal прочитается и накатится, а потом уже произойдет promote ?

за это отвечает wal_receiver, у него есть буффер в который он принимает WAL с мастера и затем синкает его в сегменты в pg_xlog, там уже вызывается fsync и все отдается на откуп ядру и драйверам.

daevynetwind,

очередь используется всегда, даже когда ио не заморжено и операции исполняются в соответствии с тем как поставлены в очередь.
можете взять blktrace и убедиться воочию

тут я совершенно неправ, посыпаю голову пеплом, и извиняюсь что ввел публику в заблуждение ))

В пределах хоста операции выполняются в очереди в произвольном порядке (это как раз и повышает скорость работы, т.к. часто бывает так, что в очереди три-четыре записи в один и тот же блок — их просто объединяют в одну), однако, для целостности и транзакционности (метаданные файловых систем, базы данных и т.д.) ОС может в любой момент установить write barrier (все последующие операции могут выполняться только после того, как операции до write barrier выполнятся), либо делать flush, для сохранения всего нафиг. На более низком уровне это контролируется флагами у SAS/SATA команд, write barrier — это абстракция линукса (и его очереди). Но суть такая: в общем случае порядок не определён, но если надо, его можно ограниченно контролировать.

netwindНо ведь в реальности ничто не помешает операциям с базой, которые делает promote выполняться параллельно с wal, обогнать их и отбросить весь тот wal, который скачался ?

про параллельность и гонки...

Несколько очередей для устройства — это очень высокий хайэнд, и в любом случае эти очереди будут для разных инициаторов/хостов (речь про большие SCSI системы или SAN).