WAL-G

https://wal-g.readthedocs.io/

Overview

WAL-G это инструмент для архивации и восстановления PostgreSQL, MySQL/MariaDB, and MS SQL Server (beta for MongoDB and Redis)

Installation

Готовые бинари можно найти тут - https://github.com/wal-g/wal-g/releases

Будем разбирать на примере последнего на текущий момент wal-g для postgres под ubuntu
https://github.com/wal-g/wal-g/releases/download/v2.0.1/wal-g-pg-ubuntu-20.04-amd64

Как можно заметить, имя релиза строится по следующему шаблону wal-g-DBNAME-OSNAME

Screenshot_2021_02_02-12_49_03-2023-06-20-at-17wal-g-releases.png

Если тебе нужен wal-g под другую систему то смотри тут как собрать - https://wal-g.readthedocs.io/#development

Есть autocompletion: wal-g help completion

Итак, качаем бинарь, кладем в /usr/local/bin/wal-g и даем ему права на исполнение

wget https://github.com/wal-g/wal-g/releases/download/v2.0.1/wal-g-pg-ubuntu-20.04-amd64
chmod ug+x wal-g-pg-ubuntu-20.04-amd64
mv wal-g-pg-ubuntu-20.04-amd64 /usr/local/bin/wal-g

Можем считать что установили

Configuration

Есть два способа сконфигурировать wal-g:

  1. Переменные окружения
  2. Конфигурационный файл

Через флаг --config /path можно указать путь до конфига

We support every format that the viper package supports: JSON, YAML, envfile and others.

Every configuration variable mentioned in the following documentation can be specified either as an environment variable or a field in the config file.

Storage

Указывает куда wal-g должен складывать бэкапы. См. https://wal-g.readthedocs.io/STORAGES/

Compression

WALG_COMPRESSION_METHOD - указывает какой метод компрессии использовать для бэкапов. Доступные варианты: lz4, lzma, zstd, brotli

По умолчанию lz4. Потому что это самый быстрый метод, но он имеет плохую степень сжатия. LZMA медленнее, но он сжимает в 6 раз сильнее чем LZ4. Brotli и ZSTD это хороший компромис между сжатием и скоростью, они сжимают в три раза сильнее чем LZ4

Encryption

Monitoring

WALG_STATSD_ADDRESS - позволяет включить паблишинг метрик в statsd или statsd_exporter. Метрики будут засылаться по UDP. Порт по умолчанию - 9125

Profiling

Профилирование позволяет находить узкие места в работе wal-g

Rate limiting

WALG_NETWORK_RATE_LIMIT - задает ограничение трафика для операций backup-push/backup-fetch. Задается в байтах в секунду

Database-specific options

Есть множество db-specific опций, смотри их в https://wal-g.readthedocs.io/#databases

Usage

Следующие команды поддерживаются для всех типов баз данных

Storage tools

Группа команд wal-g st позволяет осуществлять прямое взаимодействие с сконфигурированными стораджами
Подробности в https://wal-g.readthedocs.io/StorageTools

Databases

PostgreSQL

Информация об установке, конфигурации и использовании

MySQL/MariaDB

Информация об установке, конфигурации и использовании

SQLServer

Информация об установке, конфигурации и использовании

Mongo [Beta]

Информация об установке, конфигурации и использовании

FoundationDB [Work in progress]

Информация об установке, конфигурации и использовании

Redis [Beta]

Информация об установке, конфигурации и использовании

Greenplum [Work in progress]

Информация об установке, конфигурации и использовании

Development

О том как собрать из исходников https://wal-g.readthedocs.io/#development

Storages

WAL-G может сохранять бэкапы на S3, Google Cloud Storage, Azure, Swift, удаленный хост (через SSH) или на локальную файловую систему

S3

Чтобы wal-g мог подключиться к amazon s3 должны быть проставлены следующие переменные:

WAL-G определяет aws-креды как и другие aws тулзы. Ты можешь проставить переменные AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY (опционально с AWS_SESSION_TOKEN), или прописать их в файл ~/.aws/credentials (опционально с AWS_PROFILE), или ты можешь не прописывать ничего, тогда креды будут получены от сервиса метаданных

Опциональные переменные:

GCS

https://wal-g.readthedocs.io/STORAGES/#gcs

Azure

https://wal-g.readthedocs.io/STORAGES/#azure

Swift

https://wal-g.readthedocs.io/STORAGES/#swift

File system

