Падение любой информационной системы — это по умолчанию больно и неприятно. На Хабре вы найдете много статей о том, как этого избежать. Но что делать, если все-таки случилась одна из тех историй, которыми пугают джунов? Уборщица разлила ведро воды в ЦОДе или злосчастный экскаватор перерубил оптоволокно?

Меня зовут Андрей Белый, я старший разработчик VK Cloud в команде DBaaS. В этой статье мы на примере PostgreSQL разберем принципы работы баз данных и поговорим о том, как минимизировать последствия инцидентов с помощью оптимизации RPO (Recovery point objective).

Материал подготовлен по мотивам моего выступления на VK Databases Meetup «Point-in-time Recovery. Как уменьшить RPO для базы данных». 

История жизни одной БД

Один из основных способов защиты баз данных на случай аварий или сбоев — создание резервных копий (бэкапов). Но для каждой стратегии резервного копирования характерна периодичность и интервальность: с точки зрения нагрузок на БД и загруженности памяти для хранения бэкапов нерационально делать копии часто. Это классическая практика, но у нее есть существенный недостаток: в случае аварии любого характера часть новых данных, которая не попала в последний бэкап, неизбежно теряется. Допустимый объем потери определяет параметр RPO (Recovery point objective). 



Любая авария требует времени на восстановление штатной работы БД. Это значение определяет параметр RTO (Recovery time objective).



В результате даунтайм системы и объем потерянных данных фактически зависит от двух величин — RPO и RTO.

Варианты оптимизации RPO

Есть два очевидных варианта уменьшения RPO:

• увеличение частоты создания резервных копий;
  
• репликация БД.
  

На практике оба варианта не идеальны:

• Резервные копии не «бесплатные»: они влияют на производительность дисковой и сетевой подсистем, процессорное время и другие параметры. Исключить это влияние невозможно, поскольку бэкап надо делать на работающей БД, иначе не получится соблюсти консистентность. 
  
• Репликация — средство обеспечения высокой доступности и отказоустойчивости. Но она не исключает необходимость создания резервных копий. Авария может быть не только с точки зрения выхода из строя железа, но и какой-то неаккуратный запрос, которой прилетит и на реплику.
  

То есть варианты не универсальны и не позволяют самостоятельно нативно решить задачу сокращения RPO. Но найти способ улучшения резервного копирования и восстановления все-таки возможно, если на уровне концепций углубиться в процесс записи в базах данных.

Алгоритм записи в БД

Примечание: алгоритм записи будем разбирать на примере PostgreSQL, но другие базы данных имеют такие же концепции. 

База данных состоит из таблиц, которые с точки зрения файловой системы представляют из себя набор файлов. Каждый такой файл состоит из набора страниц, а каждая страница состоит из набора кортежей (таплов). Для простоты мы будем считать, что один кортеж — это одна запись в таблице.



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



Чтобы все процессы могли общаться между собой, используется разделяемая память (shared memory) — общее адресное пространство, к которому есть доступ у всех процессов. В этом участке памяти PostgreSQL хранит самую большую свою структуру — разделяемые буферы (shared buffers).

Алгоритм работы можно отследить по выполнению простого запроса Select к базе:

• запрос попадает в PostgreSQL;
  
• он проверяется и оптимизируется;
  
• PostgreSQL идет на диск и поднимает страницу, в которой содержится нужная запись;
  
• PostgreSQL кладет запись в разделяемые буферы, которые выступают в качестве кэша.
  

Соответственно, если потребуется что-то обновить внутри страницы, PostgreSQL сначала сделает это в памяти.



Но все изменения важно синхронизировать с диском, ведь PostgreSQL — ACID-совместимая база, которая должна гарантировать консистентность данных и изменений.

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

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



Поскольку запись последовательная, на нее надо меньше ресурсов. При этом сразу после записи в файл можно подтверждать коммит — ничего не потеряется. Именно таким файлом является WAL (Write-Ahead Log, журнал предзаписи). 

Что такое WAL

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

Физически WAL представляет собой выделенный объем памяти, который поделен на файлы стандартного размера — 16 Мб. Как только старый файл заканчивается, PostgreSQL создает новый и начинает писать в него. Файл содержит структуры, которые указывают, где и что было изменено. Каждая такая запись имеет уникальный номер — LSN (Log Sequence Number), — который позволяет найти любое изменение. Таким образом, WAL-файл в Postgres также участвует в репликации. 

Чтобы увидеть содержание WAL и найти открытый WAL-файл, достаточно сделать мутирующий запрос и выполнить специальную команду PostgreSQL:



После этого с помощью встроенной утилиты pg_waldump можно прочитать файл. 



Кроме LSN в WAL-файле есть подтверждение вставки  и коммита. При этом каждая запись ссылается на предыдущий LSN — получается непрерывная и последовательная цепочка записей. Таким образом можно отследить отдельно примененные в памяти и записанные на диск изменения. Но в табличном файле они не синхронизированы — в нем пока хранятся старые данные. Нужен процесс синхронизации. 

Синхронизация

В PostgreSQL и других БД синхронизация подразумевает создание checkpoint (контрольных точек). Алгоритм такой:

