Wal что за формат
Знакомство с wal-g системой бекапирования PostgreSQL
WAL-G — простой и эффективный инструмент для резервного копирования PostgreSQL в облака. По своей основной функциональности он является наследником популярного инструмента WAL-E, но переписанным на Go. Но в WAL-G есть одна важная новая особенность — дельта-копии. Дельта-копии WAL-G хранят страницы файлов, изменившиеся с предыдущей версии резервной копии. В WAL-G реализовано довольно много технологий по распараллеливанию бэкапов. WAL-G работает гораздо быстрее чем, WAL-E.
Подробности работы wal-g можно прочитать в статье: Разгоняем бэкап. Лекция Яндекса
Протокол хранения S3 стал популярным для хранения данных. Одно из преимуществ S3 — возможность доступа через API, что позволяет организовать гибкое взаимодействие с хранилищем, включая публичный доступ на чтение, в то время как обновление информации в хранилище происходит только авторизованными лицами.
Существует несколько как открытых, так и частных реализаций хранилищ, работающих по протоколу S3. Сегодня мы рассмотрим популярное решение для организации малых хранилищ — Minio.
Для тестирования wal-g подойдет один сервер PostgreSQL, а в качестве замены S3 используется Minio.
Сервер Minio
Правим AccessKey и SecretKey в /etc/minio/minio.conf
Если вы не будете использовать nginx перед Minio, то нужно изменить
Генерируем и добавляем в MINIO_ACCESS_KEY и MINIO_SECRET_KEY в /etc/minio/minio.conf
Заходим в web-интерфейс Minio http://ip-адрес-сервера-minio:9000 и создаем бакет (например, pg-backups).
Сервер БД
WAL-G в rpm собираю я (Антон Пацев). Github, Fedora COPR.
У кого не RPM-based система используйте официальную инструкцию по установке.
Вместе с бинарником wal-g в rpm присутствуют скрипты, которые импортируют переменные из файла /etc/wal-g.d/server-s3.conf.
Проверяем версию wal-g.
Редактируем /etc/wal-g.d/server-s3.conf по свои нужды.
Файлы конфигурации и файлы данных, используемые кластером базы данных, традиционно хранятся вместе в каталоге данных кластера, который обычно называют PGDATA
При настройке WAL-G вы указываете WALG_DELTA_MAX_STEPS — количество шагов, на которые максимально отстоит от base-бэкапа дельта-бэкап, и указываете политику дельта-копии. Либо вы делаете копию с последней существующей дельты, либо делаете дельту от изначального полного бэкапа. Это нужно на тот случай, когда у вас в базе данных всегда меняется одна и та же составляющая БД, одни и те же данные постоянно изменяются.
Если вы тестируете на 1 сервере, то нужно перенастроить параметр wal_level на archive для PostgreSQL меньше 10 версии, и replica для PostgreSQL 10 версии и старше.
Сделаем бекапирование WAL архивов каждые 60 секунд с помощью самого PostgreSQL. На проде у вас будет другое значение archive_timeout.
В отдельной консоли смотрим логи PostgreSQL на предмет ошибок: (postgresql-Wed.log меняете на текущий).
Создаем таблицу в бд test1.
Переключаемся на бд test.
Создаем таблицу indexing_table.
Запускаем вставку данных. Ждем 10-20 минут.
Смотрим записи в таблице в бд test1
Строка это текущее время.
Переключаем сегмент WAL:
Делаем полный бекап.
Смотрим список полных бекапов
Тестирование восстановления
Полное восстановление с накатываем всех доступных WAL.
Удаляем все из папки /var/lib/pgsql/9.6/data.
Запускаем скрипт /usr/local/bin/backup-fetch.sh от пользователя postgres.
Backup extraction complete.
Добавляем recovery.conf в папку /var/lib/pgsql/9.6/data со следующим содержимым.
Запускаем PostgreSQL. PostgreSQL запустит процесса recovery из архивных WAL, и только потом база откроется.
Восстановление на определенное время.
Если хотим восстановить базу до определенный минуты, то в recovery.conf добавляем параметр recovery_target_time — указываем на какое время восстановить базу.
После восстановления смотрим на таблицу indexing_table
Запускаем PostgreSQL. PostgreSQL запустит процесса recovery из архивных WAL, и только потом база откроется.
Восстановление в PostgreSQL версии 12 и выше работает по-другому:
Тестирование
Запрашиваем размер бакета после генерации 1GB данных.
s4cmd — бесплатный инструмент командной строки для работы с данными, расположенными в хранилище Amazon S3. Утилита написана на языке программирования python, и благодаря этому может использоваться в операционных системах и Windows, и Linux.
Brotli
Сравнение результатов на графике.
Как видим, что Brotli сопоставим по размеру с LZMA, но бекап выполняется за время LZ4.
Чат русскоязычного сообщества PostgreSQL: https://t.me/pgsql
Поставьте, пожалуйста, звезду на Github, если вы используете wal-g
Восстановление файлов формата DB-WAL
Руководство для Windows, MacOS, Android и IOS систем в 2021
Временный файл базы данных, созданный SQLite 3.7.0 или новее, компактная программа базы данных, обычно встроенная в мобильные и настольные приложения; сохраняет информацию журнала записи (WAL) для базы данных; автоматически создается и управляется базой данных.
Программы для восстановления DB-WAL файлов
Ищете как восстановить лог-файл (write-ahead) базы данных sqlite?
В случаях, когда файлы удалены и стандартными средствами системы их восстановить уже не предоставляется возможным, используйте Hetman Partition Recovery.
1. Загрузите, установите и запустите программу.
2. Программа автоматически просканирует компьютер и отобразит все подключенные к нему жесткие диски и съёмные носители информации, физические и локальные диски.
3. Дважды кликните на диске, файлы из которого необходимо восстановить, и выберите тип анализа.
4. После окончания процесса сканирования вам будут предоставлены файлы для восстановления.
5. Чтобы найти нужный лог-файл (write-ahead) базы данных sqlite, перейдите в интерфейсе программы в папку из которой он был удалён. Или перейдите в папку «Глубокий анализ» и выберите искомый тип файла.
6. Выделите нужные db-wal файлы и нажмите кнопку «Восстановить».
7. Выберите один из предложенных способов сохранения файлов и восстановите их.
Sysadminium
База знаний системного администратора
Буферный кэш и журнал WAL в PostgreSQL
Рассмотрим технологии которые обеспечивают высокую производительность и безопасность работы сервера PostgreSQL, а именно “Буферный кэш” и “Журнал предзаписи WAL“. В документации об этом можете почитать тут.
Устройство буферного кэша
Кэш нужен чтобы читать востребованные данные ни с диска а с более быстрой оперативной памяти. Предварительно данные приходится загружать с диска в буферных кэш оперативной памяти.
В общей памяти отводится определённый кусок памяти под массив буферов. В каждом буфере хранится одна страница памяти. Страница памяти это 8 КБ. Когда мы собираем PostgreSQL из исходных кодов мы можем изменить размер этой страницы. А после сборки это изменить уже не получится.
Есть 3 варианта размера страниц:
Буферный кэш занимает большую часть общей памяти.
Если процессу понадобятся какие-то данные он их вначале ищет в буферном кэше. Если данных в кэше не оказалось, то мы просим операционную систему прочитать эту страничку и поместить в буферный кэш. Операционная система имеет свой дисковые кэш, и ищет эту страничку там, если не находит, то читает с диска и помещает в дисковый кэш. Затем из дискового кэша страничка помещается в буферный кэш для PostgreSQL.
Так как буферный кэш находится в общей памяти, то чтобы разные процессы не мешали друг другу, к нему применяют различные блокировки.
Алгоритм вытеснения
Чтобы буферный кэш не переполнился нужно редко используемые страницы из него вытеснять. Другими словами удалить из буфера. Если мы страничку поменяли, то она считается грязной, и перед вытеснением из буфера её нужно записать на диск. Если мы страничку не меняли то и записывать на диск её ещё раз не имеет смыла.
В PostgreSQL реализован алгоритм вытеснения страниц из буфера при котором в кэше остаются самые часто используемые страницы.
Журнал предзаписи (WAL)
То что у нас данные находятся в оперативной памяти – это хорошо. Но при сбое эти данные теряются, если не успели записаться на диск.
После сбоя наша база становится рассогласованной. Какие-то страницы менялись и были записаны, другие не успели записаться.
Журнал предварительной записи (WAL) – механизм, которым позволит нам восстановить согласованность данных после сбоя.
Когда мы хотим поменять какую-то страницу памяти, мы предварительно пишем, что хотим сделать в журнал предзаписи. И запись в этом журнале должна попасть на диск раньше, чем сама страница будет записана на диск.
В случае сбоя мы смотрим в журнал предзаписи и видим какие действия выполнялись, проделываем эти действия заново и восстанавливаем согласованность данных.
Почему запись в WAL эффективнее чем запись самой страницы? При записи страницы памяти на диск она пишется в произвольное место, это место еще нужно выбрать, подготовить для записи и начать запись. А запись в журнал ведется одним потоком и с этим потоком нормально справляются и обычные жёсткие диски и ssd.
WAL защищает всё что попадает в буферный кэш:
Производительность WAL
По умолчанию, каждый раз, когда транзакция фиксирует изменения, результат должен быть сброшен на диск. Для этого вначале страница сбрасывается из буферной памяти на дисковый кэш. А затем выполняется операция fsync для записи страницы на диск. То есть частые COMMIT приводят к частым fsync.
В PostgreSQL есть другой режим работы – асинхронный. При этом каждый COMMIT не приводит к fsync. Вместо этого страницы сбрасываются на диск по расписанию специальным процессом – WALWRITER. Этот процесс периодически просыпается и записывает на диск всё что изменилось за время пока он спал и опять засыпает.
В асинхронном режиме postgresql работает быстрее, но вы можете потерять некоторые данные при сбое.
Режим работы настраивается с помощью конфигурационного файла и настройки не требуют перезагрузки сервера. Это позволяет приложению устанавливать параметры на лету. Некоторые транзакции сразу запишут изменения на диск, то есть поработают в синхронном режиме. Другие транзакции будут работать в асинхронном режиме. Условно можно поделить операции на критичные и не критичные.
Следующие параметры отвечают за режим работы WAL:
Контрольная точка
При выполнении контрольной точки (CHECKPOINT) – принудительно сбрасываются на диск все грязные страницы, которые есть в буферном кэше. Это гарантирует что на момент контрольной точки все данные сбросились на диск и при восстановлении данных нужно читать не весь журнал WAL, а только ту часть которая была сделана после последней контрольной точки.
Сброс данных при контрольной точке не проходит моментально, это бы сильно нагрузило наш сервер. Чтобы не было пиковых нагрузок сброс идет примерно 50% времени от времени между контрольными точками. Например, контрольные точки делаются каждую минуту, тогда сброс осуществляют плавно в течении 30 секунд. Это регулируется и вы можете установить например 90% времени.
Контрольная точка также уменьшает размер необходимого дискового пространства. Так как весь журнал WAL не нужен, его можно периодически подрезать.
Отдельный серверный процесс контрольных точек автоматически выполняет контрольные точки с заданной частотой. Эту частоту можно настроить следующими параметрами:
Значения по умолчанию: 5 минут и 1 Гбайт, соответственно. Если после предыдущей контрольной точки новые записи WAL не добавились, следующие контрольные точки будут пропущены, даже если проходит время checkpoint_timeout. Также можно выполнить контрольную точку принудительно, воспользовавшись SQL-командой CHECKPOINT.
Уменьшение значений checkpoint_timeout и max_wal_size приводит к учащению контрольных точек. Но появляется дополнительная нагрузка на сервер.
Процессы, связанные с буферным кэшем и журналом
Уровни журналов
Практика
В журнале WAL каждая запись имеет номер LSN (Log Sequence Number). С помощью функции pg_current_wal_lsn() можно посмотреть номер текущей записи:
Запомним номер текущей записи WAL в переменной “pos1”, затем создадим табличку с 1000 строк и опять сохраним текущий LSN в переменной “pos2”. Затем посмотрим разницу между этими числами, но в формате LSN, и получим число байт записанных в WAL при создании таблички с 1000 строками:
У нас вышло 138 KB! Так много получилось из за создания таблички, создание 1000 строк почти не нагрузит WAL.
Физически журнал хранится в файлах по 16 МБ в отдельном каталоге (PGDATA/pg_wal). На журнал можно взглянуть не только из файловой системы, но и с помощью функцию pg_ls_waldir():
Посмотреть на выполняемые процессы сервера postgres можно так:
К процессам, обслуживающим буферный кэш и журнал, можно отнести:
Теперь давайте остановим сервер корректно и посмотрим в лог файл:
Как видим сервер просто открыл соединения на сокете и tcp порту 5432 и начал работу.
Теперь завершим работу сервера некорректно, используя опцию immediate:
Как видим журнал изменился! Перед тем, как начать принимать соединения, СУБД выполнила восстановление (automatic recovery in progress).
Расширение файла DB-WAL
SQLite Database Write-Ahead Log Format
Что такое файл DB-WAL?
Программы, которые поддерживают DB-WAL расширение файла
Ниже вы найдете указатель программ, которые можно использовать для открытия файлов DB-WAL, разделенных на категории 4 в соответствии с поддерживаемой системной платформой. Файлы с суффиксом DB-WAL могут быть скопированы на любое мобильное устройство или системную платформу, но может быть невозможно открыть их должным образом в целевой системе.
Программы, обслуживающие файл DB-WAL
Как открыть файл DB-WAL?
Проблемы с доступом к DB-WAL могут быть вызваны разными причинами. С другой стороны, наиболее часто встречающиеся проблемы, связанные с файлами SQLite Database Write-Ahead Log Format, не являются сложными. В большинстве случаев они могут быть решены быстро и эффективно без помощи специалиста. Ниже приведен список рекомендаций, которые помогут вам выявить и решить проблемы, связанные с файлами.
Шаг 1. Скачайте и установите SQLite
Шаг 2. Убедитесь, что у вас установлена последняя версия SQLite
Если у вас уже установлен SQLite в ваших системах и файлы DB-WAL по-прежнему не открываются должным образом, проверьте, установлена ли у вас последняя версия программного обеспечения. Иногда разработчики программного обеспечения вводят новые форматы вместо уже поддерживаемых вместе с новыми версиями своих приложений. Причиной того, что SQLite не может обрабатывать файлы с DB-WAL, может быть то, что программное обеспечение устарело. Все форматы файлов, которые прекрасно обрабатывались предыдущими версиями данной программы, также должны быть открыты с помощью SQLite.
Шаг 3. Настройте приложение по умолчанию для открытия DB-WAL файлов на SQLite
Если у вас установлена последняя версия SQLite и проблема сохраняется, выберите ее в качестве программы по умолчанию, которая будет использоваться для управления DB-WAL на вашем устройстве. Процесс связывания форматов файлов с приложением по умолчанию может отличаться в деталях в зависимости от платформы, но основная процедура очень похожа.
Процедура изменения программы по умолчанию в Windows
Процедура изменения программы по умолчанию в Mac OS
Шаг 4. Убедитесь, что DB-WAL не неисправен
Если вы выполнили инструкции из предыдущих шагов, но проблема все еще не решена, вам следует проверить файл DB-WAL, о котором идет речь. Вероятно, файл поврежден и, следовательно, недоступен.
Если DB-WAL действительно заражен, возможно, вредоносное ПО блокирует его открытие. Рекомендуется как можно скорее сканировать систему на наличие вирусов и вредоносных программ или использовать онлайн-антивирусный сканер. Если сканер обнаружил, что файл DB-WAL небезопасен, действуйте в соответствии с инструкциями антивирусной программы для нейтрализации угрозы.
2. Проверьте, не поврежден ли файл
Вы получили DB-WAL файл от другого человека? Попросите его / ее отправить еще раз. Возможно, файл был ошибочно скопирован, а данные потеряли целостность, что исключает доступ к файлу. Это может произойти, если процесс загрузки файла с расширением DB-WAL был прерван и данные файла повреждены. Загрузите файл снова из того же источника.
3. Проверьте, есть ли у пользователя, вошедшего в систему, права администратора.
Иногда для доступа к файлам пользователю необходимы права администратора. Войдите в систему, используя учетную запись администратора, и посмотрите, решит ли это проблему.
4. Убедитесь, что ваше устройство соответствует требованиям для возможности открытия SQLite
Если система перегружена, она может не справиться с программой, которую вы используете для открытия файлов с расширением DB-WAL. В этом случае закройте другие приложения.
5. Убедитесь, что ваша операционная система и драйверы обновлены
Последние версии программ и драйверов могут помочь вам решить проблемы с файлами SQLite Database Write-Ahead Log Format и обеспечить безопасность вашего устройства и операционной системы. Возможно, что одно из доступных обновлений системы или драйверов может решить проблемы с файлами DB-WAL, влияющими на более старые версии данного программного обеспечения.
Вы хотите помочь?
Если у Вас есть дополнительная информация о расширение файла DB-WAL мы будем признательны, если Вы поделитесь ею с пользователями нашего сайта. Воспользуйтесь формуляром, находящимся здесь и отправьте нам свою информацию о файле DB-WAL.
Wal что за формат
Запись всех « грязных » страниц данных из памяти на диск, которая требуется для контрольной точки, может вызвать значительную нагрузку на дисковый ввод/вывод. По этой причине, активность записи по контрольной точке регулируется так, что ввод/вывод начинается при старте контрольной точки и завершается перед стартом следующей контрольной точки; это минимизирует потерю производительности во время прохождения контрольных точек.
Уменьшение значений checkpoint_timeout и/или max_wal_size приводит к учащению контрольных точек. Это позволяет ускорить восстановление после краха (поскольку для воспроизведения нужно меньше данных), но с другой стороны нужно учитывать дополнительную нагрузку, возникающую вследствие более частого сброса « грязных » страниц данных на диск. Если включён режим full_page_writes (по умолчанию это так), нужно учесть и ещё один фактор. Для обеспечения целостности страницы данных, при первом изменении страницы данных после контрольной точки эта страница записывается в журнал целиком. В данном случае, чем меньше интервал между контрольными точками, тем больше объём записи в журнал WAL, так что это частично дискредитирует идею уменьшения интервала записи, и в любом случае приводит к увеличению объёма обмена с диском
На платформах Linux и POSIX параметр checkpoint_flush_after позволяет принудить ОС к сбросу страниц, записываемых во время контрольной точки, при накоплении заданного количества байт. Если его не настроить, эти страницы могут оставаться в кеше страниц ОС, что повлечёт затормаживание при выполнении fsync в конце контрольной точки. Этот параметр часто помогает уменьшить задержки транзакций, но может оказать и негативное влияние на производительность; особенно, когда объём нагрузки больше shared_buffers, но меньше кеша страниц в ОС.
Так как цель commit_delay состоит в том, чтобы позволить стоимости каждой операции синхронизации амортизироваться через параллельную фиксацию транзакций (потенциально за счёт задержки транзакции), необходимо определить количество той стоимости, прежде чем урегулирование сможет быть выбрано разумно. Чем выше стоимость, тем более эффективный будет commit_delay в увеличении пропускной способности транзакций в какой-то степени. Программа pg_test_fsync может использоваться, чтобы измерить среднее время в микросекундах, которое занимает одиночная работа сброса WAL на диск. Значение половины среднего времени сообщаемого программой рекомендуется в качестве отправной точки для использования значения в параметре commit_delay при оптимизации для конкретного объёма работы, и говорит о том, сколько нужно времени для синхронизации сброса единственной операции записи 8 Кбайт. Настройка параметра commit_delay особенно полезна в случае хранения WAL в хранилище с высокоскоростными дисками, такими как твердотельные накопители (SSD) или RAID-массивы с кешем записи и аварийным питанием на батарее; но это определённо должно тестироваться на репрезентативной рабочей нагрузке. Более высокие значения commit_siblings должны использоваться в таких случаях, тогда как меньшие значения commit_siblings часто полезны на носителях с большими задержками. Обратите внимание на то, что увеличение значения параметра commit_delay может увеличить задержку транзакции настолько, что пострадает общая производительность транзакций.
Включение параметра конфигурации wal_debug (предоставляется, если Postgres Pro был скомпилирован с его поддержкой) будет приводить к тому, что все вызовы связанных с WAL функций XLogInsertRecord и XLogFlush будут протоколироваться в журнале сервера. В будущем данный параметр может быть заменён более общим механизмом.