Резервное копирование
Обзор
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 копируются в архив по мере заполнения
механизм работает под управлением сервера
неизбежны задержки попадания данных в архив
Потоковый архив
в архив постоянно записывается поток журнальных записей
требуются внешние средства
задержки минимальны
Дальнейшее развитие идеи горячей резервной копии: раз у нас есть
копия файловой системы и журналы упреждающей записи, то,
постоянно сохраняя новые журналы, мы сможем восстановить систему
не только на момент копирования файлов, но и вообще на
произвольный момент.
Для этого есть д