Чтобы wal-g сохранял бэкапы на файловую систему, нужно указать переменную WALG_FILE_PREFIX

WALG_FILE_PREFIX=/tmp/wal-g-test-data

SSH

Чтобы wal-g сохранял бэкапы по ssh, нужно указать следующие переменные

WALG_SSH_PREFIX='ssh://localhost/walg-folder'
SSH_PORT
SSH_USERNAME
SSH_PASSWORD
SSH_PRIVATE_KEY_PATH

Storage tools

Серия команд wal-g st позволяет взаимодействовать со стороджами
Помни что потенциально эти команды могут все сломать, поэтому надо быть внимательным и понимать что делаешь

WAL-G for PostgreSQL

Ты можешь использовать wal-g как инструмент для создания зашифрованых и сжатых postgresql бэкапов (полных и инкрементальных) и для push/fetch их на/с удаленных стораджей без необходимости сохранения на свою ФС

Configuration

WAL-G использует обычные постгресовые переменные окружения для настройки подключения, особенно включая PGHOST, PGPORT, PGUSER, и PGPASSWORD/PGPASSFILE/~/.pgpass

PGHOST может подключить по unix-сокету. Этот режим предпочтительный для локальных подключений. Для его использования задай переменную так - PGHOST=/var/run/postgresql
Если в PGHOST указан IP, то wal-g подключится по TCP

Usage

backup-fetch

Чтобы достать базовый бэкап, пользователю нужно указать имя бэкапа и путь куда его распаковать. Если эта директория не существует то wal-g создаст ее и все промежуточные поддиректории

wal-g backup-fetch ~/extract/to/here example-backup

Можно достать последний бэкап вот так

wal-g backup-fetch ~/extract/to/here LATEST

Можно достать бэкап который имеет определенную UserData указав эту юзердату в ключе --target-user-data или в переменной WALG_FETCH_TARGET_USER_DATA

wal-g backup-fetch /path --target-user-data "{ \"x\": [3], \"y\": 4 }"
Reverse delta unpack

Beta feature: WAL-G может распаковывать дельта бэкапы в обратном порядке для увеличения эффективности
Активировать эту функцию можно либо через переменную WALG_USE_REVERSE_UNPACK, либо через флаг --reverse-unpack

Redundant archives skipping

Вместе с включенной функцией обратной распаковки дельт ты также можешь включить пропуск избыточных архивов. Эта функция вовлечена и в процесс создания бэкапа и в процесс его восстановления, чтобы включить это нужно сделать две вещи:

  1. Опционально. Увеличить шанс пропуска архивов, но в результате может замедлиться создание бэкапов. Enable rating tar ball composer for backup-push
  2. Включить пропуск избыточных бэкапов во время backup-fetch (два варианта как):
    1. Проставив переменные WALG_USE_REVERSE_UNPACK и WALG_SKIP_REDUNDANT_TARS
    2. Добавив флаги --reverse-unpack и --skip-redundant-tars
Partial restore (experimental)

Во время частичного восстановления wal-g восстанавливает фалы только определенных баз данных. В качестве параметра используй 'database' или 'database/namespace.table' (схема 'public' может быть опущена)

wal-g backup-fetch /path LATEST --restore-only=my_database,"another database",database/my_table

В этом примере двойные кавычки нужны только для пробела, они будут проигнорированы

Три выражения ниже - эквивалентны:

Для этого требуются файлы с метаданными которые автоматически собираются во время локального бэкапирования (при удаленном бэкапировании это не работает)

Также автоматически восстанавливаются системные бд и таблицы

Потому что остатки невосстановленных бд и таблиц остаются в системных таблицах, поэтому рекомендуется дропать их

Опции --skip-redundant-tars и --reverse-unpack проставляются автоматически

backup-push

Для отгрузки бэкапов на сторадж, пользователь должен указать постгресовую датадиру в качестве аргумента

wal-g backup-push $PGDATA

WAL-G проверит, совпадают ли аргумент команды, переменная окружения PGDATA и параметр конфигурации PGDATA, если они установлены

Если бэкап запущен со standby сервера, то wal-g будет следить за таймлайном сервера. Если промоушен или таймлайн изменится во время бэкапа, то данные будут загружены но не финализированы, и wal-g вывалится с ошибкой. Логи будут содержать информацию необходимую для финализации бэкапа (которая может быть использована если ты четко понимаешь все риски)
backup-push может быть также запущен с флагом --permanent, который пометит бэкап как перманентный и убережет его от удаления при запуске команды delete

