netwindГость_0netwind,
считайте что promote НЕ ждёт, а переключает сразу.
Maxim Bogukбудет проигрывать все накопленные/принятые wal файлы
что в случае отставания реплики может занять заметное время
И кому теперь верить ? Может знатоки исходного кода просто дадут ссылку на конкретное место чтобы я мог убедиться ?
а здесь нет противоречий. исходник walreceiver'а - ./src/backend/replication/walreceiver.c, немного коментариев для начала
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
* Walreceiver first connects to the primary server (it will be served by a walsender process in the primary server), and then
* keeps receiving XLOG records and writing them to the disk as long as the connection is alive. As XLOG records are received
* and flushed to disk, it updates the WalRcv->receivedUpto variable in shared memory, to inform the startup process of how far
* it can proceed with XLOG replay.
* Normal termination is by SIGTERM, which instructs the walreceiver to exit(0). Emergency termination is by SIGQUIT; like any postmaster child
* process, the walreceiver will simply abort and exit on SIGQUIT. A close of the connection and a FATAL error are treated not as a crash but as
* normal operation.
* About SIGTERM handling:
* We can't just exit(1) within SIGTERM signal handler, because the signal might arrive in the middle of some critical operation, like while we're
* holding a spinlock. We also can't just set a flag in signal handler and check it in the main loop, because we perform some blocking operations
* like libpqrcv_PQexec(), which can take a long time to finish.
* We use a combined approach: When WalRcvImmediateInterruptOK is true, it's safe for the signal handler to elog(FATAL) immediately. Otherwise it just
* sets got_SIGTERM flag, which is checked in the main loop when convenient.
* This is very much like what regular backends do with ImmediateInterruptOK, ProcessInterrupts() etc.
walreceiver работает в бесконечном цикле: забирает xlog записи, пишет их на диск, синкает, обновляет метку для recovery process, дает фидбек мастеру. Для завершения walreceiver (pg_ctl promote или shutdown) нужно послать ему SIGTERM (обработчик WalRcvShutdownHandler), получив его (даже где-то в средине работы) выставляет у себя флаг (got_SIGTERM) и определяется внутреннее состояние walreceiver в walrcv->walRcvState = WALRCV_STOPPING. Этот флаг читается в каждом начале цикла, и если он выставлен в WALRCV_STOPPING, то инициируется завершение работы (вызов функции WalRcvDie). В процесе WalRcvDie вызывается XLogWalRcvFlush(true) для гарантии того что все имеющиеся в распоряжении XLOG записи сброшены на диск. Сама XLogWalRcvFlush также содержит функцию обновления метки WalRcv->receivedUpto которая выполняется после синка и говорит recovery process о том до куда он может вести восстановление. Как только XLOG записи засинканы, а метка WalRcv->receivedUpto обновлена, будится recovery process, соединение с wal sender'ом разрывается, wal recever завершает работу. На этом этапе прием XLOG записей с мастера завершается. Далее работа передается recovery процессу, который должен прочитать сегменты из pg_xlog и эти изменения накатить на датфайлы.
таким образом
Гость_0netwind,
считайте что promote НЕ ждёт, а переключает сразу.
да. не ждет, имеющиеся в распоряжении валы (в буфферах) синкаются, новые уже не принимаются, соединение с мастером закрывается (несмотря на то что тому еще есть что отправить).
Maxim Bogukбудет проигрывать все накопленные/принятые wal файлы
что в случае отставания реплики может занять заметное время
валы записаны в pg_xlog/, но не применены к конечным датфайлам и их апплай может занимать долгое время. Вот эта стадия может растянуться, в зависимости от объема изменений в pg_xlog. Патч про который пишет Максим как раз и добавляет возможность отбросить эту стадию (тем самым есть риск стрельнуть в ногу).
