Непрерывное архивирование и восстановление на определенный момент времени
PostgreSQL — восстановление узла из резервных копий, хранящихся в облаке AWS
В моем предыдущем посте мы уже рассмотрели основные концепции и общий обзор архитектуры управления резервным копированием.
Этот пост посвящен восстановлению узла из резервных копий, хранящихся в облаке AWS, с помощью spilo.
In this post, you will learn: - Configuration settings required by spilo for resstoring a (standalone) node. - How to restore a node at specific point-in-time as opposed to latest backups.
Обратите внимание, что резервные копии можно использовать двумя способами для восстановления узлов.
- Добавление новой ноды в качестве реплики (уже описано в моей статье).
- Добавление нового узла как отдельного для тестирования производительности и т. д. (тема этого поста).
Поскольку это автономный узел, настройка будет простой. Один узел загружает резервные копии с AWS S3, как показано на рисунке ниже.
Давайте посмотрим на конфигурации, необходимые для восстановления узла из резервных копий с помощью spilo.
Spilo supports wal-e and wal-g for managing backups, however, we use wal-g for restoring a node because wal-e is already obsolete. version: '3.0' services: restore-node-from-backup: image: registry.opensource.zalan.do/acid/spilo-14:2.1-p7 hostname: node-3 container_name: node-3 ports: # Port 2379-2380 etcd # Port 5432 Postgres # Port 8008 Patroni - "2379:2379" - "2380:2380" - "5432:5432" - "8008:8008" # Please use volume as opposed to tmpfs for production system. # !!! WHEN YOU USE VOLUME !!! # Ensure these volumes have correct permission. # id of postgres user used inside the container (id -u postgres) => 101 # group of postgres user used inside the container (id -g postgres) => 103 # 101 & 103 both belongs to postgres user & group # chown 101:103 your-directory-here tmpfs: /home/postgres/pgdata environment: SCOPE: '<YOUR-CLUSTER-NAME>' PGVERSION: 13 USE_ADMIN: 'false' # A password for the superuser. # Please use the same password as that of the one used while backing up. PGPASSWORD_SUPERUSER: '<PASSWORD_HERE>' CLONE_WAL_S3_BUCKET: '<BUCKET_NAME_HERE>' CLONE_WALE_S3_PREFIX: 's3://<BUCKET_NAME_HERE>/<BUCKET_OBJECT_HERE>/' CLONE_WALE_S3_ENDPOINT: 'https+path://s3.AWS_REGION.amazonaws.com:443' CLONE_AWS_REGION: '<AWS_REGION>' CLONE_AWS_ENDPOINT: 'https://s3.AWS_REGION.amazonaws.com/' # Conditional parameters CLONE_AWS_ACCESS_KEY_ID & CLONE_AWS_SECRET_ACCESS_KEY # Only relevant when you are running it locally. # On AWS cloud, you don't need to specify it. IAM profile takes care of it. CLONE_AWS_ACCESS_KEY_ID: '<AWS_ACCESS_KEY_ID>' CLONE_AWS_SECRET_ACCESS_KEY: '<AWS_SECRET_ACCESS_KEY>' CLONE_USE_WALG_RESTORE: 'true' # Even though we are cloning but spilo need this env variable to be true. # Otherwise, it fails to detect correct AWS region. CLONE_USE_WALG_BACKUP: 'true' CLONE_WALG_DOWNLOAD_CONCURRENCY: 10 # Please note that our system uses wal-g. So, using "CLONE_WITH_WALE" # does not mean that it uses wal-e. It is still using wal-g. CLONE_METHOD: 'CLONE_WITH_WALE'
Spilo будет использовать те же переменные среды, но теперь они имеют префикс CLONE_
.
Поскольку узел восстанавливается из резервных копий, ему потребуются права только на чтение для данной корзины AWS S3.
- s3:GetObject - s3:ListBucket
Восстановление узла с использованием определенной метки времени
Чтобы восстановить узел с определенной отметкой времени, нам нужно применить базовые резервные копии, а затем резервные копии журнала с упреждающей записью (WAL). Я очень хорошо объяснил эту концепцию в своем предыдущем посте на эту тему.
Предположим, что в облаке AWS хранятся следующие резервные копии.
| **Timestamp** | **Base backups** | **WAL backups** | |--------------- |------------------ |----------------- | | t1 | base-backup-t1 | | | t2 | | wal-backup-t2 | | t3 | | wal-backup-t3 | | t4 | base-backup-t4 | | | t5 | | wal-backup-t5 | | t6 | base-backup-t6 | | | t7 | | wal-backup-t7 | where t1 is the oldest timestamp t7 is the newest timestamp
И мы хотели бы восстановить узел до метки времени t3
. Возможно ли это? Да.
Для этого нам нужно использовать следующую настройку.
# Set the time stamp up to which recovery will proceed. # Please specify it as `YYYY-mm-dd HH:mm:ss+00:00`. # # It's important to specify timezone. You can read more on this topic here [1] # [1] https://postgresqlco.nf/doc/en/param/recovery_target_time/ CLONE_TARGET_TIME: '<timestamp-with-timezone>'
Если мы укажем временную метку t3
в приведенной выше конфигурации, она восстановит узел следующим образом.
- база-резервная копия-t1
- wal-резервное копирование-t2
- wal-резервное копирование-t3
Если указана временная метка t5
, восстановление будет выполнено с использованием следующих резервных копий:
- база резервного копирования-t4
- wal-резервное копирование-t5
Я пытаюсь подчеркнуть, что он всегда будет использовать последнюю базовую резервную копию для заданной временной метки, а затем применять WAL (инкрементные) резервные копии до заданной временной метки.
Please ignore the above setting if you want to recover from the latest backup.
Репозиторий: https://github.com/anasanjaria/postgresql-backup-management
Спасибо за прочтение. Если у вас есть какие-либо вопросы, пожалуйста, дайте мне знать.
Если вам понравился этот пост, вам также может понравиться следующий.
Чему я научился у Docker Networking?
Использование отдельной базы данных для каждого модульного теста
Ознакомьтесь с моими бесплатными шаблонами понятий.