Remote backup

WAL-G backup-push имеет два варианта стриминга данных:

  1. Запуск прямо на сервере с БД под пользователем постгреса - wal-g может читать файлы базы данных прямо с файловой системы. Этот вариант дает высокую производительность и дополнительные возможности, такие как частичное восстановление или дельта бэкапы

For uploading backups to S3 using streaming option 1, the user should pass in the path containing the backup started by Postgres as in:
bash wal-g backup-push /backup/directory/path

  1. Альтернативно wal-g может стримить бэкапные данные через postgres'овый BASE_BACKUP протокол
    Это позволяет wal-g стримить бэкапы по TCP, быть запущенным удаленно и быть запущенным из под другого пользователя. Wal-g требуется подключение с правом репликации (в статье про base backup это описано). Помни что протокол BASE_BACKUP не умеет в мультитрединг и дельта бэкапы пока не имплементированы

Чтобы завести эту схему, надо покинуть data dir постгри и указать хостнейм постгрес сервера (через env var PGHOST или аргумент параметра --pghost)

# Inline
PGHOST=srv1 wal-g backup-push
# Export
export PGHOST=srv1 wal-g backup-push
# Use commandline option
wal-g backup-push --pghost srv1

Опции удаленного бэкапирования также могут быть использованы для:

Rating composer mode

В режиме составителя рэйтинга (?) wal-g во время бэкапа кладет файлы с одинаковой частотой обновления в общие тарболы. Это должно увеличить эффективность пропуска избыточных архивов backup-fetch'а. Будь осторожен, хоть этот режим и позволяет сохранить больше данных, в итоге он может замедлить создание бэкапа по сравнение с дефолтным сборщиком тарболов

Для активации этой фичи сделай одно из:

wal-g backup-push /path --rating-composer
Copy composer mode

В режиме copy composer, wal-g делает полный бэкап и копирует неизмененные тар-файлы из предыдущего полного бэкапа. В случае если нет предыдущего полного бэкапа будет задействован regular composer

Чтобы активировать эту фичу сделай одно из:

wal-g backup-push /path --copy-composer
Database composer mode

В этом режиме wal-g отделяет файлы из разных директорий внутри дефолтного tablespace и пакует их в разные тарболы. Это создано для увеличения перфоманса частичного восстановления
Чтобы активировать эту фичу сделай одно из:

wal-g backup-push /path --database-composer
Backup without metadata

По умолчанию wal-g отслеживает метаданные забэкапленных файлов. Если забэкаплено миллионы файлов (типичный кейс сотен бд и тысяч таблиц в каждой бд), то трекинг этих метаданных потребует гигабайты памяти

Если выставлен флаг --without-files-metadata или переменная WALG_WITHOUT_FILES_METADATA, то wal-g не будет трэкать метаданные забэкапленных файлов. Это значительно уменьшит потребление памяти на инстансе с более чем 100к файлов

Ограничения:

Чтобы активировать эту фичу сделай одно из:

wal-g backup-push /path --without-files-metadata
Create delta backup from specific backup

При создании дельта бэкапа (WALG_DELTA_MAX_STEPS > 0), wal-g по умолчанию использует последний бэкап как базовый. Это поведение может быть изменено с помощью следующих флагов:

wal-g backup-push /path --delta-from-name base_000000010000000100000072_D_000000010000000100000063
wal-g backup-push /path --delta-from-user-data "{ \"x\": [3], \"y\": 4 }"

Если использовать флаг выше в комбинации с WALG_DELTA_ORIGIN, то его логика будет применяться к указанному бэкапу

list of backups in storage:
base_000000010000000100000040  # full backup
base_000000010000000100000046_D_000000010000000100000040  # 1st delta
base_000000010000000100000061_D_000000010000000100000046  # 2nd delta
base_000000010000000100000070  # full backup

export WALG_DELTA_ORIGIN=LATEST_FULL
wal-g backup-push /path --delta-from-name base_000000010000000100000046_D_000000010000000100000040

wal-g logs:
INFO: Selecting the backup with name base_000000010000000100000046_D_000000010000000100000040 as the base for the current delta backup...
INFO: Delta will be made from full backup.
INFO: Delta backup from base_000000010000000100000040 with LSN 140000060.
Page checksums verification

