Резервное копирование
Обзор
13
Авторские права
© Postgres Professional, 2015‒2022
Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Логическое резервное копирование
Физическое резервное копирование
3
Логическое копирование
Что такое логическое резервное копирование
Копия таблицы
Копия базы данных
Копия кластера
4
Логическая копия
Команды SQL для восстановления данных с нуля
+ можно сделать копию отдельного объекта или базы
+ можно восстановиться на кластере другой основной версии
+ можно восстановиться на другой архитектуре
− невысокая скорость
Существует два вида резервирования: логическое и физическое.
Логическое резервирование — это набор команд SQL,
восстанавливающая кластер (или базу данных, или отдельный объект)
с нуля.
Такая копия представляет собой, по сути, обычный текстовый файл, что
дает известную гибкость. Например, можно сделать копию только тех
объектов, которые нужны; можно отредактировать файл, изменив
имена или типы данных и т. п.
Кроме того, команды SQL можно выполнить на другой версии СУБД
(при наличии совместимости на уровне команд) или на другой
архитектуре (то есть не требуется двоичная совместимость).
Однако для большой базы этот механизм неэффективен, поскольку
выполнение команд займет много времени. К тому же восстановить
систему из такой резервной копии можно только на тот момент,
в который она была сделана.
5
COPY: копия таблицы
Резервное копирование
вывод таблицы или результатов запроса в файл, на консоль
или в программу
Восстановление
добавление строк из файла или с консоли к существующей таблице
Серверный вариант Клиентский вариант
команда SQL COPY команда psql \COPY
файл должен быть доступен файл должен быть доступен
пользователю postgres запустившему psql
на сервере на клиенте
Если требуется сохранить только содержимое одной таблицы, можно
воспользоваться командой COPY.
Команда позволяет записать таблицу (или результат произвольного
запроса) либо в файл, либо на консоль, либо на вход произвольной
программе. При этом можно указать ряд параметров, таких как формат
(текстовый, csv или двоичный), разделитель полей, текстовое
представление NULL и др.
Другой вариант команды, наоборот, считывает из файла или из консоли
строки с полями и записывает их в таблицу. Таблица при этом не
очищается, новые строки добавляются к уже существующим.
Команда COPY работает существенно быстрее, чем аналогичные
команды INSERT — клиенту не нужно много раз обращаться к серверу,
а серверу не нужно много раз анализировать команды.
В psql существует клиентский вариант команды COPY с аналогичным
синтаксисом. В отличие от серверного варианта COPY, который
является командой SQL, клиентский вариант — это команда psql.
Указание имени файла в команде SQL соответствует файлу на сервере
БД. У пользователя, под которым работает PostgreSQL (обычно
postgres), должен быть доступ к этому файлу. В клиентском варианте
обращение к файлу происходит на клиенте, а на сервер передается
только содержимое.
7
pg_dump: копия базы
Резервное копирование
выдает на консоль или в файл либо SQL-скрипт,
либо архив в специальном формате с оглавлением
поддерживает параллельное выполнение
позволяет ограничить набор выгружаемых объектов
(таблицы, схемы, только DML или только DDL и т. п.)
Восстановление
SQL-скрипт — psql
формат с оглавлением — pg_restore
(позволяет ограничить набор объектов при восстановлении
и поддерживает параллельное выполнение)
новая база должна быть создана из шаблона template0
заранее должны быть созданы роли и табличные пространства
Для создания полноценной резервной копии базы данных используется
утилита pg_dump. В зависимости от указанных параметров,
результатом работы является либо SQL-скрипт, содержащий команды,
создающие выбранные объекты, либо файл в специальном формате
с оглавлением.
Чтобы восстановить объекты из SQL-скрипта, достаточно прогнать его
через psql.
Для восстановления резервной копии в специальном формате
требуется другая утилита — pg_restore. Она читает файл и преобразует
его в обычные команды psql. Преимущество в том, что набор объектов
можно ограничить не при создании резервной копии, а уже при
восстановлении. Кроме того, создание резервной копии в специальном
формате и восстановление из нее может выполняться параллельно.
Базу данных для восстановления надо создавать из шаблона template0,
так как все изменения, сделанные в template1, также попадут
в резервную копию. Кроме того, заранее должны быть созданы
необходимые роли и табличные пространства, поскольку эти объекты
относятся ко всему кластеру. После восстановления базы имеет смысл
выполнить команду ANALYZE, которая соберет статистику.
8
pg_dumpall: копия кластера
Резервирование
сохраняет весь кластер, включая роли и табличные пространства
выдает на консоль или в файл SQL-скрипт
параллельное выполнение не поддерживается, но можно выгрузить
только глобальные объекты и воспользоваться pg_dump
Восстановление
с помощью psql
Чтобы создать резервную копию всего кластера, включая роли и
табличные пространства, можно воспользоваться утилитой pg_dumpall.
Поскольку pg_dumpall требуется доступ ко всем объектам всех БД,
имеет смысл запускать ее от имени суперпользователя. Утилита по
очереди подключается к каждой БД кластера и выгружает информацию
с помощью pg_dump. Кроме того, она сохраняет и данные,
относящиеся к кластеру в целом.
Результатом работы pg_dumpall является скрипт для psql. Другие
форматы не поддерживаются. Это означает, что pg_dumpall не
поддерживает параллельную выгрузку данных, что может оказаться
проблемой при больших объемах данных. В таком случае можно
воспользоваться ключом --globals-only, чтобы выгрузить только роли и
табличные пространства, а сами базы данных выгрузить с помощью
pg_dump.
10
Физическое копирование
Что такое физическое резервное копирование
Холодное и горячее резервное копирование
Протокол репликации
Автономные резервные копии
Непрерывная архивация журналов предзаписи
11
Физическая копия
Используется механизм восстановления после сбоя:
копия данных и журналы предзаписи
+ скорость восстановления
+ можно восстановить кластер на определенный момент времени
− нельзя восстановить отдельную базу данных, только весь кластер
− восстановление только на той же основной версии и архитектуре
Физическое резервирование использует механизм восстановления
после сбоев. Для этого требуются:
- копия файлов кластера (базовая резервная копия);
- набор журналов предзаписи, необходимых для восстановления
согласованности.
Если файловая система уже согласована (копия снималась при
корректно остановленном сервере), то журналы не требуются.
Однако наличие архива журналов позволяет из базовой резервной
копии получить состояние кластера на любой момент времени. Таким
образом можно восстановить резервную копию практически на момент
сбоя (либо сознательно восстановить систему на некоторый момент
в прошлом).
Высокая скорость восстановления и возможность создавать копию
«на лету», не выключая сервер, делает физическое резервирование
основным инструментом периодического резервного копирования.
12
Горячо или холодно?
Холодное резервирование
Горячее
резервирование
Файловая система
копируется при...
выключенном
сервере
неаккуратно
выключенном
сервере
работающем
сервере
Журналы
предварительной
записи...
не нужны нужны с последней
контрольной точки
нужны за время
копирования ФС
нужны
специальные
средства
находятся
в файловой
системе
сервер
не должен удалить WAL
раньше времени
Физическое резервирование так или иначе предполагает создание
копии файловой системы.
Если копия создается при выключенном сервере, она называется
«холодной». Такая копия либо содержит согласованные данные (если
сервер был выключен аккуратно), либо содержит все необходимые для
восстановления журналы (например, если используется снимок данных
средствами операционной системы). Это упрощает восстановление, но
требует останова сервера.
Если копия создается при работающем сервере (что требует
определенных действий — просто так копировать файлы нельзя), она
называется «горячей». В этом случае процедура сложнее, но позволяет
обойтись без останова.
При горячем резервировании копия ФС будет содержать
несогласованные данные. Однако механизм восстановления после
сбоев можно успешно применить и к восстановлению из резервной
копии. Для этого потребуются журналы предзаписи как минимум за
время копирования файлов.
13
Автономная копия
Автономная копия содержит и файлы данных, и WAL
Резервное копирование — утилита pg_basebackup
подключается к серверу по протоколу репликации
выполняет контрольную точку
копирует файловую систему в указанный каталог
сохраняет все сегменты WAL, сгенерированные за время копирования
Восстановление
разворачиваем созданную автономную копию
запускаем сервер
Для создания горячей резервной копии существует утилита
pg_basebackup.
Вначале утилита выполняет контрольную точку. Затем копируется
файловая система кластера.
Все файлы WAL, сгенерированные сервером за время от контрольной
точки до окончания копирования файлов, также копируются
в резервную копию. Такая копия называется автономной, поскольку
содержит в себе все необходимое для восстановления.
Для восстановления достаточно развернуть резервную копию и
запустить сервер. При необходимости он выполнит восстановление
согласованности с помощью имеющихся файлов WAL и будет готов
к работе.
14
Протокол репликации
Протокол
получение потока журнальных записей
команды управления резервным копированием и репликацией
Обслуживается процессом wal_sender
Параметр wal_level = replica
Слот репликации
серверный объект для получения журнальных записей
помнит, какая запись была считана последней
сегмент WAL не удаляется, пока он полностью не прочитан через слот
Чтобы сохранить все необходимые для восстановления файлы WAL,
сгенерированные сервером за время копирования файлов, утилита
подключается к серверу по специальному протоколу репликации.
Несмотря на название, это протокол используется не только для
репликации (о которой пойдет речь в следующей теме), но и для
резервного копирования. Протокол позволяет получать поток
журнальных записей параллельно с копированием файлом.
Чтобы сервер не удалил необходимые файлы WAL преждевременно,
может использоваться слот репликации.
Для того, чтобы подключение было возможно, необходим ряд настроек.
Во-первых, роль должна обладать атрибутом REPLICATION (или быть
суперпользователем). Кроме того, этой роли должно быть выдано
разрешение в конфигурационном файле pg_hba.conf.
Во-вторых, параметр max_wal_senders должен быть установлен
в достаточно большое значение. Этот параметр ограничивает число
одновременно работающих процессов wal_sender, обслуживающих
подключения по протоколу репликации.
В-третьих, параметр wal_level, определяющий количество информации
в журнале, должен быть установлен в значение replica.
Начиная с версии 10, настройки по умолчанию уже включают все эти
требования (при локальном подключении).
15
Автономная копия
базовая копия
+
WAL
основной сервер
сегменты WAL
select, insert
update, delete
p
g
_
b
a
s
e
b
a
c
k
u
p
На этом рисунке слева представлен основной сервер. Он обрабатывает
поступающие запросы; при этом формируются записи WAL и
изменяется состояние баз данных (сначала в буферном кеше, потом на
диске). Сегменты WAL циклически перезаписываются (точнее,
удаляются старые сегменты, так как имена файлов уникальны).
Внизу рисунка (а в реальной жизни — обычно на другом сервере)
изображена созданная резервная копия — базовая копия данных и
набор файлов WAL.
17
Восстановление
основной сервер
сегменты WAL
select, insert
update, delete
select, insert
update, delete
резервный сервер
базовая копия
+
WAL
При восстановлении базовая резервная копия, включающая
необходимые файлы WAL, разворачивается, например, на другом
сервере (справа на рисунке).
После старта сервера он восстанавливает согласованность и
приступает к работе. Восстановление происходит на тот момент
времени, на который была сделана резервная копия. Разумеется,
за прошедшее время основной сервер может уйти далеко вперед.
19
Архив журналов
Файловый архив
сегменты WAL копируются в архив по мере заполнения
механизм работает под управлением сервера
неизбежны задержки попадания данных в архив
Потоковый архив
в архив постоянно записывается поток журнальных записей
требуются внешние средства
задержки минимальны
Дальнейшее развитие идеи горячей резервной копии: раз у нас есть
копия файловой системы и журналы упреждающей записи, то,
постоянно сохраняя новые журналы, мы сможем восстановить систему
не только на момент копирования файлов, но и вообще на
произвольный момент.
Для этого есть два способа. Первый состоит в том, чтобы не просто
перезаписывать файлы WAL, а предварительно откладывать их куда-то
в архив. Это можно реализовать специальными настройками сервера.
К сожалению, при таком варианте файл WAL не попадет в архив, пока
сервер не переключится на запись в другой файл.
Второй способ — постоянно читать журнальные записи по протоколу
репликации и записывать их в тот же архив. При таком варианте
задержки будут минимальны, но потребуется настроить отдельную от
сервера утилиту для получения данных из потока.
20
Файловый архив журналов
Процесс archiver
Параметры
archive_mode = on
archive_command команда shell для копирования сегмента WAL
в отдельное хранилище
Алгоритм
при переключении сегмента WAL вызывается команда archive_command
если команда завершается со статусом 0, сегмент удаляется
если команда возвращает не 0 (в частности, если команда не задана),
сегмент остается до тех пор, пока попытка не будет успешной
Файловый архив реализуется фоновым процессом archiver.
PostgreSQL позволяет определить для копирования произвольную
команду shell в параметре archive_command. Сам механизм включается
параметром archive_mode = on.
Общий алгоритм таков. При заполнении очередного сегмента WAL
вызывается команда копирования. Если она завершается с нулевым
статусом, то сегмент может быть удален. Если же нет, то сегмент
(и следующие за ним) не будет удален, а сервер будет периодически
пытаться выполнить команду, пока не получит 0.
21
Файловый архив журналов
archive_command
архив WAL
+
базовая копия
основной сервер
сегменты WAL
select, insert
update, delete
непрерывное
архивирование
На этом рисунке изображен основной сервер с настроенным
непрерывным архивированием: заполненные сегменты WAL
копируются в отдельный архив с помощью команды в параметре
archive_command. Обычно такой архив расположен на другом сервере.
Там же создается базовая резервная копия (или несколько копий,
сделанных в разные моменты времени).
22
Потоковый архив журналов
Утилита pg_receivewal
подключается по протоколу репликации (можно использовать слот)
и направляет поток записей WAL в файлы-сегменты
стартовая позиция — начало сегмента, следующего за последним
заполненным сегментом, найденным в каталоге,
или начало текущего сегмента сервера, если каталог пустой
в отличие от файлового архива, записи пишутся постоянно
при переходе на новый сервер надо перенастраивать параметры
Другое решение — использование утилиты pg_receivewal для записи
сегментов в архив по протоколу потоковой репликации.
Обычно утилита запускается на отдельном «архивном» сервере и
подключается к мастеру с параметрами, указанными в ключах. Утилита
может (и должна) использовать слот репликации, чтобы
гарантированно не потерять записи.
Утилита формирует файлы аналогично тому, как это делает сервер,
и записывает их в указанный каталог. Еще не заполненные сегменты
записываются с префиксом .partial.
Архивирование всегда начинается с начала сегмента, следующего за
последним заполненным сегментом архива. Если архив пуст (первый
запуск), архивирование начинается с начала текущего сегмента.
При переходе на новый сервер утилиту требуется остановить и
запустить заново с соответствующими параметрами.
Требуется учесть, что сама по себе утилита не запускается
автоматически (как сервис) и не демонизируется.
23
Потоковый архив журналов
архив WAL
основной сервер
сегменты WAL
select, insert
update, delete
wal sender
pg_receivewal
Утилита pg_receivewal подключается к серверу по протоколу потоковой
репликации. Подключение обрабатывается отдельным процессом wal
sender (это необходимо учесть при установке параметра
max_wal_senders).
Утилита записывает данные, не дожидаясь получения всего сегмента.
24
Резервная копия + архив
Настроенное непрерывное архивирование журналов
Резервное копирование — pg_basebackup
подключается к серверу по протоколу репликации
выполняет контрольную точку
копирует файловую систему в указанный каталог
Восстановление
разворачиваем резервную копию
задаем конфигурационные параметры
(чтение WAL из архива, указание целевой точки восстановления)
создаем сигнальный файл recovery.signal
запускаем сервер
сегменты WAL
в копии не нужны
Для создания резервной копии при настроенном непрерывном
архивировании используется та же утилита pg_basebackup, только
с другим набором параметров. Единственное отличие состоит в том,
что в резервную копию не сохраняются файлы WAL, поскольку они уже
есть в архиве.
Восстановление в таком случае выполняется более сложно. Помимо
разворачивания базовой резервной копии, требуется задать настройки
восстановления:
- команду restore_com mand (обратную archive_command — она
копирует нужные файлы из архива в каталог сервера);
- целевую точку восстановления.
Кроме этого, нужен сигнальный файл recovery.signal, наличие которого
при старте сервера означает указание войти в режим управляемого
восстановления (содержимое файла игнорируется).
25
Восстановление
restore_command
резервный сервер
архив WAL
+
базовая копия
основной сервер
сегменты WAL
не попал
в архив
Процедура восстановления (например, при выходе сервера из строя
основного сервера), выполняется следующим образом. На другом (или
на том же) сервере разворачивается базовая резервная копия и
создается файл recovery.signal. Сервер запускается и начинает читать
сегменты WAL из архива, используя restore_command, и применять их.
Следует обратить внимание, что при файловой архивации последний
незаполненный сегмент WAL основного сервера не попадет в архив.
Однако сегмент можно вручную подложить резервному серверу
в каталог pg_wal, если есть такая возможность. Конечно, таких
сегментов может оказаться и несколько, но только в случае какого-то
сбоя при архивировании.
26
Восстановление
restore_command
резервный сервер
архив WAL
+
базовая копия
основной сервер
сегменты WAL
целевая точка
восстановления
Резервный сервер применяет все доступные записи WAL, читая
сегменты из каталога pg_wal (при отсутствии сегмента делая попытку
скопировать его из архива), тем самым доводя состояние баз данных
до актуального. Максимально возможная потеря — незаполненный
сегмент WAL, не попавший в архив, если его по каким-то причинам
невозможно скопировать.
По умолчанию применяются все доступные журнальные записи,
а указание целевой точки восстановления позволяет остановить их
применение в желаемый момент.
27
Восстановление
select, insert
update, delete
archive_command
резервный сервер
архив WAL
+
базовая копия
основной сервер
сегменты WAL
После этого резервный сервер переходит в обычный режим работы:
принимает запросы, записывает сегменты WAL в архив и так далее,
выступая в качестве нового полноценного основного сервера.
Если развернутый сервер предполагается использовать вместо
основного, то его имеет смысл располагать на таком же или, по крайней
мере, сравнимом по характеристикам аппаратуры сервере, чтобы
избежать снижения производительности.
28
Итоги
Логическая резервная копия —
команды SQL для восстановления состояния объектов
команда copy, утилиты pg_dump и pg_dumpall
Физическая резервная копия —
копия файлов кластера + набор файлов WAL
утилита pg_basebackup
Архив журнальных файлов
файловый или потоковый
позволяет восстановить систему на произвольный момент времени
29
Практика
1. Создайте базу данных и таблицу в ней с несколькими
строками.
2. Сделайте логическую копию базы данных с помощью
утилиты pg_dump.
Удалите базу данных и восстановите ее из сделанной копии.
3. Сделайте автономную физическую резервную копию
кластера с помощью утилиты pg_basebackup.
Измените таблицу.
Восстановите новый кластер из сделанной резервной копии
и проверьте, что база данных не содержит более поздних
изменений.
3. В виртуальной машине курса уже создан кластер replica на порту
5433. Используйте этот кластер, для того чтобы восстановить
резервную копию.
Каталог кластера располагается в /var/lib/postgresql/13/replica.
Для подключения укажите номер порта: psql -p 5433
30
Практика+
1. Организуйте потоковую архивацию кластера main
с помощью утилиты pg_receivewal.
2. Сделайте автономную резервную копию кластера main
(без WAL) с помощью утилиты pg_basebackup.
3. В кластере main создайте базу данных и таблицу в ней.
4. Выполните восстановление кластера replica из базовой копии
с использованием архива. Убедитесь, что база и таблица
тоже восстановились.
Кластер replica находится в /var/lib/postgresql/13/replica.
Текущий файл, записываемый утилитой pg_receivewal, имеет
суффикс.partial, по окончании записи файл переименовывается. При
восстановлении наряду с обычными сегментами нужно использовать и
последний недозаписанный файл.
Для подключения к кластеру replica укажите номер порта: psql -p 5433.
