29.5. Внутреннее устройство WAL

WAL включается автоматически; от администратора не требуется никаких действий за исключением того, чтобы убедиться, что выполнены требования WAL к месту на диске, и что выполнены все необходимые действия по тонкой настройке (см. Section 29.4).

Журналы WAL хранятся в каталоге pg_xlog, который находится в каталоге data, в виде списка файлов сегментов, обычно 16MB каждый (но этот размер может быть изменён с помощью опции конфигурации --with-wal-segsize во время компиляции сервера). Каждый файл сегмента разделяется на страницы, обычно по 8KB каждая (данный размер может быть изменён с помощью опции конфигурации --with-wal-blocksize). Заголовки записи журнала описываются в access/xlog.h; содержимое самой записи зависит от типа события, которое сохраняется в журнал. Файлы сегментов имеют имена-номера, которые начинаются с 000000010000000000000000 и увеличваются автоматически. Эти номера не перекрываются, но пока доступные номера исчерпаются, пройдёт очень, очень долгое время.

Выгодно размещать журнал на другом диске, отличном от того, где находятся основные файлы базы данных. Этого можно достигнуть, переместив каталог pg_xlog из каталога data в другое место (разумеется, когда сервер остановлен) и затем создав символьную ссылку на перемещённый каталог в каталоге data.

Цель WAL состоит в том, чтобы иметь уверенность, что журнал записывается перед тем как будут изменены данные в базе данных, но это может быть извращено дисковыми драйверами , которые ложно сообщают ядру об успешном завершении записи, хотя фактически они только закэшировали данные и пока не сохранили их на диск. Сбой питания в такой ситуации может привести к непоправимому повреждению данных. Администраторы должны попытаться убедиться, что диски, которые хранят файлы журналов WAL PostgreSQL, не выдают таких ложных сообщений ядру. (См. Section 29.1.)

При наступлении контрольной точки и сохранения журнала, позиция контрольной точки сохраняется в файл pg_control. Таким образом, при старте восстановления, сервер сперва читает файл pg_control и затем запись контрольной точки; затем он выполняет операцию наката REDO, сканируя вперёд от точки журнала, обозначенной в записи контрольной точки. Поскольку полное содержимое страниц данных сохраняется в журнале в первой странице после контрольной точки (учитывая, что full_page_writes не выключено), все страницы, изменённые с момента контрольной точки будут всстановлены в целостное состояние.

В случае, если файл pg_control повреждён, мы должны поддерживать возможность сканирования существующих сегментов журнала в обратном порядке — от новых к старым — чтобы найти последнюю контрольную точку. Это пока не реализовано. pg_control является достаточно маленьким файлом (меньше, чем одна дисковая страница), который не должен попадать под проблему частичной записи и на момент написания данной документации, не было ни одного сообщения о сбоях СУБД исключительно из-за невозможности чтения самого файла pg_control. Таким образом, хотя теоретически это является слабым местом, на практике проблем с pg_control не обнаружено.