Чтобы включить верификацию страничных чексумм по время backup-push, используй флаг --verify или переменную WALG_VERIFY_PAGE_CHECKSUMS. Если будут найдены, то кол-во поврежденных блоков будет записано в sentinel json

...
"/base/13690/13535": {
"IsSkipped": true,
"MTime": "2020-08-20T21:02:56.690095409+05:00",
"IsIncremented": false
},
"/base/16384/16397": {
"CorruptBlocks": [
1
],
"IsIncremented": false,
"IsSkipped": false,
"MTime": "2020-08-21T19:09:52.966149937+05:00"
},
...

wal-fetch

Когда качается wal архив из s3, пользователь должен указать имя архива и имя файла в который надо скачать архив. Этот файл не должен существовать так как wal-g создаст его для тебя

Wal-g предзакачивает wal файлы наперед относительно тех которые запрошены. Эти файлы кэшируются в папку ./.wal-g/prefetch. Закэшированные файлы старше чем последний запрошенный удаляются из кэша для предотвращения разбухания кэша. Если закэшированный файл запрошен через wal-fetch, он будет удален из кэша и будет дернут триггер на скачивание нового

wal-g wal-fetch example-archive new-file-name

Эта команда создана для выполнения из постгресового restore_command

Отметим что wal-fetch будет вылетать с экзиткодом 74 (EX_IOERR: input/output error, ...) если wal файл не доступен в репозитории. Все остальные ошибки приводят к exit code 1, и должны останавливать postgres раньше чем завершается восстановление. Для постгреса это может быть любой код ошибки между 126 и 255, которые могут быть получены через простой скрипт-обертку. См. PR - https://github.com/wal-g/wal-g/pull/1195 (судя по PR это говно уже пофикшено)

wal-push

Для отгрузки вал архивов в S3 пользователь должен указать абсолютный путь до архива

wal-g wal-push /path/to/archive

Эта команда создана для выполнения из постгресовой archive_command

wal-show

Показывает инфу о каталоге хранения wal'ов. Она показывает все таймлайны вол-сегментов доступных в сторадже, отображает доступные бэкапы для них и проверяет их на потерянные сегменты

wal-g wal-show

По умолчанию wal-show показывает доступные бэкапы для каждого таймлайна. Чтобы выключить это поведение добавь флаг --without-backups

По умолчанию выводится таблица, чтобы вывести подробный json, добавь флаг --detailed-json

wal-verify

Запускает серию проверок чтобы убедиться что сторадж wal-сегментов здоров. Доступные проверки:

integrity

Проверка того что история wal-сегментов консистентна для кластера и значит wal-g сможет выполнить PITR для бэкапа. В основном это проверки того что все wal-сегменты в диапазоне [oldest backup start segment, current cluster segment) доступны в сторадже. Если бэкапов не найдено то будет отсканирован диапазон [1, current cluster segment)

Screenshot_2021_02_02-12_49_03-2023-06-26-at-00walghealthcheck.png

В выводе integrity проверки есть 4 статуса:

Размер диапазона сегментов ProbablyUploading берется из настройки WALG_UPLOAD_CONCURRENCY
Размер диапазона сегментов ProbablyDelayed контролируется настройкой WALG_INTEGRITY_MAX_DELAYED_WALS

Вывод содержит:

  1. Статус integrity проверки:
    • OK - нет пропущенных сегментов
    • WARNING - есть несколько пропущенных сегментов но они не MISSING_LOST
    • FAILURE - есть несколько MISSING_LOST сегментов
  2. Список сегментов в хронологическом порядке сгруппированных по таймлайнам и статусам
timeline

Проверка что текущий таймлайн кластера больше чем или равен какому-либо таймлайну в сторадже
Эта проверка полезна для обнаружения split-brain конфликтов
Обрати внимание что эта проверка будет работать корректно только если создан новый сторадж или старый очищен после восстановления из бэкапа или применения pg_upgrade

Вывод содержит:

  1. Статус timeline проверки:
    • OK - текущий timeline-id матчится с наивысшим таймлайном в сторадже
    • WARNING - не получается определить что текущий таймлайн матичится с наивысшим в сторадже
    • FAILURE - текущий timeline-id не равен наивысшему таймлайну в сторадже
  2. Текущий таймлайн айди
  3. Наивысший таймлайн айди найденный в сторадже

Пример

wal-g wal-verify [space separated list of checks]
# For example:
wal-g wal-verify integrity timeline # perform integrity and timeline checks
wal-g wal-verify integrity # perform only integrity check

