Выполнение контрольной точки в PostgreSQL
Выполнением контрольной точки занимается специальный фоновый процесс checkpointer, который запускается вследствие следующих событий:
- Истекло время checkpoint_timeout от предыдущей контрольной точки (по умолчанию это 300 секунд);
- В версии 9.4 и более ранних весиях количество сегментных файлов WAL, заданное для checkpoint_segments, израсходовано с момента предыдущей контрольной точки (по умолчанию это число равно 3);
- В версии 9.5 и новее суммарный размер файлов сегмента WAL в каталоге pg_wal (в версии 9.6 и более ранних версиях - pg_xlog) превысил значение параметра max_wal_size (значение по умолчанию - 1 ГБ (64 файла));
- Сервер PostgreSQL останавлиется в режим smart или fast;
- Суперпользователь выполняет команду CHECKPOINT вручную.
Примечание:
В версияи 9.1 и более ранних версиях, как уже было сказано выше, процесс фоновой записи выполнял как checlprinting, так и запись грязных страниц..
Далее мы опишем схему создания контрольных точек, а также файл pg_control, в котором хранятся метаданные текущей контрольной точки.
Процесс контрольной точки
Процесс контрольной точки имеет два аспекта: подготовка к восстановлению базы данных и очистка грязных страниц в общем буферном пуле. В этом подразделе мы сосредоточимся на первом аспекте. Смотрите рис. 109.
(1) При запуске процесса контрольной точки в памяти сохраняется точка REDO. Точка REDO - это местоположение записи XLOG, которая была записана в момент запуска последней контрольной точки. Именно она является отправной точкой для восстановления базы данных;
(2) Запись XLOG этой контрольной точки (т. е. запись контрольной точки) записывается в буфер WAL. Часть данных этой записи определяется структурой CheckPoint, которая содержит несколько переменных, таких как точка REDO, сохраненная на шаге (1); Место, куда записывается запись контрольной точки, также называется контрольной точкой.
(3) Все данные в общей памяти (например, содержимое CLOG) сбрасывается в хранилище;
(4) Все грязные страницы в общем буферном пуле постепенно записываются и сбрасываются в хранилище;
(5) Обновляется файл pg_control, содержащий содержит информацию, такую как место, где была записана контрольная точка (она же местоположение контрольной точки).
Structure CheckPoint
typedef struct CheckPoint
{
XLogRecPtr redo; /* next RecPtr available when we began to
* create CheckPoint (i.e. REDO start point) */
TimeLineID ThisTimeLineID; /* current TLI */
TimeLineID PrevTimeLineID; /* previous TLI, if this record begins a new
* timeline (equals ThisTimeLineID otherwise) */
bool fullPageWrites; /* current full_page_writes */
uint32 nextXidEpoch; /* higher-order bits of nextXid */
TransactionId nextXid; /* next free XID */
Oid nextOid; /* next free OID */
MultiXactId nextMulti; /* next free MultiXactId */
MultiXactOffset nextMultiOffset;/* next free MultiXact offset */
TransactionId oldestXid; /* cluster-wide minimum datfrozenxid */
Oid oldestXidDB; /* database with minimum datfrozenxid */
MultiXactId oldestMulti; /* cluster-wide minimum datminmxid */
Oid oldestMultiDB; /* database with minimum datminmxid */
pg_time_t time; /* time stamp of checkpoint */
/* * Oldest XID still running. This is only needed to initialize hot standby * mode from an online checkpoint, so we only bother calculating this for * online checkpoints and only when wal_level is hot_standby. Otherwise * it's set to InvalidTransactionId. */ TransactionId oldestActiveXid; } CheckPoint;
Если обобщить приведенное выше описание с точки зрения восстановления базы данных, то при создании контрольной точки создается запись контрольной точки, содержащая точку REDO, и сохраняется местоположение контрольной точки, а также другая информация, содержащаяся в файле pg_control. Это позволяет PostgreSQL восстановиться путем воспроизведения WAL-данных из точки REDO, предоставленной файлом pg_control.
Файл pg_control
Информация о том, с какими внутренними значениями завершилась контрольная точка, хранится в файле global/pg_control и потому этот файл должен быть доступен СУБД еще до момента восстановления данных. Если PostgreSQL отключается нештатно, то изменения из файлов журнала (pg_xlog) применяются к файлам БД, начиная с позиции последней контрольной точки. Этот процесс называется восстановлением данных.
Несмотря на то, что в файле pg_control хранится более 40 элементов, ниже показаны три элемента, которые понадобятся в следующем разделе:
- текущее состояние: работает/остановлен;
- позиция в журнале, соответствующая запущенной контрольной точке;
- позиция в журнале, соответствующая предыдущей контрольной точке
Посмотреть содержимое pg_control можно при помощи утилиты pg_controldata:
postgres> pg_controldata /usr/local/pgsql/data pg_control version number: 1300 Catalog version number: 202306141 Database system identifier: 7250496631638317596 Database cluster state: in production pg_control last modified: Mon Jan 1 15:16:38 2024 Latest checkpoint location: 0/16AF0090 Latest checkpoint's REDO location: 0/16AF0090 Latest checkpoint's REDO WAL file: 000000010000000000000016 ... snip ...
Примечание: Удаление предыдущей контрольной точки в PostgreSQL 11
PostgreSQL 11 и новее хранят только сегменты WAL, содержащие последнюю контрольную точку или более новую. Более старые файлы сегментов, содержащие предыдущую контрольную точку, не сохраняются, что позволяет уменьшить дисковое пространство, используемое для сохранения файлов сегментов WAL в подкаталоге pg_wal.
