У моего клиента довольно большая (общий размер папки «данные» 200 ГБ) база данных PostgreSQL, и мы работаем над планом аварийного восстановления. На данный момент мы определили три различных типа сбоев: отключение оборудования, слишком большая нагрузка и непреднамеренная потеря данных из-за ошибочно выполненной неправильной миграции (например, DELETE или ALTER TABLE DROP COLUMN).
Кажется, что первые два типа легко смягчить, но мы не можем разработать хороший план смягчения для третьего типа. Я предложил использовать ZFS и частые (ежечасные) снимки состояния, но в наши дни «ZFS» означает «OpenIndiana», и наши инженеры Ops не имеют в этом большого опыта, поэтому использование OpenIndiana сопряжено с другим риском. Коллеги пытаются убедить меня, что восстановление из резервной копии PostgreSQL PITR может быть таким же быстрым, как восстановление из моментального снимка ZFS, но я очень сомневаюсь, что воспроизведение, скажем, 50 ГБ заархивированных файлов WAL можно считать «быстрым».
Какие еще варианты нам не хватает? ZFS - единственная жизнеспособная альтернатива? Можем ли мы добиться быстрого восстановления Pg DB в среде Linux?
Я предлагаю вам взглянуть на Barman, Backup and Recovery Manager for PostgreSQL, который был написан нами и доступен как открытый исходный код на условиях GNU GPL 3. Чтобы дать вам представление, мы используем его в производстве для баз данных большего размера, чем ваша (7 терабайт). Версия 1.0 была выпущена в июле. Уже есть версия RPM, пакет Debian готовится (Barman будет включен в Ubuntu 12.10). Чтобы получить больше информации: www.pgbarman.org.
Воспроизведение архивных файлов WAL - лучший вариант и, скорее всего, самый быстрый.
Это лучший вариант, потому что у вас есть полный график. Никакой потери данных. Со всеми типами снимков вы потеряете данные. Ежечасные снимки означают, что в худшем случае вы теряете изменения БД на 1 час (катастрофа происходит непосредственно перед следующим снимком).
Также, если вы выполняете физическое (не логическое - требуется моментальный снимок базы данных, лучше всего для восстановления удаленной таблицы и т. Д.), Восстановление выполняется на уровне блока и ОЧЕНЬ быстро.
Почему FreeBSD не подходит для запуска ZFS и PostgreSQL? Разработчики FreeBSD ZFS очень тесно сотрудничают с командой Illumos, и совсем недавно Павел Якуб Давидек (человек, который первым портировал ZFS на FreeBSD) добавил: Поддержка SSD TRIM для ZFS. Скорее всего, это также скоро будет добавлено в код Illumos ZFS.
Еще одно преимущество FreeBSD и ZFS - это GEOM фреймворк. В Solaris, когда целые диски добавляются в пул ZFS, ZFS автоматически включает их кэш записи. Этого не происходит, когда ZFS управляет только дискретными фрагментами диска, так как он не знает, управляются ли другие фрагменты файловыми системами, не защищенными от записи кешем, такими как UFS. Реализация FreeBSD может обрабатывать сброс диска для разделов благодаря GEOM framework, и поэтому не страдает этим ограничением.