Непрерывное архивирование и восстановление на определенный момент времени

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.

Обратите внимание, что резервные копии можно использовать двумя способами для восстановления узлов.

  1. Добавление новой ноды в качестве реплики (уже описано в моей статье).
  2. Добавление нового узла как отдельного для тестирования производительности и т. д. (тема этого поста).

Поскольку это автономный узел, настройка будет простой. Один узел загружает резервные копии с 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?

Использование отдельной базы данных для каждого модульного теста

Ознакомьтесь с моими бесплатными шаблонами понятий.