29.6. Внутреннее устройство WAL#
29.6. Внутреннее устройство WAL
WAL включается автоматически; администратору не требуется никаких действий, кроме обеспечения выполнения требований к дисковому пространству для журналов WAL и выполнения необходимой настройки (см. Раздел 29.5).
WAL записи добавляются в журналы WAL по мере записи каждой новой записи. Позиция вставки описывается номером последовательности журнала (LSN), который представляет собой смещение в байтах в журналах и увеличивается монотонно с каждой новой записью. Значения LSN возвращаются в виде типа данных pg_lsn. Значения могут быть сравнены для вычисления объема данных WAL, разделяющих их, поэтому они используются для измерения прогресса репликации и восстановления.
Журналы WAL хранятся в каталоге pg_wal внутри каталога данных в виде набора сегментных файлов, обычно размером 16 МБ каждый (но размер можно изменить, изменив параметр --wal-segsize опции initdb). Каждый сегмент разделен на страницы, обычно по 8 кБ каждая (этот размер можно изменить с помощью параметра --with-wal-blocksize опции configure). Заголовки записей журнала описаны в файле access/xlogrecord.h; содержимое записи зависит от типа события, которое регистрируется. Файлы сегментов имеют имена, состоящие из последовательно возрастающих чисел, начиная с 000000010000000000000001. Числа не оборачиваются, но потребуется очень, очень долгое время, чтобы исчерпать имеющийся запас чисел.
Это выгодно, если журнал находится на другом диске, отличном от основных файлов базы данных. Это можно сделать, переместив каталог pg_wal в другое место (конечно, при выключенном сервере) и создав символическую ссылку из исходного местоположения в основном каталоге данных в новое место.
Целью WAL является гарантировать, что журнал будет записан перед изменением записей в базе данных, но это может быть нарушено дисками. которые ложно сообщают о успешной записи в ядро, когда на самом деле они только кешируют данные и еще не сохраняют их на диск. Потеря питания в такой ситуации может привести к необратимой повреждению данных. Администраторы должны стараться обеспечить чтобы диски, содержащие журналы Tantor SE's WAL не давали таких ложных отчетов. (См. Раздел 29.1).
После создания контрольной точки и сброса журнала, позиция контрольной точки сохраняется в файле pg_control. Поэтому при запуске процесса восстановления сервер сначала считывает файл pg_control, а затем запись контрольной точки; затем выполняется операция REDO, просматривая журнал вперед от позиции, указанной в записи контрольной точки. Поскольку весь контент страниц данных сохраняется в журнале при первом изменении страницы после контрольной точки (если не отключен параметр full_page_writes), все измененные с момента контрольной точки страницы будут восстановлены в согласованное состояние.
Чтобы справиться с ситуацией, когда файл pg_control поврежден, мы должны поддерживать возможность сканирования существующих сегментов журнала в обратном порядке - от новых к старым - чтобы найти последнюю контрольную точку. Это еще не реализовано.
Файл pg_control достаточно мал (менее одной страницы диска), поэтому он не подвержен проблемам частичной записи, и на данный момент не было сообщений о сбоях базы данных, вызванных исключительно невозможностью чтения самого файла pg_control. Таким образом, хотя теоретически это слабое место, на практике pg_control не представляет проблемы.