По умолчанию вывод wal-verify это плейнтекст. Чтобы переключить на json добавь флаг --json

Пример обычного вывода:

[wal-verify] integrity check status: OK
[wal-verify] integrity check details:
+-----+--------------------------+--------------------------+----------------+--------+
| TLI | START                    | END                      | SEGMENTS COUNT | STATUS |
+-----+--------------------------+--------------------------+----------------+--------+
|   3 | 00000003000000030000004D | 0000000300000004000000F0 |            420 |  FOUND |
|   4 | 0000000400000004000000F1 | 000000040000000800000034 |            836 |  FOUND |
+-----+--------------------------+--------------------------+----------------+--------+
[wal-verify] timeline check status: OK
[wal-verify] timeline check details:
Highest timeline found in storage: 4
Current cluster timeline: 4

Пример json вывода:

{
   "integrity":{
      "status":"OK",
      "details":[
         {
            "timeline_id":3,
            "start_segment":"00000003000000030000004D",
            "end_segment":"0000000300000004000000F0",
            "segments_count":420,
            "status":"FOUND"
         },
         {
            "timeline_id":4,
            "start_segment":"0000000400000004000000F1",
            "end_segment":"000000040000000800000034",
            "segments_count":836,
            "status":"FOUND"
         }
      ]
   },
   "timeline":{
      "status":"OK",
      "details":{
         "current_timeline_id":4,
         "highest_storage_timeline_id":4
      }
   }
}

wal-receive

Получает wal поток используя postgresql streaming replication и пушит это в сторадж

Ты можешь указать имя слота репликации в переменной WALG_SLOTNAME (по умолчанию walg). Имя слота может содержать только цифры буквы и подчеркивания. Для загрузки wal в s3 пользователь должен указать полный путь до архива

backup-mark

Бэкапы могут быть помечены как постоянные (permanent) для предотвращения удаления их при запуске команды delete. Постоянность бэкапа может быть изменена через эту команду. Нужно скормить сюда имя бэкапа (получить его можно из вывода wal-g backup-list --pretty --detail --json), и тогда он и предыдущие связанные с ним бэкапы будут помечены как постоянные. Обратное действие доступно через флаг -i

catchup-push

Чтобы создать догонный инкрементальный бэкап, пользователь должен указать путь до постгресовой диры на мастере и LSN реплики для которой делается бэкап

Пошагово:

  1. Остановка реплики
  2. Получение LSN реплики
  3. Начало загрузки инкрементального бэкапа на мастере
wal-g catchup-push /path/to/master/postgres --from-lsn replica_lsn

catchup-fetch

Чтобы провернуть догон инкрементальным бэкапом сделанным через catchup-push, пользователю нужно указать путь до постгреса на реплике и имя бэкапа

wal-g catchup-fetch /path/to/replica/postgres backup_name

copy

Эта команда поможет изменить сторадж и перенести туда набор бэкапов или записать бэкапы на магнитную ленту
Например: wal-g copy --from=config_from.json --to=config_to.json - скопирует все бэкапы
Флаги:

delete garbage

Удаляет просроченные wal архивы и остаточные файлы бэкапов на сторадже (неуспешные бэкапы или частично удаленные). Удалит все неперманентные объекты до самого раннего неперманентного бэкапа. Эта команда полезна когда бэкапы были удалены через delete target

wal-g delete garbage           # Deletes outdated WAL archives and leftover backups files from storage
wal-g delete garbage ARCHIVES      # Deletes only outdated WAL archives from storage
wal-g delete garbage BACKUPS       # Deletes only leftover (partially deleted or unsuccessful) backups files from storage

The garbage target can be used in addition to the other targets, which are common for all storages

wal-restore

Восстанавливает потеряные wal-сегменты которые будут необходимы для выполнения pg_rewind из стораджа. Текущая версия поддерживает только локальные кластеры

wal-g wal-restore path/to/target-pgdata path/to/source-pgdata

daemon

Архивировать и стягивать все wal-сегменты в фоне. Работает с PostgreSQL archive library walg_archive или walg-daemon-client

wal-g daemon path/to/socket-descriptor

pgBackRest backups support (beta version)

https://wal-g.readthedocs.io/PostgreSQL/#pgbackrest-backups-support-beta-version

Failover archive storages (experimental)

https://wal-g.readthedocs.io/PostgreSQL/#failover-archive-storages-experimental

Playground

Ты можешь протестить wal-g в с помощью этого playground