wal-g#

wal-g

wal-g
Назад	Наверх	G.1. Клиентские приложения	Начало	Далее

wal-g

wal-g — инструмент для восстановления архивных данных в PostgreSQL

WAL-G

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

WAL-G является преемником WAL-E с рядом ключевых отличий. WAL-G использует сжатие LZ4, LZMA, ZSTD или Brotli, несколько процессоров и неэксклюзивные базовые резервные копии для Postgres. Более подробную информацию о первоначальной разработке и реализации WAL-G можно найти в блоге Citus Data «Представляем WAL-G от Citus: более быстрое восстановление после сбоев для Postgres».

О wal-g

Версия: 3.0.3

GitHub

Конфигурация

Существует два способа настройки WAL-G:

Использование переменных окружения
Использование файла конфигурации
--config /path флаг может быть использован для указания пути, где находится файл конфигурации.
Мы поддерживаем все форматы, которые поддерживает пакет viper: JSON, YAML, envfile и другие.

Каждая переменная конфигурации, упомянутая в следующей документации, может быть указана либо как переменная окружения, либо как поле в файле конфигурации.

Сжатие

WALG_COMPRESSION_METHOD

Для настройки метода сжатия, используемого для резервных копий. Возможные варианты: lz4, lzma, zstd, brotli. Метод по умолчанию lz4. LZ4 является самым быстрым методом, но коэффициент сжатия у него плохой. LZMA значительно медленнее. Однако, он сжимает резервные копии примерно в 6 раз лучше, чем LZ4. Brotli и zstd являются хорошим компромиссом между скоростью и коэффициентом сжатия, который примерно в 3 раза лучше, чем у LZ4.

Шифрование

YC_CSE_KMS_KEY_ID

Чтобы настроить ключ Yandex Cloud KMS для шифрования и дешифрования на стороне клиента. По умолчанию шифрование не используется.

YC_SERVICE_ACCOUNT_KEY_FILE

