журнал транзакций, однако чаще всего просто используется аббревиатура WAL. Запись в журналтребуется для обеспечения надежности и сохранения порядка всех изменений над данными и возможности восстановления после аварийного завершения СУБД. В таком случае при последующем запуске СУБД, используя журнал, воспроизведет последовательность измененийнадтемиданными,которыенебылисброшеныизбуферногокешавосновноехранилище. ПроизводительностьСУБДзависитвтомчислеиотскоростиработысWAL-журналом,которую можно узнать с помощью статистики.

Журнал сообщений СУБД

Послетогокаккомандазавершилась,клиентупередаетсярезультатвыполнения,будьтонабор строк, тег или вообще ошибка. Здесь может выполняться протоколирование, то есть сохранение служебной информации о выполнении команды.Эта информация может включать в себя данные о клиенте,текст и параметры запроса и т. п.Протоколирование дополняет статистику и также является важным источником информации о работе СУБД.Далее сервер готов к получению и выполнению следующей команды.

Репликация изменений

Помимоосновнойработысклиентами,СУБДвыполняетрядслужебныхзадач.Дляэтогосуществуютотдельныепроцессы,которыеработаютв фоновом режиме.Одной изтаких задач является физическая репликация, которая построена на основе журнала упреждающей записи. Все изменения данных,которые попадают в журнал,читаются процессом walsender и по протоколу репликации передаются на реплики.На репликах процессы walreceiver принимаютданные журнала и сохраняют содержимое на диск. Другой фоновый процесс — startup — читает полученныеданныежурналаивоспроизводитпоследовательностьизмененийналокальнойкопии данных. После этого изменения, пришедшие с основного сервера, становятся видимыми для запросов,выполняющихся на реплике.

Кромефизическойрепликации,PostgreSQLподдерживаетилогическую.Физическаярепликация предполагаетпередачу и применение всех изменений,вто время каклогическая позволяет выборочно передавать данные на уровне отдельных таблиц и даже операций. Использованиерепликацииможетпреследоватьразныецели,напримерраспределениерабочейнагрузки или отказоустойчивость и быстрое переключение при сбоях. Поэтому важно отслеживать состояние всех узлов,и в этом снова нам помогает статистика.

Архивирование журнала предзаписи

Похожей на репликацию является задача архивирования WAL-журнала. С точки зрения операционной системы WAL-журнал — это всего лишь последовательность файлов, называемых WAL-сегментами. Как только запись в очередной WAL-сегмент завершена, специальный процесс archiver может поместить этот сегмент в архив. Под архивом подразумевается отдельное

22Глава 1. Обзор статистики

от СУБД хранилище, которое используется для задач резервного копирования и аварийного восстановления.

Фоновая синхронизация данных

Есть и другие фоновые задачи. Одна из них — это синхронизация измененных данных из буферного кеша с основным хранилищем. Для этого задействованы два процесса: background writer и checkpointer. Первый в непрерывном цикле ищет грязные страницы и записывает их на диск. Второй, checkpointer, выполняет контрольные точки. Контрольная точка — это отметка в WAL-журнале,которая указывает на то,что все изменения до этой отметки уже записаны внадежноехранилище.Привыполненииконтрольнойточкипроцессcheckpointerзаписывает все грязные данные в отличие от background writer, который делает это выборочно. Другими словами,checkpointer,такжекакиbackgroundwriter,синхронизируетизмененияизбуферного кеша с диском,но дополнительно ставит особую отметку в WAL-журнале о том,что синхронизированы все грязные данные.

Поскольку журнал предзаписи — это история всех изменений, возникает вопрос: как долго следует хранить эту историю? Ответ дает процесс checkpointer: установка контрольной точки означает, что все предыдущие изменения надежно записаны в основное хранилище и все сегменты журнала, предшествующие этой контрольной точке, могут быть удалены. Таким образом,объем журнала предзаписи сохраняется более или менее постоянным и WAL-сегменты не накапливаются.

Автоочистка

Еще одной регулярной фоновой задачей является очистка таблиц и индексов от устаревших версий строк,так называемая автоочистка (autovacuum).Необходимость автоочистки является следствием реализации операций обновления данных и конкурентного доступа к ним.При изменении данных и конкурентной работе нескольких клиентов в таблицах могут возникать несколько версий одних и тех же строк. Со временем самые старые версии строки становятся неактуальными и могут быть удалены. Их удалением и занимается процесс автоочистки. Фоновыйпроцессautovacuumlauncherсопределеннойпериодичностью(см.autovacuum_naptime) запускает рабочие процессы autovacuum worker, которые выполняют очистку. Дополнительно рабочие процессы могут собирать статистику для планировщика о качественных и количественных характеристиках данных в таблицах. Эта статистика нужна для построения планов запросов. Неэффективная работа автоочистки в перспективе негативно влияет на производительность,и с помощью статистики активности можно наблюдать за работой не только очистки,но и других фоновых процессов.

Подводяитог,можносказать,чтовPostgreSQLестьмногосложныхпроцессов,которыевлияют другнадруга и связаны между собой.При возникновении проблем администратору БД нужна информацияотом,какработаюттеилииныепроцессы.Дляотслеживанияразличныхсобытий СУБД имеетвнутренние инструменты,которые ведутучети хранятстатистику в специальной