У меня есть две базы данных, которые используют потоковую репликацию и находятся в этом состоянии
postgres 16319 0.0 0.5 137949952 3077260 ? Ss Aug22 0:11 /usr/pgsql-12/bin/postmaster -D /var/lib/pgsql/12/data/
postgres 16321 0.0 0.0 249564 2080 ? Ss Aug22 0:00 \_ postgres: logger
postgres 16322 7.3 5.2 137950296 27899272 ? Ss Aug22 9031:16 \_ postgres: startup recovering 0000000100003EA70000002C
postgres 16323 0.8 5.2 137950152 27549964 ? Ss Aug22 1001:55 \_ postgres: checkpointer
postgres 16324 0.0 0.1 137949928 1050960 ? Ss Aug22 1:40 \_ postgres: background writer
postgres 16338 0.0 0.0 251960 2328 ? Ss Aug22 57:32 \_ postgres: stats collector
postgres 16339 10.6 0.0 137961464 5116 ? Ss Aug22 13123:06 \_ postgres: walreceiver streaming 3EA7/2C5A24F0
Обычно я замечал «восстановление» только тогда, когда БД находится в плохом состоянии. Когда я выполнил запрос к реплике, я получил
ERROR: canceling statement due to conflict with recovery
. Я заметил, что «потоковая передача 3EA7/2C5A24F0» и восстановление увеличивается.
SELECT * FROM pg_stat_wal_receiver
также увеличивается.
Я просто хочу убедиться, что с моей БД нет проблем, и она просто использует recovery
как часть своего механизма репликации.
Если вы настроили репликацию Postgres, отправив журнал упреждающей записи, как описано в руководстве по потоковой репликации, тогда да, все реплики находятся в состоянии постоянного восстановления, что является нормальным. Поскольку транзакции записи выполняются на главном узле, реплики получают и применяют журналы от главного узла, как это сделал бы любой сервер Postgres в процессе восстановления.
Изменяющийся номер, который вы видите, является текущим идентификатором полученной транзакции.
Пожалуйста, прочтите всю связанную страницу, чтобы уточнить детали. Что касается меня, то очевидно, что резервный (подчиненный) сервер фактически выполняет восстановление непрерывно, если не повышен.