Для настройки имени файла, содержащего закрытый ключ учетной записи сервиса Yandex Cloud. Если не задано, будет использоваться токен из службы метаданных (http://169.254.169.254) для выполнения API-запросов к Yandex Cloud KMS.

WALG_LIBSODIUM_KEY

Чтобы настроить шифрование и дешифрование с помощью libsodium. WAL-G использует алгоритм, который требует только секретный ключ. Ключи libsodium имеют фиксированный размер 32 байта. Для оптимальной криптографической безопасности рекомендуется использовать случайный 32-байтовый ключ. Чтобы сгенерировать случайный ключ, вы можете использовать что-то вроде openssl rand -hex 32 (установите WALG_LIBSODIUM_KEY_TRANSFORM в hex) или openssl rand -base64 32 (установите WALG_LIBSODIUM_KEY_TRANSFORM в base64).

WALG_LIBSODIUM_KEY_PATH

Похоже на WALG_LIBSODIUM_KEY, но значение является путем к ключу в файловой системе. Содержимое файла будет очищено от пробельных символов.

WALG_LIBSODIUM_KEY_TRANSFORM

Преобразование, которое будет применено к WALG_LIBSODIUM_KEY для получения необходимого 32-байтного ключа. Поддерживаемые преобразования: base64, hex или none (по умолчанию). Опция none существует для обратной совместимости, ввод пользователя будет преобразован в 32 байта либо путем усечения, либо путем дополнения нулями.

WALG_GPG_KEY_ID (альтернативная форма WALE_GPG_KEY_ID) ⚠️ УСТАРЕЛО

Чтобы настроить ключ GPG для шифрования и дешифрования. По умолчанию шифрование не используется. Открытое кольцо ключей кэшируется в файле “/.walg_key_cache”.

WALG_PGP_KEY

Чтобы настроить шифрование и дешифрование по стандарту OpenPGP. Вы можете объединить многострочный ключ, используя символы \n в одну строку (в основном используется в случае daemontools и envdir). Установите значение закрытого ключа, когда вам нужно выполнить команду wal-fetch или backup-fetch. Установите значение открытого ключа, когда вам нужно выполнить команду wal-push или backup-push. Имейте в виду, что закрытый ключ также содержит открытый ключ.

WALG_PGP_KEY_PATH

Похоже на WALG_PGP_KEY, но значение - это путь к ключу в файловой системе.

WALG_PGP_KEY_PASSPHRASE

Если ваш закрытый ключ зашифрован с помощью парольной фразы, вам следует установить парольную фразу для расшифровки.

WALG_ENVELOPE_PGP_KEY Для настройки шифрования и дешифрования с использованием конвертного PGP-ключа, хранящегося в системе управления ключами. Этот параметр позволяет безопасно управлять вашими PGP-ключами, храня их в KMS. Важно убедиться, что передаваемый ключ зашифрован с использованием KMS и закодирован с помощью base64. Также обе частные и публичные части должны присутствовать в ключе, потому что конвертный ключ будет внедрен в метаданные и использован позже в wal/backup-fetch.

Пожалуйста, обратите внимание, что в настоящее время для настройки поддерживается только Yandex Cloud Key Management Service (KMS). Убедитесь, что вы настроили и сконфигурировали Yandex Cloud KMS, упомянутый ниже, перед попыткой использовать эту функцию.

WALG_ENVELOPE_CACHE_EXPIRATION

Этот параметр управляет сроком действия ответа kms. Значение по умолчанию - 0, чтобы хранить ключи постоянно в памяти. Пожалуйста, обратите внимание, что если система не сможет повторно расшифровать ключ в kms после истечения срока действия, будет использован предыдущий ответ.

WALG_ENVELOPE_PGP_YC_ENDPOINT

Конечная точка - это конечная точка API Yandex.Cloud, против которой используется SDK. Большинству пользователей не нужно явно задавать её.

WALG_ENVELOPE_PGP_YC_CSE_KMS_KEY_ID

Похоже на YC_CSE_KMS_KEY_ID, но используется только для конвертированных pgp ключей.

WALG_ENVELOPE_PGP_YC_SERVICE_ACCOUNT_KEY_FILE

Похоже на YC_SERVICE_ACCOUNT_KEY_FILE, но используется только для конвертированных pgp ключей.

WALG_ENVELOPE_PGP_KEY_PATH

Похоже на WALG_ENVELOPE_PGP_KEY, но значение является путем к ключу в файловой системе.

Мониторинг

WALG_STATSD_ADDRESS

Чтобы включить публикацию метрик в statsd или statsd_exporter. Метрики будут отправляться по принципу наилучших усилий через UDP. Порт по умолчанию для statsd — 8125.

WALG_STATSD_EXTRA_TAGS

Используйте этот параметр для добавления статических тегов (host, operation, database и т.д.) к метрикам, которые WAL-G публикует в statsd.

Если вы хотите создать демонстрацию для тестирования, вы можете использовать сервис graphite из файла docker-compose.

Профилирование

Профилирование полезно для выявления узких мест в WAL-G.

PROFILE_SAMPLING_RATIO

Значение с плавающей запятой между 0 и 1, определяет вероятность включения профилировщика. При установке в 1, он будет всегда работать. Это позволяет выполнять вероятностное выборочное профилирование вызовов. Поскольку процессы WAL-G могут создаваться несколько раз в секунду (например, wal-g wal-push), мы не хотим профилировать все из них.

PROFILE_MODE

Тип профайлера pprof для использования. Может быть одним из cpu, mem, mutex, block, threadcreation, trace, goroutine. См. документацию runtime/pprof для получения дополнительной информации. По умолчанию cpu.

PROFILE_PATH

Каталог для хранения профилей. По умолчанию $TMPDIR.

Ограничение скорости

WALG_NETWORK_RATE_LIMIT

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

Использование

WAL-G в настоящее время поддерживает эти команды для всех типов баз данных:

`backup-list`

Список имен и времени создания доступных резервных копий.

--pretty флаг выводит список в таблице

--json флаг выводит список в формате JSON, красиво отформатированный, если используется с --pretty

--detail флаг выводит дополнительные детали резервного копирования, красиво отформатированные, если используется с --pretty, закодированные в json, если используется с --json

`delete`

Используется для удаления резервных копий и WAL перед ними. По умолчанию, delete выполнит пробный запуск. Если вы хотите выполнить удаление, вам нужно добавить флаг --confirm в конце команды. Резервные копии, помеченные как постоянные, не будут удалены.

delete может работать в четырех режимах: retain, before, everything и target.

retain [FULL|FIND_FULL] %number% [--after %name|time%]

Если указано FULL, сохраняется %number% полных резервных копий и все промежуточные. Если используется флаг --after, сохраняется number самых последних резервных копий и резервные копии, сделанные после %name|time% (включительно).

before [FIND_FULL] %name%

Если указано FIND_FULL, WAL-G рассчитает минимальную резервную копию, необходимую для сохранения всех дельт. Если FIND_FULL не указано, и вызов может привести к появлению осиротевших дельт, вызов завершится с ошибкой и списком.

everything [FORCE]

target [FIND_FULL] %name% | --target-user-data %data% удалит резервную копию, указанную по имени или пользовательским данным. В отличие от других команд удаления, эта команда не удаляет архивированные WAL.

(Только в Postgres & MySQL) По умолчанию, если в качестве цели указан delta backup, WAL-G также удалит все зависимые delta backups. Если указано FIND_FULL, WAL-G удалит все резервные копии с той же базовой резервной копией, что и цель.

Примеры

everything все резервные копии будут удалены (если нет постоянных резервных копий)

everything FORCE все резервные копии, включая постоянные, будут удалены

retain 5 завершится неудачей, если 5-й является дельтой

retain FULL 5 будет хранить 5 полных резервных копий и все их дельты

retain FIND_FULL 5 найдет необходимое полное для 5-го и сохранит все после этого

retain 5 --after 2019-12-12T12:12:12 сохранить 5 самых последних резервных копий и резервные копии, сделанные после 2019-12-12 12:12:12

before base_000010000123123123 завершится ошибкой, если base_000010000123123123 является дельтой

before FIND_FULL base_000010000123123123 будет сохранять все после базы base_000010000123123123

target base_0000000100000000000000C9 удалит базовую резервную копию и все зависимые дельта-резервные копии

target --target-user-data "{ \"x\": [3], \"y\": 4 }" удалит резервную копию, указанную пользовательскими данными

target base_0000000100000000000000C9_D_0000000100000000000000C4 удалит дельта-резервную копию и все зависимые дельта-резервные копии

target FIND_FULL base_0000000100000000000000C9_D_0000000100000000000000C4 удалит дельта-резервную копию и все дельта-резервные копии с той же базовой резервной копией

Разработка

Дополнительно:

Чтобы собрать с компрессором и декомпрессором brotli, установите переменную окружения USE_BROTLI.
Чтобы собрать с libsodium, установите переменную среды USE_LIBSODIUM.
Чтобы собрать с декомпрессором lzo, установите переменную окружения USE_LZO.

Ubuntu

# Install latest Go compiler
sudo add-apt-repository ppa:longsleep/golang-backports 
sudo apt update
sudo apt install golang-go

# Install lib dependencies
sudo apt install libbrotli-dev liblzo2-dev libsodium-dev curl cmake

# Fetch project and build
# Go 1.15 and below
go get github.com/wal-g/wal-g
# Go 1.16+ - just clone repository to $GOPATH
# if you want to save space add --depth=1 or --single-branch
git clone https://github.com/wal-g/wal-g $(go env GOPATH)/src/github.com/wal-g/wal-g

cd $(go env GOPATH)/src/github.com/wal-g/wal-g

# optional exports (see above)
export USE_BROTLI=1
export USE_LIBSODIUM=1
export USE_LZO=1

make deps
make pg_build
main/pg/wal-g --version

Пользователи также могут установить WAL-G, используя make pg_install. Указание переменной среды GOBIN перед установкой позволяет пользователю указать место установки. По умолчанию, make pg_install помещает скомпилированный бинарный файл в корневой каталог (/).

export USE_BROTLI=1
export USE_LIBSODIUM=1
export USE_LZO=1
make pg_clean
make deps
GOBIN=/usr/local/bin make pg_install

macOS

# brew command is Homebrew for Mac OS
brew install cmake

# Fetch project and build
# Go 1.15 and below
go get github.com/wal-g/wal-g
# Go 1.16+ - just clone repository to $GOPATH
# if you want to save space add --depth=1 or --single-branch
git clone https://github.com/wal-g/wal-g $(go env GOPATH)/src/github.com/wal-g/wal-g

cd $(go env GOPATH)/src/github.com/wal-g/wal-g

export USE_BROTLI=1
export USE_LIBSODIUM="true" # since we're linking libsodium later
./link_brotli.sh
./link_libsodium.sh
make install_and_build_pg

# if you need to install
GOBIN=/usr/local/bin make pg_install

Чтобы собрать на ARM64, установите соответствующие переменные окружения GOOS/GOARCH:

env GOOS=darwin GOARCH=arm64 make install_and_build_pg

Скомпилированный бинарный файл для запуска - main/pg/wal-g

Устранение неполадок

Хороший способ начать устранение проблем - установить одну или обе эти переменные окружения:

WALG_LOG_LEVEL=DEVEL

Выводит используемую конфигурацию WAL-G и подробные журналы используемой команды.

S3_LOG_LEVEL=DEVEL

Если ваши команды, кажется, застряли, это может быть связано с тем, что S3 недоступен, проблемы с сертификатом или другие проблемы, связанные с S3. С установленной этой переменной окружения вы можете видеть Запросы и Ответы от S3.

Авторы

См. также список участников, которые приняли участие в этом проекте.

Благодарности

WAL-G не появился бы без поддержки Citus Data

WAL-G появился в результате сотрудничества между летним инженерным стажером в Citus, Кэти Ли, и Даниэлем Фариной, оригинальным автором WAL-E, который в настоящее время работает ведущим инженером в команде Citus Cloud. Citus Data также имеет расширение с открытым исходным кодом для Postgres, которое распределяет запросы к базе данных по горизонтали для обеспечения масштабируемости и производительности.

Разработка WAL-G поддерживается Yandex Cloud

Чат

У нас есть группа в Slack и чат в Telegram для обсуждения использования и разработки WAL-G. Чтобы присоединиться к Slack PostgreSQL, используйте приложение для приглашений .

Инструменты хранения (опасная зона)

wal-g st серия команд позволяет взаимодействовать с настроенным хранилищем. Имейте в виду, что эти команды могут выполнять потенциально опасные операции, и убедитесь, что вы знаете, что делаете.

`ls`

Выводит список объектов в указанной папке хранения.

wal-g st ls получить список всех объектов и папок в настроенном хранилище.

wal-g st ls -r получить рекурсивный список со всеми объектами в настроенном хранилище.

wal-g st ls some_folder/some_subfolder получить список всех объектов в указанном пути хранения.

`get`

Загрузите указанный объект хранения. По умолчанию команда попытается применить декомпрессию и расшифровку (если настроено).

Флаги:

Добавьте --no-decompress, чтобы загрузить удаленный объект без декомпрессии
Добавьте --no-decrypt, чтобы загрузить удаленный объект без расшифровки

Примеры:

wal-g st get path/to/remote_file path/to/local_file загрузить файл из хранилища.

wal-g st get path/to/remote_file path/to/local_file --no-decrypt загрузить файл из хранилища без расшифровки.

`cat`

Показать указанный объект хранения на STDOUT. По умолчанию команда НЕ будет пытаться его декомпрессировать и расшифровывать. Полезно для получения сигнальных и других метаинформационных файлов.

Флаги:

Добавьте --decompress для распаковки исходного файла
Добавьте --decrypt, чтобы расшифровать исходный файл

Примеры:

wal-g st cat path/to/remote_file.json показать remote_file.json

`rm`

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

Примеры:

wal-g st rm path/to/remote_file удаляет файл из хранилища.

wal-g st rm path/to/remote_file_or_directory удаляет файл или все файлы в каталоге.

wal-g st rm path/to/remote_directory/ явно укажите, что путь указывает на каталог, а не на файл.

`put`

Загрузите указанный файл в хранилище. По умолчанию команда попытается применить сжатие и шифрование (если настроено).

Флаги:

Добавьте --no-compress, чтобы загрузить объект без сжатия
Добавьте --no-encrypt, чтобы загрузить объект без шифрования

Пример:

wal-g st put path/to/local_file path/to/remote_file загрузить локальный файл в хранилище.

`transfer`

Перенос файлов из одного настроенного хранилища в другое. Обычно используется для перемещения файлов из резервного хранилища в основное, когда оно становится доступным.

Подкоманды:

transfer files prefix - перемещает произвольные файлы без какого-либо специального обращения.
Аргумент prefix является путем к каталогу в обоих хранилищах, куда файлы должны быть перемещены/извлечены. Файлы из всех подкаталогов также перемещаются.
transfer pg-wals - перемещает только файлы WAL PostgreSQL (просто псевдоним для transfer files "wal_005/").
transfer backups [--max-backups=N] - последовательно перемещает резервные копии.
Чтобы предотвратить любые проблемы с восстановлением из частично загруженного/удаленного резервного копирования, файл сигнала *_backup_stop_sentinel.json перемещается в исходное хранилище последним и удаляется из целевого хранилища первым.
Поддерживается дополнительный флаг: --max-backups указывает максимальное количество резервных копий для перемещения в этом запуске.

Флаги (поддерживаются в каждой подкоманде):

Добавьте -s (--source), чтобы указать имя исходного хранилища, из которого будут взяты файлы. Чтобы указать основное хранилище, используйте default. Этот флаг обязателен.
Добавьте -t (--target), чтобы указать имя целевого хранилища для сохранения файлов. По умолчанию используется основное хранилище.
Добавьте -o (--overwrite), чтобы перемещать файлы и перезаписывать их, даже если они уже существуют в целевом хранилище.
Файлы, существующие в обоих хранилищах, останутся без изменений, если этот флаг не указан.
Пожалуйста, обратите внимание, что файлы проверяются на их существование в целевом хранилище только один раз в самом начале. Поэтому, если новый файл появится в целевом хранилище во время выполнения команды, он может быть перезаписан, даже если --overwrite не указан.
Добавьте --fail-fast, чтобы команда остановилась после первой ошибки при передаче любого файла.
Без этого флага команда попытается переместить каждый файл.
Независимо от флага, команда завершится с нулевым кодом ошибки только в том случае, если все файлы были успешно перемещены.
Имейте в виду, что файлы не передаются атомарно. Это означает, что когда этот флаг установлен, ошибка с одним файлом может прервать передачу других файлов в середине, так что они могут быть уже скопированы на целевое хранилище, но еще не удалены из источника.
Добавьте -c (--concurrency), чтобы установить максимальное количество параллельных рабочих процессов, которые будут перемещать файлы.
Добавьте -m (--max-files), чтобы установить максимальное количество файлов для перемещения за один запуск команды.
Добавьте --appearance-checks, чтобы установить максимальное количество проверок для появления файлов в целевом хранилище, которые будут выполнены после перемещения файла и перед его удалением.
Эта опция рекомендуется для использования с хранилищами, которые не гарантируют согласованность чтения после записи. В противном случае, передача файлов между ними может вызвать момент времени, когда файл не существует ни в одном из хранилищ, что может привести к проблемам с восстановлением резервных копий в этот момент.
Добавьте --appearance-checks-interval, чтобы указать минимальный интервал времени между проверками одного и того же файла на появление в целевом хранилище.
Продолжительность должна быть указана в golang time.Duration формате.
Добавьте --preserve, чтобы предотвратить удаление переданных файлов из исходного хранилища («копировать» файлы вместо «перемещения»).

Примеры:

wal-g st transfer pg-wals --source='my_failover_ssh'

wal-g st transfer files folder/single_file.json --source='default' --target='my_failover_ssh' --overwrite

wal-g st transfer files basebackups_005/ --source='my_failover_s3' --target='default' --fail-fast -c=50 -m=10000 --appearance-checks=5 --appearance-checks-interval=1s

wal-g st transfer backups --source='my_failover_s3' --target='default' --fail-fast -c=50 --max-files=10000 --max-backups=10 --appearance-checks=5 --appearance-checks-interval=1s

WAL-G для PostgreSQL

Вы можете использовать wal-g как инструмент для создания зашифрованных, сжатых резервных копий PostgreSQL (полных и инкрементных) и их отправки/получения в/из удаленных хранилищ без сохранения на вашей файловой системе.

Если вы предпочитаете использовать Docker Image, вы можете напрямую протестировать wal-g с помощью этой песочницы playground.

Конфигурация

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

PGHOST может подключаться через UNIX-сокет. Этот режим предпочтительнее для подключений localhost, установите PGHOST=/var/run/postgresql для его использования. WAL-G будет подключаться через TCP, если PGHOST является IP адресом.

WALG_DISK_RATE_LIMIT

Для настройки ограничения скорости чтения диска во время backup-push в байтах в секунду.

Значения параллелизма могут быть настроены с помощью:

WALG_DOWNLOAD_CONCURRENCY

Для настройки количества гоупроцедур, используемых во время backup-fetch и wal-fetch, используйте WALG_DOWNLOAD_CONCURRENCY. По умолчанию, WAL-G использует минимальное количества извлекаемых файлов и 10.

WALG_DOWNLOAD_FILE_RETRIES

Чтобы настроить, сколько раз неудавшийся файл будет повторно запрашиваться во время backup-fetch и wal-fetch, используйте WALG_DOWNLOAD_FILE_RETRIES. По умолчанию установлено значение 15.

WALG_PREFETCH_DIR

По умолчанию предварительная выборка WAL сохраняет выбранные данные в каталоге pg_wal. Это гарантирует, что WAL можно легко переместить из места предварительной выборки в каталоге фактического использования WAL. Но это может иметь негативные последствия, если вы используете его с pg_rewind в PostgreSQL 13. PostgreSQL 13 способен вызывать restore_command во время pg_rewind. Предварительно выбранный WAL может вызвать ложную ошибку pg_rewind. Чтобы избежать этого, вы можете либо отключить предварительную выборку во время перемотки (установите WALG_DOWNLOAD_CONCURRENCY = 1), либо поместите папку предварительной выборки wal за пределами PGDATA. Подробности смотрите в this pgsql-hackers thread.

WALG_UPLOAD_CONCURRENCY

Для настройки количества параллельных потоков при загрузке резервной копии используйте WALG_UPLOAD_CONCURRENCY. По умолчанию, WAL-G использует 16 потоков.

WALG_UPLOAD_DISK_CONCURRENCY

Для настройки количества параллельных потоков, считывающих данные с диска во время backup-push, используется параметр wal_concurrency. По умолчанию, WAL-G использует 1 поток.

TOTAL_BG_UPLOADED_LIMIT (например, 1024)

Переопределяет значение по умолчанию количества файлов WAL для загрузки за один скан. По умолчанию будет загружено не более 32 файлов WAL.

WALG_SENTINEL_USER_DATA

Этот параметр позволяет инструментам автоматизации резервного копирования добавлять дополнительную информацию в файл JSON-маркер во время backup-push. Этот параметр может использоваться, например, для задания пользовательских имен для резервных копий. Примечание: UserData должен быть допустимой строкой JSON.

WALG_PREVENT_WAL_OVERWRITE

Если этот параметр указан, во время wal-push WAL-G будет проверять наличие WAL перед его загрузкой. Если другой файл уже архивирован под тем же именем, WAL-G вернет ненулевой код выхода, чтобы предотвратить удаление WAL PostgreSQL.

WALG_DELTA_MAX_STEPS

Дельта-бэкап - это разница между ранее созданной резервной копией и текущим состоянием. WALG_DELTA_MAX_STEPS определяет, сколько дельта-резервных копий может быть между полными резервными копиями. По умолчанию равно 0. Процесс восстановления автоматически получит все необходимые дельта-копии и базовую резервную копию и составит допустимую восстановленную резервную копию (вам все равно нужны WAL-файлы после начала последней резервной копии для восстановления согласованного кластера). Вычисление дельты основано на ModTime файловой системы и номере LSN страниц в файле данных.

WALG_DELTA_ORIGIN

Для настройки базы для следующего дельта-бэкапа (только если не превышено значение WALG_DELTA_MAX_STEPS). WALG_DELTA_ORIGIN может быть LATEST (цепочка инкрементов), LATEST_FULL (для баз, где волатильная часть компактна и цепочка не имеет значения - дельты перезаписывают друг друга). По умолчанию установлено значение LATEST.

WALG_TAR_SIZE_THRESHOLD

Для настройки размера одного резервного пакета (в байтах). Меньший размер обеспечивает более мелкую гранулярность и более оптимальное, быстрое восстановление. Однако это также увеличивает количество запросов к хранилищу, поэтому может стоить вам много денег. Размер по умолчанию - 1 ГБ (1 << 30 - 1 байт).

WALG_TAR_DISABLE_FSYNC

Отключить вызов fsync после записи файлов при извлечении tar-архивов.

WALG_PG_WAL_SIZE

Для настройки размера сегмента wal, если он отличается от значения по умолчанию в postgres, равного 16 МБ

WALG_UPLOAD_WAL_METADATA

Чтобы загрузить метаданные, связанные с wal-файлами. WALG_UPLOAD_WAL_METADATA может быть INDIVIDUAL (генерирует метаданные для всех wal-журналов) или BULK (генерирует метаданные для набора wal-файлов). Пример файла метаданных (000000020000000300000071.json)

{
    "000000020000000300000071": {
    "created_time": "2021-02-23T00:51:14.195209969Z",
    "date_fmt": "%Y-%m-%dT%H:%M:%S.%fZ"
    }
}

Если значение параметра равно NOMETADATA или не указано, то будет использовано значение по умолчанию (без генерации метаданных wal).

WALG_ALIVE_CHECK_INTERVAL

Для контроля того, как часто WAL-G будет проверять, работает ли Postgres во время backup-push. Если проверка не пройдет, backup-push прекращает работу.

Примеры:

0 - отключить проверки на активность
10s - проверять каждые 10 секунд
1m - проверять каждую 1 минуту (значение по умолчанию)
10m - проверять каждые 10 минут

WALG_STOP_BACKUP_TIMEOUT

Таймаут для вызова pg_stop_backup(). По умолчанию таймаут отсутствует.

Примеры:

0 - отключить тайм-аут (значение по умолчанию)
10s - тайм-аут 10 секунд
10м - тайм-аут 10 минут

Использование

Типичное использование:

`backup-fetch`

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

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

WAL-G также может получить последнюю резервную копию с помощью:

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

WAL-G может получить резервную копию, которая имеет конкретные пользовательские данные (хранящиеся в метаданных резервной копии), используя флаг --target-user-data или переменную WALG_FETCH_TARGET_USER_DATA:

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

Обратная распаковка дельты

Бета-функция: WAL-G может распаковывать дельта-копии в обратном порядке для улучшения эффективности загрузки.

Чтобы активировать эту функцию, выполните одно из следующих действий:

Установите переменную среды WALG_USE_REVERSE_UNPACK.
добавьте флаг --reverse-unpack

wal-g backup-fetch /path LATEST --reverse-unpack

Пропуск избыточных архивов

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

Опционально. Увеличивает вероятность пропуска архива, но может привести к более медленному созданию резервной копии. Включите режим компоновщика tar-архивов с оценкой для backup-push.
Включите пропуск избыточных архивов резервных копий во время операции восстановления резервной копии. Выполните одно из следующих действий:
- Установите переменные среды WALG_USE_REVERSE_UNPACK и WALG_SKIP_REDUNDANT_TARS.
- Добавьте флаги --reverse-unpack и --skip-redundant-tars.

wal-g backup-fetch /path LATEST --reverse-unpack --skip-redundant-tars

Частичное восстановление (экспериментально)

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

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

Примечание: Двойные кавычки нужны только для вставки пробелов и будут проигнорированы

Пример:

--restore-only=my_db,"another db"

эквивалентно

--restore-only=my_db,another" "db

или даже так\:

--restore-only=my_db,anoth"e"r" "d"b"

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

Восстанавливает системные базы данных и таблицы автоматически.

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

Из-за того, что остатки невосстановленных баз данных или таблиц все еще находятся в системных таблицах, рекомендуется их удалить.

`backup-push`

При загрузке резервных копий в хранилище, пользователь должен передать каталог данных Postgres в качестве аргумента.

wal-g backup-push $PGDATA

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

Если резервное копирование начинается с резервного сервера, WAL-G будет отслеживать временную шкалу сервера. Если во время резервного копирования происходит повышение или изменение временной шкалы, данные будут загружены, но не завершены, и WAL-G завершится с ошибкой. Логи будут содержать необходимую информацию для завершения резервного копирования, которую можно использовать, если вы четко понимаете риски.

backup-push также можно запустить с флагом --permanent, который пометит резервную копию как постоянную и предотвратит ее удаление при выполнении команды delete.

Удаленное резервное копирование

WAL-G backup-push позволяет использовать два варианта потоковой передачи данных:

Запускаясь непосредственно на сервере базы данных от имени пользователя postgres, wal-g может читать файлы базы данных из файловой системы. Этот вариант обеспечивает высокую производительность и дополнительные возможности, такие как частичное восстановление или Delta резервные копии.
Для загрузки резервных копий в S3 с использованием опции потоковой передачи 1, пользователь должен указать путь, содержащий резервную копию, начатую Postgres, как в:
```
wal-g backup-push /backup/directory/path
```
В качестве альтернативы, WAL-G может передавать данные резервной копии через postgres протокол BASE_BACKUP. Это позволяет WAL-G передавать данные резервной копии через слой tcp, запускать удаленно и работать как отдельный пользователь Linux. WAL-G требует подключения к базе данных с привилегиями репликации. Обратите внимание, что протокол BASE_BACKUP не поддерживает многопотоковую передачу, и что Delta резервное копирование в настоящее время не реализовано.
Чтобы передавать данные резервной копии в потоковом режиме, не указывайте каталог данных. А чтобы задать имя хоста сервера postgres, вы можете использовать переменную окружения PGHOST или аргумент WAL-G --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
```

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

Запустите Postgres на нескольких хостах (потоковая репликация), и создайте резервную копию с помощью WAL-G, используя конфигурацию с несколькими хостами: wal-g backup-push --pghost srv1,srv2
Запустите Postgres на хосте Windows и выполните резервное копирование с помощью WAL-G на хосте Linux: PGHOST=winsrv1 wal-g backup-push
Запланируйте выполнение WAL-G как Kubernetes CronJob

Режим оценки компоновщика

В режиме компоновщика рейтинга, WAL-G размещает файлы с похожими частотами обновлений в одних и тех же tarballs во время создания резервной копии. Это должно увеличить эффективность backup-fetch пропуска избыточных архивов. Обратите внимание, что хотя компоновщик рейтинга позволяет сохранять больше данных, это может привести к замедлению создания резервной копии по сравнению с компоновщиком tarball по умолчанию.

Чтобы активировать эту функцию, выполните одно из следующих действий:

Установите переменную среды WALG_USE_RATING_COMPOSER.
добавьте флаг --rating-composer

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

Режим копирования компоновщика

В режиме копирования композитора WAL-G делает полный резервный копирование и копирует неизмененные tar файлы из предыдущего полного резервного копирования. В случае, если нет предыдущего полного резервного копирования, используется regular композитор.

Чтобы активировать эту функцию, выполните одно из следующих действий:

Установите переменную среды WALG_USE_COPY_COMPOSER.
добавьте флаг --copy-composer

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

Режим композитора базы данных

В режиме композитора базы данных, WAL-G разделяет файлы из различных каталогов внутри стандартного табличного пространства и упаковывает их в разные tar-архивы. Разработано для повышения производительности частичного восстановления.

Чтобы активировать эту функцию, выполните одно из следующих действий:

установите переменную окружения WALG_USE_DATABASE_COMPOSER
добавьте флаг --database-composer

wal-g backup-push /path --database-composer

Резервное копирование без метаданных

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

Если включена опция --without-files-metadata или WALG_WITHOUT_FILES_METADATA, то WAL-G не отслеживает метаданные файлов, которые были созданы резервной копией. Это значительно снижает использование памяти на экземплярах с более чем 100 тыс. файлов.

Ограничения

Нельзя использовать с rating-composer, copy-composer
Нельзя использовать с настройкой WALG_DELTA_MAX_STEPS или флагами delta-from-user-data и delta-from-name.

Чтобы активировать эту функцию, выполните одно из следующих действий:

Установите переменную среды WALG_WITHOUT_FILES_METADATA.
Добавьте флаг --without-files-metadata.

wal-g backup-push /path --without-files-metadata

Создать дельта-резервную копию из конкретной резервной копии

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

Флаг --delta-from-name или переменная окружения WALG_DELTA_FROM_NAME для выбора резервной копии с указанным именем в качестве базы для дельта-бэкапа
--delta-from-user-data флаг или WALG_DELTA_FROM_USER_DATA переменная окружения для выбора резервной копии с указанными пользовательскими данными в качестве базы для дельта-бэкапа

Примеры:

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, логика 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.

Проверка контрольных сумм страниц

Для включения проверки контрольных сумм страниц во время резервного копирования-передачи, используйте флаг --verify или установите переменную среды WALG_VERIFY_PAGE_CHECKSUMS. Если найдены поврежденные номера блоков (в настоящее время не более 10), они будут записаны в резервную копию в формате 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. Эти файлы будут кэшироваться в ./.wal-g/prefetch директории. Кэшированные файлы, старше недавно запрашиваемого файла WAL, будут удалены из кэша, чтобы предотвратить его раздувание. Если кэшированный файл запрашивается с помощью wal-fetch, это также удалит его из кэша, но вызовет кэширование нового файла.

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

Эта команда предназначена для выполнения из параметра Postgres restore_command.

Примечание: wal-fetch завершится с кодом ошибки 74 (EX_IOERR: input/output error, see sysexits.h for more info) если WAL-файл недоступен в репозитории. Все остальные ошибки заканчиваются кодом выхода 1 и должны остановить PostgreSQL, а не завершать восстановление PostgreSQL. Для PostgreSQL это должен быть любой код ошибки между 126 и 255, который можно достичь с помощью простого скрипта-обертки. Пожалуйста, смотрите https://github.com/wal-g/wal-g/pull/1195 для получения дополнительной информации.

`wal-push`

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

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

Эта команда предназначена для выполнения из параметра Postgres archive_command.

`wal-show`

Показать информацию о папке хранения WAL. wal-show показывает все временные линии сегментов WAL, доступные в хранилище, отображает доступные резервные копии для них, и проверяет их на отсутствующие сегменты.

если в диапазоне нет пропусков (отсутствующих сегментов), конечный статус будет OK
Если найдены отсутствующие сегменты, конечный статус будет LOST_SEGMENTS.

wal-g wal-show

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

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

`wal-verify`

Выполните серию проверок, чтобы убедиться, что хранилище сегментов WAL находится в рабочем состоянии. Доступные проверки:

`integrity`

Убедитесь, что существует последовательная история сегментов WAL для кластера, чтобы WAL-G мог выполнить PITR для резервной копии. По сути, это проверяет, что все сегменты WAL в диапазоне [старейший начальный сегмент резервной копии, текущий сегмент кластера) доступны в хранилище. Если резервные копии не найдены, [1, текущий сегмент кластера) диапазон будет просканирован.

Диаграмма G.1. ИллюстрацияСтатусаСегмента

В выводе проверки целостности, существуют четыре статуса сегментов WAL:

FOUND сегменты присутствуют в хранилище WAL
MISSING_DELAYED сегменты отсутствуют в хранилище WAL, но, вероятно, Postgres еще не пытался архивировать их с помощью archive_command
MISSING_UPLOADING сегменты - это сегменты, которые отсутствуют в хранилище WAL, но кажется, что они находятся в процессе загрузки в хранилище
MISSING_LOST сегменты отсутствуют в хранилище WAL и не являются ни MISSING_UPLOADING, ни MISSING_DELAYED

ProbablyUploading размер диапазона сегментов берется из настройки WALG_UPLOAD_CONCURRENCY.

ProbablyDelayed размер диапазона сегментов контролируется с помощью настройки WALG_INTEGRITY_MAX_DELAYED_WALS.

Вывод состоит из:

Статус проверки integrity:
- OK если нет отсутствующих сегментов
- WARNING если есть некоторые отсутствующие сегменты, но они не MISSING_LOST
- FAILURE если есть некоторые MISSING_LOST сегменты
Список, который показывает сегменты WAL в хронологическом порядке, сгруппированные по временной шкале и статусу.

`timeline`

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

Вывод состоит из:

Статус проверки timeline:
- OK если текущий идентификатор временной шкалы совпадает с наивысшим идентификатором временной шкалы, найденным в хранилище
- WARNING если не удалось определить, совпадает ли текущая временная шкала с самой высокой в хранилище
- FAILURE, если текущий идентификатор временной шкалы не равен наивысшему идентификатору временной шкалы, найденному в хранилище
Текущий идентификатор временной шкалы.
Самый высокий идентификатор временной шкалы, найденный в папке хранения WAL.

Использование:

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 репликация потоков и отправка в хранилище.

You can set WALG_SLOTNAME variable to define the репликационный слот name to be used (defaults to walg). The slot name can only consist of the following characters: [0-9A-Za-z_]. When uploading WAL archives to S3, the user should pass in the absolute path to where the archive is located.

wal-g wal-receive

`backup-mark`

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

wal-g backup-mark example-backup -i

`catchup-push`

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

Шаги: 1) Остановите реплику 2) Получите LSN реплики (например, используя команду pg_controldata) 3) Начните загрузку инкрементальной резервной копии на мастере.

wal-g catchup-push /path/to/master/postgres --from-lsn replica_lsn

`catchup-fetch`

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

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

`catchup-send` и `catchup-recieve`

Эти команды используются вместе для догонки отстающего реплики. На резервном сервере вы должны запустить catchup-recieve, затем на основном сервере catchup-send. Резервный Postgres должен быть остановлен во время этой процедуры.

wal-g catchup-receive ${PGDATA_STANDBY} 1337 &

wal-g catchup-send ${PGDATA_PRIMARY} hostname:1337

`copy`

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

Флаги:

-b, --backup-name string Копировать конкретный резервную копию
-f, --from string Конфигурация хранилища, откуда следует скопировать резервную копию
-t, --to string Конфигурация хранилища, куда следует скопировать резервную копию
-w, --without-history Копировать резервную копию без истории (wal файлы)

`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

Цель garbage может использоваться в дополнение к другим целям, которые являются общими для всех хранилищ.

`wal-restore`

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

Использование:

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

`daemon`

Архивирует и извлекает все сегменты WAL в фоновом режиме. Работает с библиотекой архивации PostgreSQL walg_archive или walg-daemon-client.

Использование:

wal-g daemon path/to/socket-descriptor

Конфигурация

WALG_DAEMON_WAL_UPLOAD_TIMEOUT

Чтобы настроить временной лимит для каждого архива WAL в демоне. Операции, зависающие на более длительное время, будут прерваны. Значение по умолчанию — 60 секунд.

`поддержка резервных копий pgBackRest (бета-версия)`

Поддержка резервных копий pgBackRest является:

`pgbackrest backup-list`

Список резервных копий pgbackrest.

Использование:

wal-g pgbackrest backup-list [--pretty] [--json] [--detail]

`pgbackrest backup-fetch`

Получить резервную копию pgbackrest. В настоящее время работает только с полными резервными копиями, инкрементные и дифференциальные резервные копии не поддерживаются.

Использование:

wal-g pgbackrest backup-fetch path/to/destination-directory backup-name

`pgbackrest wal-fetch`

Получить файл wal из резервной копии pgbackrest

Использование:

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

`pgbackrest wal-show`

Показать wal-файлы из резервной копии pgbackrest

Использование:

wal-g pgbackrest wal-show

Резервные хранилища для аварийного переключения (экспериментально)

Возможно настроить WAL-G для использования дополнительных хранилищ "аварийного переключения", которые используются в случае, если основное хранилище становится недоступным. Это может быть полезно для избежания проблем с нехваткой дискового пространства.

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

wal-push
wal-fetch
wal-prefetch
backup-push
backup-fetch
backup-list
delete (включая все подкоманды)

Конфигурация

WALG_FAILOVER_STORAGES

Вложенный раздел с настройками резервных хранилищ с их именами. Настройки основного хранилища берутся из корня конфигурации. Основное хранилище всегда используется, если оно доступно. Если нет, используется первое доступное резервное хранилище (для большинства команд, но некоторые команды используют все доступные хранилища). Порядок резервных хранилищ определяется сортировкой их имен в лексикографическом порядке.

Пожалуйста, обратите внимание, что для использования этой функции WAL-G должен быть настроен с использованием конфигурационного файла, так как невозможно поместить эту вложенную структуру в переменную окружения.

Пример:

WALG_FAILOVER_STORAGES:
    TEST_STORAGE:
        AWS_SECRET_ACCESS_KEY: "S3_STORAGE_KEY_1"
        AWS_ACCESS_KEY_ID: "S3_STORAGE_KEY_ID_1"
        WALE_S3_PREFIX: "s3://some-s3-storage-1/"
    STORAGE2:
        AWS_SECRET_ACCESS_KEY: "S3_STORAGE_KEY_2"
        AWS_ACCESS_KEY_ID: "S3_STORAGE_KEY_ID_2"
        WALE_S3_PREFIX: "s3://some-s3-storage-2/"
    FILE_STORAGE:
        WALG_FILE_PREFIX: "/some/prefix"

Проверка активности хранилища

WAL-G ведет список всех статусов хранилищ в любой данный момент и использует только активные хранилища во время выполнения команд. Этот список служит кэшем, так как мы не хотим проверять каждое хранилище при каждой операции ввода-вывода.

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

Существует два источника информации, которые влияют на статусы хранения в кэше: - Явные проверки. Это отдельные процедуры, выполняемые на хранилищах для проверки их работоспособности для RO / RW нагрузки. - Мониторинг фактических операций. Каждый раз, когда выполняется какая-либо операция на хранилище, ее результат сообщается и применяется к метрике "живучести" хранилища. Эта метрика рассчитывается с использованием алгоритма экспоненциального скользящего среднего.

Явные проверки используются только в том случае, если какое-то хранилище еще не использовалось вообще или не использовалось в течение длительного времени, так что его статус TTL истек. Например, если хранилище вышло из строя и не использовалось командами WAL-G из-за этого, его статус в конечном итоге устаревает в кэше. Чтобы вернуть его в кэш, выполняется явная проверка.

Вы можете найти подробности настройки фактического мониторинга операций в разделе ниже.

WALG_FAILOVER_STORAGES_CHECK (=true по умолчанию)

Позволяет полностью отключить проверки на живучесть. В этом случае используются все настроенные хранилища, и все считаются живыми.

WALG_FAILOVER_STORAGES_CHECK_TIMEOUT (=30s по умолчанию)

Позволяет указать тайм-аут для явных проверок.

WALG_FAILOVER_STORAGES_CHECK_SIZE (=1mb по умолчанию)

Позволяет указать размер файла, который загружается в явной проверке RW.

WALG_FAILOVER_STORAGES_CACHE_LIFETIME (=15m по умолчанию)

Этот параметр управляет временем жизни кэша для каждого статуса хранения.

Конфигурация экспоненциального скользящего среднего

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

new_aliveness = (reported_value * α) + (prev_aliveness * (1 - α))

Где α фактически является «чувствительностью» reported_value по сравнению с prev_aliveness.

reported_value либо вес операции (в случае успешного выполнения операции), либо 0 (в случае неудачи).

Различные операции имеют разный вес: - Проверка существования файла: 1000 - Список файлов в папке: 2000 - Чтение файла: 1000 * log_10(file_size_in_mb), но не менее 1000. - Запись файла: 1000 * log_10(file_size_in_mb), но не менее 1000. - Удаление файла: 500 - Копирование файла: 2000

Когда жизнеспособность мертвого хранилища достигает «предела живучести», хранилище становится живым. Когда жизнеспособность живого хранилища достигает «предела мертвости», оно становится мертвым. Предел живучести больше, чем предел мертвости, чтобы усложнить быстрое переключение между состояниями мертвого и живого.

В приведенной выше формуле α также не является постоянной, она изменяется в определенных пределах в зависимости от текущего значения живучести и состояния хранения (мертв / жив).

α изменяется линейно в пределах настроенных диапазонов, и диапазоны различаются для живых и мертвых хранилищ. - Для живого хранилища α максимален при живучести = 1.0, и минимален при живучести = предел мертвости. - Для мертвого хранилища α максимален при живучести = 0, и минимален при живучести = предел живучести.

Это можно настроить, используя следующие параметры:

WALG_FAILOVER_STORAGES_CACHE_EMA_ALIVE_LIMIT (=0.99 по умолчанию)

Значение предела активности.

WALG_FAILOVER_STORAGES_CACHE_EMA_DEAD_LIMIT (=0.88 по умолчанию)

Пороговое значение завершения.

WALG_FAILOVER_STORAGES_CACHE_EMA_ALPHA_ALIVE_MAX (=0.05 по умолчанию)

Максимальное значение EMA Alpha для активного хранилища.

WALG_FAILOVER_STORAGES_CACHE_EMA_ALPHA_ALIVE_MIN (=0.01 по умолчанию)

Минимальное значение EMA Alpha для активного хранилища.

WALG_FAILOVER_STORAGES_CACHE_EMA_ALPHA_DEAD_MAX (=0.5 по умолчанию)

Максимальное значение EMA Alpha для неактивного хранилища.

WALG_FAILOVER_STORAGES_CACHE_EMA_ALPHA_DEAD_MIN (=0.1 по умолчанию)

Минимальное значение EMA Alpha для неактивного хранилища.

Игровая площадка

Если вы предпочитаете использовать образ Docker, вы можете напрямую протестировать WAL-G с этим песочницей.

Пожалуйста, обратите внимание, что это сторонний репозиторий, и мы не несем ответственности за его корректную работу.

Назад	Наверх	Далее
columnar_migrator	Начало	pg_anon

wal-g

wal-g#

wal-g

WAL-G

О wal-g

Конфигурация

Сжатие

Шифрование

Мониторинг

Профилирование

Ограничение скорости

Использование

backup-list

delete

Примеры

Разработка

Ubuntu

macOS

Устранение неполадок

Авторы

Благодарности

Чат

Инструменты хранения (опасная зона)

ls

get

cat

rm

put

transfer

WAL-G для PostgreSQL

Конфигурация

Использование

backup-fetch

Обратная распаковка дельты

Пропуск избыточных архивов

Частичное восстановление (экспериментально)

backup-push

Удаленное резервное копирование

Режим оценки компоновщика

Режим копирования компоновщика

Режим композитора базы данных

Резервное копирование без метаданных

Создать дельта-резервную копию из конкретной резервной копии

Проверка контрольных сумм страниц

wal-fetch

wal-push

wal-show

wal-verify

integrity

timeline

wal-receive

backup-mark

catchup-push

catchup-fetch

catchup-send и catchup-recieve

copy

delete garbage

wal-restore

daemon

поддержка резервных копий pgBackRest (бета-версия)

pgbackrest backup-list

pgbackrest backup-fetch

pgbackrest wal-fetch

pgbackrest wal-show

Резервные хранилища для аварийного переключения (экспериментально)

Конфигурация

Проверка активности хранилища

Конфигурация экспоненциального скользящего среднего

Игровая площадка

`backup-list`

`delete`

`ls`

`get`

`cat`

`rm`

`put`

`transfer`

`backup-fetch`

`backup-push`

`wal-fetch`

`wal-push`

`wal-show`

`wal-verify`

`integrity`

`timeline`

`wal-receive`

`backup-mark`

`catchup-push`

`catchup-fetch`

`catchup-send` и `catchup-recieve`

`copy`

`delete garbage`

`wal-restore`

`daemon`

`поддержка резервных копий pgBackRest (бета-версия)`

`pgbackrest backup-list`

`pgbackrest backup-fetch`

`pgbackrest wal-fetch`

`pgbackrest wal-show`