LINUX.ORG.RU
ФорумAdmin

Есть ли описание формата wal-сегментов PostgreSQL?


0

1

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

d0 71 00 07
Но сейчас в логе бэкап-агента вижу:
18:15:02 03/07/2013| kissobak.sh[16757/8552]| ERROR| ST=<UNKNOWN>| File pg_xlog/00000001000000A4000000E6 seems to be invalid, because it contains wrong signature

Хорошо, что после выдачи этого сообщения об ошибке работа агента не завершается (по сути уровень сообщения error - задел на будущее, сейчас это должен быть warning).
Теперь вот думаю: а есть ли у wal-сегментов вообще сигнатура эта?
Погуглил формат xlog/wal-файла - так и не нашёл ничего. Может, кто сырцы Postgres'а рыл и может поделиться сакральным знанием?)

★★★★★

Для PostgreSQL 9.2:

$ fgrep XLOG_PAGE_MAGIC /usr/src/postgresql-9.2.0/src/include/access/xlog_internal.h
#define XLOG_PAGE_MAGIC 0xD071  /* can be used as WAL version indicator */
Для PostgreSQL 9.1:
$ fgrep XLOG_PAGE_MAGIC ./src/include/access/xlog_internal.h 
#define XLOG_PAGE_MAGIC 0xD066  /* can be used as WAL version indicator */
Даже и не знаю, радоваться этому или огорчаться... Пока получается, что кроме первого байта «D0», всё остальное может быть равно чему угодно...

DRVTiny ★★★★★
() автор топика

А на каком этапе сегменты могут побиться? Может как-то можно этого избежать?

true_admin ★★★★★
()
Ответ на: комментарий от DRVTiny

Везде разработчики говорят что нельзя полагаться на формат, тк при мажорном обновлении формат wal может измениться.

ventilator ★★★
()
Ответ на: комментарий от DRVTiny

Уж не говоря о том что проверять битость сегмента по однобайтовой сигнатуре просто абсурдно, учитывая что полезных данных в нем 16M. Можете сами посчитать вероятность того что испортится сигнатура.

ventilator ★★★
()

Сегмент - по сути кусок raw data, проверять его правильность по первым нескольким байтам бессмысленно. Единственный нормальный способ проверить его - попробовать его восстановить. То есть завести slave-сервер, восстанавливающийся не по streaming replication, а только из архивированных WAL, и мониторить на нём ошибки.

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

selivan ★★★
()
Ответ на: комментарий от selivan

Я обнаружил, что в wal-сегменте есть поле CRC-суммы. Если её проверить, то с вероятностью 99,9% можно считать, что файл корректный.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

А потом когда в новой версии postgresql сменят алгоритм подсчета чексуммы, снова переписывать вашу проверялку.

ventilator ★★★
()
Ответ на: комментарий от DRVTiny

А если он туда записал неверные данные и к ним посчитал правильную сумму? Единственная объективная проверка - восстановление. Кстати, а из чего возникла проблема? В какой конфигурации удалось получить битые WAL-сегменты?

selivan ★★★
()
Ответ на: комментарий от selivan

Проблема скорее в том, что вообще к тому, что пытаются сохранить на удалённый сервер, особого доверия нет. Это не проверка на битость, это проверка на ошибки в тех скриптах, которые используют бэкапер в качестве бэкенда.
Проще говоря, если делается save_xlog какого-нибудь левого файла, мы его не должны пересылать. А как понять, левый он или нет? Должна быть какая-то характерная сигнатура. Имя файла там же проверяется чуть раньше :)

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

Эммм... archive_command postgres сам дёргает, как оно может что-то левое скопировать? Странно всё это

selivan ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.