31.1. Очистка памяти
В зависимости от параметров конфигурации очистки памяти Postgres Pro Standard может автоматически перезаписывать данные нулевыми байтами перед удалением. В этом разделе описывается, как очищаются данные различных типов. По умолчанию все параметры очистки памяти включены.
31.1.1. Удаление файлов из внешней памяти
Когда вы выполняете команды SQL, удаляющие файлы, соответствующее дисковое пространство возвращается операционной системе. К таким командам относятся:
Команды, удаляющие объекты БД:
DROP TABLEDROP TEMPORARY TABLEDROP MATERIALIZED VIEWDROP INDEXTRUNCATEDROP DATABASEDROP SCHEMA
Команды, пересоздающие объекты:
VACUUM FULLREINDEXALTER TABLE ADD COLUMN(со значением по умолчанию)ALTER TABLE ALTER COLUMN TYPE
Если параметр конфигурации wipe_file_on_delete включён, файлы перед удалением сначала заполняются нулевыми байтами.
Примечание
Команда ALTER TABLE DROP COLUMN не пересоздаёт файл. Все данные, содержащиеся в удаляемом столбце, остаются внутри страниц, хотя к ним и нельзя обращаться с помощью команд SQL. Чтобы физически удалить эти данные из файла, выполните VACUUM FULL после удаления столбца.
31.1.2. Очистка страниц
В соответствии с моделью MVCC (Multiversion Concurrency Control, Многоверсионное управление конкурентным доступом) при удалении строк (командой DELETE) данные, содержащиеся в этих строках, помечаются как удалённые, но физически не удаляются. При модификации строк (командой UPDATE) сначала удаляется старая версия строки, а затем вставляется новая, так что предыдущее содержимое так же сохраняется в странице.
Чтобы механизм MVCC работал корректно, Postgres Pro сохраняет удалённые данные в страницах до тех пор, пока эта версия может быть востребована какими-либо активными снимками. Если строка задействуется в индексах, то в страницах индексов так же сохраняются ссылки на строки, которые были удалены, но ещё не освобождены. Когда версия строки не востребована никакими снимками, её можно удалить, произведя процедуру VACUUM. При этом все ссылки на эту версию будут удалены и из индексов. Однако это удаление не подразумевает физическое уничтожение: в обычном режиме соответствующее место в странице помечается как свободное и может использоваться для размещения другой строки.
Для предотвращения доступа к удалённым версиям строк необходимо включить параметр wipe_heaptuple_on_delete в файле конфигурации postgresql.conf. При этом процесс VACUUM будет не только помечать место в страницах как свободное, но и заполнять его нулевыми байтами.
31.1.3. Очистка блоков памяти в ОЗУ
Во время работы сервера оперативная память (в ОЗУ) постоянно выделяется и освобождается. Postgres Pro использует собственную подсистему управления памятью, основанную на контекстах, в которой память всегда выделяется в одном из вложенных контекстов. При удалении контекста освобождается вся память, выделенная в нём и в соответствующих вложенных контекстах. Этот подход позволяет избежать утечек памяти. Тем не менее выделением и освобождением памяти в конце концов занимается операционная система. В обычных условиях освобождаемая область ОЗУ возвращается операционной системе и может быть выделена другому процессу.
Чтобы из освобождаемой области ОЗУ удалялись все данные, включите следующие параметры в файле конфигурации postgresql.conf:
wipe_memctx_on_free — этот параметр включает заполнение нулевыми байтами освобождаемой памяти в каком-либо контексте.
wipe_mem_on_free — этот параметр включает заполнение нулевыми байтами освобождаемой памяти, не принадлежащей никакому контексту. Хотя Postgres Pro всегда выделяет память в контекстах, вы можете воспользоваться этим параметром для большей уверенности.
31.1.4. Очистка файлов WAL
Журнал предзаписи (Write-Ahead Log, WAL) представляет собой стандартный способ обеспечения целостности данных, позволяющий осуществлять резервное копирование, восстановление на момент времени и репликацию данных между серверами. Концептуальной сущностью WAL является то, что изменения в каталогах данных (где располагаются таблицы и индексы) должны производиться только после фиксации изменений в журнале, то есть после того, как записи журнала, описывающие изменения, окажутся в постоянном хранилище. Таким образом WAL может содержать важные данные, которые необходимо защищать.
Сервер Postgres Pro всегда сохраняет определённое количество сегментов WAL в каталоге $PGDATA/pg_wal. Минимальный объём сохраняемых сегментов WAL определяется параметром min_wal_size. В случае большой нагрузки размер сегментов WAL может увеличиться до значения max_wal_size и даже несколько его превысить. Пока размер журнала WAL на диске остаётся больше min_wal_size, старые файлы сегментов WAL удаляются при освобождении. В противном случае сегменты WAL перезаписываются.
Для недопущения неавторизованного доступа к освобождённым сегментам WAL необходимо включить параметр wipe_xlog_on_free в файле конфигурации postgresql.conf. В этом случае сегмент WAL будет заполнен нулевыми байтами перед удалением или повторным использованием.
Более подробно конфигурация и использование WAL описывается в Главе 28.
31.1. Memory Purge
Using memory purge configuration parameters, Postgres Pro Standard can automatically replace data with zero bytes before it is deleted. This section describes how different types of data are handled. By default, all the memory purge parameters are switched on.
31.1.1. Deleting Files from External Memory
When you run some SQL commands that delete files, the corresponding disk space is returned to the operating system. Such commands include:
Commands that delete database objects:
DROP TABLEDROP TEMPORARY TABLEDROP MATERIALIZED VIEWDROP INDEXTRUNCATEDROP DATABASEDROP SCHEMA
Commands that re-create objects:
VACUUM FULLREINDEXALTER TABLE ADD COLUMN(with the default value)ALTER TABLE ALTER COLUMN TYPE
If the wipe_file_on_delete configuration parameter is switched on, the files to be deleted are first filled with zero bytes.
Note
The ALTER TABLE DROP COLUMN command does not re-create the file. All the data contained in the deleted column remains inside the pages, although you cannot access this data using SQL commands. To physically remove this data from the file, run VACUUM FULL after deleting the column.
31.1.2. Page Cleanup
In accordance with the Multiversion Concurrency Control (MVCC) model, when rows are deleted (with the DELETE command) the data stored in these rows is marked as deleted, but is not physically removed. In the case of row updates (with the UPDATE command), the old version of the row is deleted, and then a new version is inserted, so the previous value is not removed from the page either.
To ensure that MVCC mechanism is working correctly, Postgres Pro keeps the deleted data in the page while the saved version of the row can be accessed by at least one active snapshot. If the row is referenced from indexes, index pages also keep references to the row versions that are deleted but not yet freed. When the row version is not referenced from any snapshot anymore, this version can be deleted with the VACUUM process. At the same time, all references to this row version are deleted from indexes. However, deleting does not mean physical removal: in normal operation, the corresponding space in the page is marked as free and can be used to store another row.
To prevent access to the deleted row versions, make sure that the wipe_heaptuple_on_delete parameter is switched on in the postgresql.conf configuration file. In this case, the VACUUM process not only marks the page spaces as free, but also fills them with zero bytes.
31.1.3. Clearing Random-Access Memory
While the server is running, random-access memory (RAM) is constantly allocated and released. Postgres Pro uses its own context-based system of memory allocation, in which memory is always allocated in one of the nested contexts. Deleting a context frees all the memory allocated in this context and the corresponding nested contexts. This approach helps to avoid memory leaks. Nevertheless, memory allocation and release are ultimately performed by the operating system. In normal operation, the released part of RAM is returned to the operating system and can be allocated to another process.
To remove all the data from the released part of RAM, make sure that the following parameters are switched on in the postgresql.conf configuration file:
wipe_memctx_on_free — this parameter fills the released memory with zero bytes if the released memory belongs to a context.
wipe_mem_on_free — this parameter fills the released memory with zero bytes if the released memory does not belong to any context. Although Postgres Pro always allocates memory within a particular context, you can still use this parameter to be on the safe side.
31.1.4. Cleaning up WAL Files
Write-Ahead Log (WAL) is a standard method for ensuring data integrity, which enables database backups, point-in-time recovery, and data replication between servers. WAL's central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been logged, that is, after log records describing the changes have been flushed to permanent storage. Thus, WAL can contain sensitive data that must be secured.
Postgres Pro server always stores a certain number of WAL segments in the $PGDATA/pg_wal directory. The minimum amount of WAL segments to store is defined by the min_wal_size parameter. In case of heavy load, the size of WAL segments can increase up to the max_wal_size value, or even exceed this value a little. As long as WAL disk usage stays above the min_wal_size threshold, old WAL segment files are deleted when they are released. Otherwise, WAL segments get overwritten.
To prevent unauthorized access to the released WAL segments, make sure that the wipe_xlog_on_free parameter is switched on in the postgresql.conf configuration file. In this case, the WAL segment will be filled with zero bytes before it is deleted or overwritten.
For details on WAL configuration and usage, see Chapter 28.