• в табличных файлах обновляются данные;
  
• создается специальная запись checkpoint в WAL, которая содержит указания на последние изменения, которые входят в этот checkpoint;
  
• PostgreSQL обновляет свою внутреннюю структуру, в которую сохраняет LSN на последнюю успешный checkpoint. 
  

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



Внутри WAL-файла можно увидеть примерно следующее:



Самое интересное здесь — последние записи. Они указывают, что был факт создания checkpoint, и имеют указатель Redo на LSN, который был.   

Примечание: В реально работающей системе между этими записями может быть много других, потому что PostgreSQL не замирает в момент создания checkpoint. 

Восстановление после сбоя

На случай, если изменения зафиксированы в памяти и WAL-файле, но PostgreSQL аварийно выключается и checkpoint не успевает отработать, есть операция для восстановления после сбоя. При старте Postgresql через структуру pg_control определяет что был завершен некорректно и LSN который указывает на последний checkpoint и начинает искать его в WAL. После этого:

• Все, что идет до checkpoint, — уже синхронизировано и записано, поэтому с этими записями PostgreSQL ничего не делает.
  
• А все, что случилось после checkpoint, — принудительно синхронизируется.
  

Как мы все это можем применить?

Итого мы разобрали два механизма применения WAL:

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

Их наличие позволяет заменить постоянное полное резервное копирование базы данных отправкой только WAL-файлов — например, при первой установке БД делать полную резервную копию, а потом отсылать WAL-файлы с информацией обо всех изменениях.



Но ограничиться только отправкой WAL-файлов нельзя. Причин две:

• WAL — это цепочка. Если теряется хотя бы одно звено, будут доступны данные только до места разрыва, а остальное потеряется.
  
• На восстановление из WAL нужны ресурсы. Это сложнее, чем просто скачать бэкап из внешнего хранилища и положить его на диск.
  

Поэтому отправку WAL-файлов оптимально сочетать с периодическим созданием полных резервных копий. 



Такое комбинирование помогает снизить нагрузку на БД и систему в целом, а также уменьшить объем данных, которые потенциально можно потерять в случае сбоев.

Как реализовать в PostgreSQL 

Для использования всего описанного алгоритма в PostgreSQL «из коробки» есть режим архивации WAL. Он настраивается двумя опциями:

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

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

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

Чтобы исключить такие риски, в PostgreSQL есть опция archive_timeout, которая позволяет принудительно делать pg_switchwal, то есть архивировать WAL-файл, если за определенный период времени в нем были изменения. Это кратно снижает риски.

Алгоритм восстановления тоже реализован просто.



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

Также есть группа опций recovery_target. Одни из основных сценариев их использования — возможность откатиться к конкретному времени или к именованной точке, которая присваивается каждой конкретной транзакции. Например, если известно, что TRUNCATE TABLE или DROP DATABASE случился в 15:02, то можно откатиться к 15:01 и продолжить работу с минимальным ущербом для БД и всей системы. 

Благодаря этому такая стратегия резервного копирования и восстановления получила название Point-in-time Recovery, то есть восстановление на произвольный момент времени. Важно, что все этапы Point-in-time Recovery — снятие полных бэкапов по расписанию, отсылку WAL-файлов и другие — в PostgreSQL можно автоматизировать. Для этого можно использовать:

• самописные скрипты;
  
• индустриальные инструменты — например, open-source-решения WAL-G, pgBackRest, pg_probackup.
  

Примечание: Point-in-time Recovery в других БД реализован иначе. Так, в MySQL/MariaDB:

• используется Binlog;
  
• можно делать архивацию по cron;
  
• для восстановления используется mysqlbinlog/mariadb-binlog;
  
• можно автоматизировать с помощью WAL-G.
  

В MongoDB:

• используется OPLog (operational log);
  
• для автоматизации доступны WAL-G (beta) и Percona Backup for MongoDB.
  

Как мы сделали в VK Cloud

В облаке VK Cloud функциональность Point-in-time Recovery уже доступна для СУБД PostgreSQL, реализована возможность восстановления на точку во времени. Такой сценарий работы покрывает 99,9 % случаев. 

«Под капотом» функциональность реализована на WAL-G.

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

Итоги

• Полностью исключить сбои в БД не получится. И даже незначительный отказ на практике может привести к большим проблемам, особенно если данные в БД критически важны и их потеря недопустима.
  
• Создание полных резервных копий — отличный способ повышения надежности хранения данных, но он не панацея, ведь полные бэкапы нерационально делать часто из-за большого потребления ресурсов.
  
• Оптимальный способ снижения допустимого объема потерь данных — комбинировать создание полных резервных копий и WAL-файлов с историей всех изменений. Это снижает риски и позволяет реализовать стратегию Point-in-time Recovery.
  
• Все этапы Point-in-time Recovery можно автоматизировать с помощью самописных скриптов или индустриальных инструментов. В VK Cloud для автоматизации использован WAL-G.
  

Присоединяйтесь к Telegram-каналу «Данные на стероидах». В нем вы найдете все об инструментах и подходах к извлечению максимальной пользы из работы с данными: регулярные дайджесты, полезные статьи, а также анонсы конференций и вебинаров.