Как восстановить базу данных postgresql
Резервное копирование PostgreSQL
В данной инструкции рассмотрены варианты создания резервных копий и восстановления баз СУБД PostgreSQL.
Все команды, которые приводятся ниже, должны выполняться из командной строки. В Linux — это окно терминала, в Windows — командная строка (cmd.exe) с переходом в папку установки PostgreSQL.
Создание резервных копий
Базовая команда
pg_dump users > /tmp/users.dump
Пользователь и пароль
Если резервная копия выполняется не от учетной записи postgres, необходимо добавить опцию -U с указанием пользователя:
* где dmosk — имя учетной записи; опция W потребует ввода пароля.
Сжатие данных
Для экономии дискового пространства или более быстрой передачи по сети можно сжать наш архив:
pg_dump users | gzip > users.dump.gz
Скрипт для автоматического резервного копирования
Рассмотрим 2 варианта написания скрипта для резервирования баз PostgreSQL. Первый вариант — запуск скрипта от пользователя root для резервирования одной базы. Второй — запуск от пользователя postgres для резервирования всех баз, созданных в СУБД.
Для начала, создадим каталог, в котором разместим скрипт, например:
Вариант 1. Запуск от пользователя root; одна база.
PGPASSWORD=password
export PGPASSWORD
pathB=/backup
dbUser=dbuser
database=db
* где password — пароль для подключения к postgresql; /backup — каталог, в котором будут храниться резервные копии; dbuser — имя учетной записи для подключения к БУБД; pathB — путь до каталога, где будут храниться резервные копии.
* данный скрипт сначала удалит все резервные копии, старше 61 дня, но оставит от 15-о числа как длительный архив. После при помощи утилиты pg_dump будет выполнено подключение и резервирование базы db. Пароль экспортируется в системную переменную на момент выполнения задачи.
Для запуска резервного копирования по расписанию, сохраняем скрипт в файл, например, /scripts/postgresql_dump.sh и создаем задание в планировщике:
3 0 * * * /scripts/postgresql_dump.sh
* наш скрипт будет запускаться каждый день в 03:00.
Вариант 2. Запуск от пользователя postgres; все базы.
* где /backup — каталог, в котором будут храниться резервные копии; pathB — путь до каталога, где будут храниться резервные копии.
* данный скрипт сначала удалит все резервные копии, старше 61 дня, но оставит от 15-о числа как длительный архив. После найдет все созданные в СУБД базы, кроме служебных и при помощи утилиты pg_dump будет выполнено резервирование каждой найденной базы. Пароль нам не нужен, так как по умолчанию, пользователь postgres имеет возможность подключаться к базе без пароля.
Необходимо убедиться, что у пользователя postgre будет разрешение на запись в каталог назначения, в нашем примере, /backup/postgres.
Зададим в качестве владельца файла, пользователя postgres:
chown postgres:postgres /scripts/postgresql_dump.sh
Для запуска резервного копирования по расписанию, сохраняем скрипт в файл, например, /scripts/postgresql_dump.sh и создаем задание в планировщике:
* мы откроем на редактирование cron для пользователя postgres.
3 0 * * * /scripts/postgresql_dump.sh
* наш скрипт будет запускаться каждый день в 03:00.
Права и запуск
Разрешаем запуск скрипта, как исполняемого файла:
chmod +x /scripts/postgresql_dump.sh
Единоразово можно запустить задание на выполнение резервной копии:
. или от пользователя postgres:
На удаленном сервере
* необходимо убедиться, что сама СУБД разрешает удаленное подключение. Подробнее читайте инструкцию Как настроить удаленное подключение к PostgreSQL.
Дамп определенной таблицы
Запускается с опцией -t или —table= :
* где students — таблица; users — база данных.
Размещение каждой таблицы в отдельный файл
* где /tmp/folder — путь до каталога, в котором разместяться файлы дампа для каждой таблицы.
Только схемы (структуры)
Для резервного копирования без данных (только таблицы и их структуры):
* в данном примере мы создадим дамп структуры базы данных users только для схемы production.
Или полный дамп с данными для схемы внутри базы данных:
Только данные
Использование pgAdmin
Данный метод хорошо подойдет для компьютеров с Windows и для быстрого создания резервных копий из графического интерфейса.
В открывшемся окне выбираем путь для сохранения данных и настраиваемый формат:
При желании, можно изучить дополнительные параметры для резервного копирования:
Не текстовые форматы дампа
Другие форматы позволяют делать частичное восстановление, работать в несколько потоков и сжимать данные.
Как восстановить базу данных PostgreSQL из архива
Пришло время поговорить о восстановлении базы данных PostgreSQL из архива, так как к тому времени, когда Вы с этим столкнетесь, Вы уже должны будите уметь это делать, для того чтобы оперативно восстановить работу базы и соответственно всех приложений, которые работают с ней. Иначе Вы можете получить всякого рода выговоры от руководства за простой процесса производства.
Чуть ранее мы с Вами рассмотрели возможность создания резервной копии базы данных PostgreSQL в материале Как создать архив базы PostgreSQL, а теперь пора научиться восстанавливать базы из backup.
Если Вы знаете, как создается backup в PostgreSQL, то понимаете, что это делается достаточно просто, поэтому и восстановить базу также не составит труда.
Мы с Вами рассматривали два варианта создания архива, через графический интерфейс pgAdmin и через командную строку, поэтому и восстанавливать мы будем также двумя способами. Только в отличие от создания backup, через батник (для ежедневной автоматической архивации) который нам был нужен практически только для того, чтобы автоматизировать этот процесс и забыть про него, при восстановлении нам такая автоматизация не нужна, так как не каждый день приходится восстанавливать базу данных. Но мы все равно рассмотрим вариант через bat-файл, только для того чтобы Вы знали, как это делается и в случае необходимости оперативно восстановили базу, путем простого запуска батника, так как через графический интерфейс, согласитесь, займет немного больше времени.
Итак, приступим, если Вы помните, что при архивации использовалась утилита pg_dump.exe, то при восстановлении используется утилита pg_restore.exe
Примечание! Как и при создании архива, в качестве примера мы использовали локальный сервер PostgreSQL 8.4, на Windows 7, так и сегодня мы будем использовать именно данные версии СУБД и ОС.
Восстанавливаем базу через pgAdmin
Открываем pgAdmin, подключаемся к серверу, выбираем правой кнопкой мыши базу, и щелкаем «Восстановить»
Затем открывается окно восстановления базы, где Вы можете задать параметры восстановления, в частности выбрать архив, я здесь поставил галочку «Очистить перед восстановлением» так как если ее не ставить достаточно часто база восстанавливается с ошибкой (но все равно восстанавливается), и жмем «ОК»
После Вам останется, дождаться восстановления и нажать кнопку «Завершить»
Восстанавливаем базу с помощью батника
Для этого открываем блокнот (удобней Notepad++) и вставляем в него следующие команды (символ ^ это перенос строки):
Где, не трудно догадаться первая строка это запуск утилиты, вторая это подключение к серверу, третья выбор базы для восстановления, параметры восстановления и соответственно из чего это все восстанавливать. Только одно замечание, при восстановлении проверьте путь к архиву, т.е. необходимо выбрать актуальный архив на момент восстановления, чтобы не получилось ситуации, когда Вы якобы восстановили базу, только скажем прошлогодней версии, а пользователи смотрят и удивляются:)
Как видите, восстанавливать базу не так страшно как кажется.
На сегодня все, в следующих статьях мы будем рассматривать, как можно создавать и восстанавливать backup базы данных, но только уже на СУБД MSSql 2008.
Мой первый опыт восстановления базы данных Postgres после сбоя (invalid page in block 4123007 of relatton base/16490)
Хочу поделиться с вами моим первым успешным опытом восстановления полной работоспособности базы данных Postgres. С СУБД Postgres я познакомился пол года назад, до этого опыта администрирования баз данных у меня не было совсем.
Я работаю полу-DevOps инженером в крупной IT-компании. Наша компания занимается разработкой программного обеспечения для высоконагруженных сервисов, я же отвечаю за работоспособность, сопровождение и деплой. Передо мной поставили стандартную задачу: обновить приложение на одном сервере. Приложение написано на Django, во время обновления выполняются миграции (изменение структуры базы данных), и перед этим процессом мы снимаем полный дамп базы данных через стандартную программу pg_dump на всякий случай.
Во время снятия дампа возникла непредвиденная ошибка (версия Postgres – 9.5):
Ошибка «invalid page in block» говорит о проблемах на уровне файловой системы, что очень нехорошо. На различных форумах предлагали сделать FULL VACUUM с опцией zero_damaged_pages для решения данной проблемы. Что же, попрробеум…
Подготовка к восстановлению
ВНИМАНИЕ! Обязательно сделайте резервную копию Postgres перед любой попыткой восстановить базу данных. Если у вас виртуальная машина, остановите базу данных и сделайте снепшот. Если нет возможности сделать снепшот, остановите базу и скопируйте содержимое каталога Postgres (включая wal-файлы) в надёжное место. Главное в нашем деле – не сделать хуже. Прочтите это.
Сервер был физическим, снять снепшот было невозможно. Бекап снят, двигаемся дальше.
Проверка файловой системы
Перед попыткой восстановления базы данных необходимо убедиться, что у нас всё в порядке с самой файловой системой. И в случае ошибок исправить их, поскольку в противном случае можно сделать только хуже.
В моём случае файловая система с базой данных была примонтирована в «/srv» и тип был ext4.
Останавливаем базу данных: systemctl stop postgresql@9.5-main.service и проверяем, что файловая система никем не используется и её можно отмонтировать с помощью команды lsof:
lsof +D /srv
Мне пришлось ещё остановить базу данных redis, так как она тоже исползовала «/srv». Далее я отмонтировал /srv (umount).
Далее с помощью утилиты dumpe2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep checked) можно убедиться, что проверка действительно была произведена:
e2fsck говорит, что проблем на уровне файловой системы ext4 не найдено, а это значит, что можно продолжать попытки восстановить базу данных, а точнее вернуться к vacuum full (само собой, необходимо примонтирвоать файловую систему обратно и запустить базу данных).
Попытка 1: zero_damaged_pages
Подключаемся к базе через psql аккаунтом, обладающим правами суперпользователя. Нам нужен именно суперпользователь, т.к. опцию zero_damaged_pages может менять только он. В моём случае это postgres:
Опция zero_damaged_pages нужна для того, чтобы проигнорировать ошибки чтения (с сайта postgrespro):
При выявлении повреждённого заголовка страницы Postgres Pro обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр zero_damaged_pages включён, вместо этого система выдаёт предупреждение, обнуляет повреждённую страницу в памяти и продолжает обработку. Это поведение разрушает данные, а именно все строки в повреждённой странице.
Включаем опцию и пробуем делать full vacuum таблицы:
К сожалению, неудача.
Мы столкнулись с аналогичной ошибкой:
pg_toast – механизм хранения «длинных данных» в Postgres, если они не помещаются в одну страницу (по умолчанию 8кб).
Попытка 2: reindex
Первый совет из гугла не помог. После нескольких минут поиска я нашёл второй совет – сделать reindex повреждённой таблицы. Этот совет я встречал во многих местах, но он не внушал доверия. Сделаем reindex:
reindex завершился без проблем.
Однако это не помогло, VACUUM FULL аварийно завершался с аналогичной ошибкой. Поскольку я привык к неудачам, я стал искать советов в интернете дальше и наткнулся на довольно интересную статью.
Попытка 3: SELECT, LIMIT, OFFSET
В статье выше предлагали посмотреть таблицу построчно и удалить проблемные данные. Для начала необходимо было просмотреть все строки:
В моём случае таблица содержала 1 628 991 строк! По-хорошему необходимо было позаботиться о партициирвоании данных, но это тема для отдельного обсуждения. Была суббота, я запустил вот эту команду в tmux и пошёл спать:
К утру я решил проверить, как обстоят дела. К моему удивлению, я обнаружил, что за 20 часов было просканировано только 2% данных! Ждать 50 дней я не хотел. Очередной полный провал.
Но я не стал сдаваться. Мне стало интересно, почему же сканирование шло так долго. Из документации (опять на postgrespro) я узнал:
OFFSET указывает пропустить указанное число строк, прежде чем начать выдавать строки.
Если указано и OFFSET, и LIMIT, сначала система пропускает OFFSET строк, а затем начинает подсчитывать строки для ограничения LIMIT.
Применяя LIMIT, важно использовать также предложение ORDER BY, чтобы строки результата выдавались в определённом порядке. Иначе будут возвращаться непредсказуемые подмножества строк.
Очевидно, что вышенаписанная команда была ошибочной: во-первых, не было order by, результат мог получиться ошибочным. Во-вторых, Postgres сначала должен был просканировать и пропустить OFFSET-строк, и с возрастанием OFFSET производительность снижалась бы ещё сильнее.
Попытка 4: снять дамп в текстовом виде
Далее мне в голову пришла, казалось бы, гениальная идея: снять дамп в текстовом виде и проанализировать последнюю записанную строку.
Но для начала, ознакомимся со структурой таблицы ws_log_smevlog:
В нашем случае у нас есть столбец «id», который содержал уникальный идентификатор (счётчик) строки. План был такой:
Снятия дампа, как и ожидалось, прервался с той же самой ошибкой:
Попытка 5: SELECT, FROM, WHERE > Неудачи делают нас сильнее. Не стоит никогда сдаваться, нужно идти до конца и верить в себя и свои возможности. Поэтому я решил попробовать ешё один вариант: просто просмотреть все записи в базе данных по одному. Зная структуру моей таблицы (см. выше), у нас есть поле id, которое является уникальным (первичным ключом). В таблице у нас 1 628 991 строк и id идут по порядку, а это значит, что мы можем просто перербрать их по одному:
Если кто не понимает, команда работает следующим образом: просматривает построчно таблицу и отправляет stdout в /dev/null, но если команда SELECT проваливается, то выводится текст ошибки (stderr отправляется в консоль) и выводится строка, содержащая ошибку (благодаря ||, которая означает, что у select возникли проблемы (код возврата команды не 0)).
Мне повезло, у меня были созданы индексы по полю id:
А это значит, что нахождение строки с нужным id не должен занимать много времени. В теории должно сработать. Что же, запускаем команду в tmux и идём спать.
К утру я обнаружил, что просмотрено около 90 000 записей, что составляет чуть более 5%. Отличный результат, если сравнивать с предыдущим способом (2%)! Но ждать 20 дней не хотелось…
WAL-G: бэкапы и восстановление СУБД PostgreSQL
Уже давно известно, что делать бэкапы в SQL-дампы (используя pg_dump или pg_dumpall) – не самая хорошая идея. Для резервного копирования СУБД PostgreSQL лучше использовать команду pg_basebackup, которая делает бинарную копию WAL-журналов. Но когда вы начнёте изучать весь процесс создания копии и восстановления, то поймёте что нужно написать как минимум пару трёхколёсных велосипедов, чтобы всё это работало и не вызывало у вас боль как сверху, так и снизу. Дабы облегчить страдания был разработан WAL-G.
WAL-G – это инструмент, написанный на Go для резервного копирования и восстановления PostgreSQL баз данных (а с недавнего времени и MySQL/MariaDB, MongoDB и FoundationDB). Он поддерживает работу с хранилищами Amazon S3 (и аналогами, например, Yandex Object Storage), а также Google Cloud Storage, Azure Storage, Swift Object Storage и просто с файловой системой. Вся настройка сводится к простым шагам, но из-за того что статьи о нём разрозненны по интернету – нет полного how-to мануала, который бы включал все шаги от и до (на Хабре есть несколько постов, но многие моменты там упущены).
Данная статья написана в первую очередь чтобы систематизировать свои знания. Я не являюсь DBA и где-то могу выражаться обывательско-разработческим языком, поэтому приветствуются любые исправления!
Отдельно отмечу что всё нижеприведенное актуально и проверено для PostgreSQL 12.3 на Ubuntu 18.04, все команды должны выполняться от привилегированного пользователя.
Установка
В момент написания данной статьи стабильная версия WAL-G – v0.2.15 (март 2020). Её мы и будем использовать (но если вы захотите самостоятельно собрать его из master-ветки, то в репозитории на github есть все инструкции для этого). Для скачивания и установки нужно выполнить:
После этого нужно сконфигурировать вначале WAL-G, а потом сам PostgreSQL.
Настройка WAL-G
Для примера хранения бэкапов будет использоваться Amazon S3 (потому что он ближе к моим серверам и его использование обходится очень дёшево). Для работы с ним нужен «s3-бакет» и ключи доступа.
Немного поясню по всем параметрам:
Настройка PostgreSQL
Чтобы архиватор внутри базы сам заливал WAL-журналы в облако и восстанавливался из них (в случае необходимости) – нужно задать несколько параметров в конфигурационном файле /etc/postgresql/12/main/postgresql.conf. Только для начала вам нужно убедиться, что никакие из нижеприведенных настроек не заданы в какие-то другие значения, чтобы при перезагрузке конфигурации – СУБД не упала. Добавить эти параметры можно с помощью:
Описание устанавливаемых параметров:
Настройка расписания резервного копирования
Как ни крути, но самым удобным способом для запуска – является cron. Именно его мы и настроим для создания резервных копий. Начнём с команды создания полного бэкапа: в wal-g это аргумент запуска backup-push. Но для начала лучше выполнить эту команду вручную от пользователя postgres, чтобы убедиться что всё хорошо (и нет каких-то ошибок доступа):
В аргументах запуска указан путь к директории с данными – напоминаю что его можно узнать, выполнив pg_lsclusters.
Если всё прошло без ошибок и данные загрузились в хранилище S3, то далее можно настроить периодический запуск в crontab:
В данном примере процесс бэкапа запускается каждый день в 4:15 утра.
Удаление старых резервных копий
Cron будет выполнять эту задачу каждый день в 6:30 утра, удаляя всё (полные бэкапы, дельты и WAL’ы) кроме копий за последние 10 дней, но оставит как минимум один бэкап до указанной даты, чтобы любая точка после даты попадала в PITR.
Восстановление из резервной копии
Ни для кого не секрет что залог здоровой базы – в периодическом восстановлении и проверке целостности данных внутри. Как восстановиться с помощью WAL-G – расскажу в этом разделе, а о проверках поговорим после.
Отдельно стоит отметить что для восстановления на тестовом окружении (всё то, что не production) – нужно использовать Read Only аккаунт в S3, чтобы случайно не перезаписать бэкапы. В случае с WAL-G нужно задать пользователю S3 следующие права в Group Policy (Effect: Allow): s3:GetObject, s3:ListBucket, s3:GetBucketLocation. И, конечно, предварительно не забыть выставить archive_mode=off в файле настроек postgresql.conf, чтобы ваша тестовая база не захотела сбэкапиться по-тихому.
Восстановление производится лёгким движением руки с удалением всех данных PostgreSQL (в том числе пользователей), поэтому, пожалуйста, будьте предельно аккуратны когда будете запускать следующие команды.
Для тех, кто хочет проверять процесс восстановления — ниже подготовлен небольшой кусок bash-магии, чтобы в случае проблем в восстановлении – скрипт упал с ненулевым exit code. В данном примере делается 120 проверок с таймаутом в 5 секунд (всего 10 минут на восстановление), чтобы узнать удалился ли сигнальный файл (это будет означать что восстановление прошло успешно):
После успешного восстановления не забудьте запустить обратно все процессы (pgbouncer/monit и тд).
Проверка данных после восстановления
Обязательно нужно проверить целостность базы после восстановления, чтобы не возникло ситуации с побитой/кривой резервной копией. И лучше делать это с каждым созданным архивом, но где и как – зависит только от вашей фантазии (можно поднимать отдельные сервера на почасовой оплате или запускать проверку в CI). Но как минимум – необходимо проверять данные и индексы в базе.
Для проверки данных достаточно прогнать их через дамп, но лучше чтобы при создании базы у вас были включены контрольные суммы (data checksums):
Для проверки индексов – существует модуль amcheck, sql-запрос к нему возьмём из тестов WAL-G и вокруг выстроим небольшую логику:
Резюмируя
Выражаю благодарность Андрею Бородину за помощь в подготовке публикации и отдельное спасибо за его вклад в разработку WAL-G!
На этом данная заметка подошла к концу. Надеюсь что смог донести легкость настройки и огромный потенциал для применения этого инструмента у вас в компании. Я очень много слышал о WAL-G, но никак не хватало времени сесть и разобраться. А после того как внедрил его у себя – из меня вышла эта статья.
Отдельно стоит заметить, что WAL-G также может работать со следующими СУБД:
Резервное копирование и восстановление в PostgreSQL
Режим архивирования WAL-логов настраивается через включение параметров archive_mode и archive_command в postgresql.conf и создание директории где будут храниться архивы. Для начала стоит включить режим архивирования и оценить объем архивов создаваемых за одни сутки работы базы данных. Это позволит провести оценку требуемого места для хранения архивов и базовых копий. За архивирование отвечают опции:
archive_mode = on
archive_command = ‘cp %p /opt/pgsql/pgbackup/archive/%f’
Непосредственное резервное копирование настраиваем средствами pg_basebackup. Это программа из комплекта утилит идущих вместе с PostgreSQL которую можно использовать как для настройки потоковой репликации, так и для снятия резервных копий. Принцип работы позволяет снимать резервную копию не останавливая кластер базы данных. Исходя из задачи, нам всего лишь нужно запускать pg_basebackup по расписанию в cron. Учитывая требования по месту, нужно позаботиться о достаточном месте на диске, во избежание переполнения.
Хранение резервных копий задача опциональная, так как достаточно иметь хотя бы одну резервную копию. Подразумевается что на момент запуска создания резервной копии мы согласны с утверждением что база находится в «правильном» состоянии (мы ведь не будем копировать битую базу).
После завершения создания резервной копии, старую копию можно удалить вместе с архивами. Удаление архивов выполняется с помощью утилиты pg_archivecleanup. Утилита позволяет аккуратно удалить ненужные архивы основываясь на специальных файлах-метках, которые создаются при резервном копировании.
Также немаловажно настроить процедуру проверки резервной копии после её создания. Алгоритм достаточно простой: нужно скопировать базовую копию в некий каталог-песочницу (осторожно, место!), создать в ней минимально необходимые файлы конфигурации необходимые для запуска в режиме восстановления и запустить postgres относительно этого каталога-песочницы, после запуска необходимо проанализировать лог и сделать вывод является ли резервная копия пригодной для восстановления.
Таким образом процесс укладывается в три шага: создание базовой копии, её проверка и удаление старой, предыдущей базовой копии.
Теперь предположим что случилось наихудшее и нужно выполнить восстановление. Нужно остановить основной кластер postgres и переименовать каталог базы данных в произвольное имя. Каталог резервной копии нужно переименовать в каталог кластера базы данных. При необходимости скопировать файлы конфигурации. После определения конфигурационных файлов, запускаем postgres относительно нашего каталога. При запуске, Postgres обнаружит recovery.conf и запустится в режиме восстановления. Остается дождаться пока postgres восстановит свое состояние с помощью архивов, после чего можно будет подключаться к базе данных и продолжить работу. Вот и все, процедура восстановления завершена.
Вот так вот. Держите данные в сохранности! Скрипты для резервного копирования и валидации копий здесь.