DevOps
Database Administration
Data recovery
Configuring Linux
System administration
Comments 34
+1
Нет особого смысла хранить архивлоги за большой период. Если только вам не нужно откатиться на заданную минуту в прошлом, тогда пригодятся и снапшоты и архивлоги. Для случаев отставания реплики достаточно периода в несколько дней. Само отставание (в секундах) мониторить можно так
select extract(epoch from now() - pg_last_xact_replay_timestamp())::integer

Останавливать базу для создания снапшота необязательно, достаточно выполнить два запроса
psql -U pgsql postgres -t -A <<EOT
SELECT select pg_xlog_replay_pause();
CHECKPOINT;
EOT

и после создания снапшота
psql -U pgsql postgres -t -A -c "select pg_xlog_replay_resume();"


0
Архив-логи я храню с целью бекапа, позволяет уменьшить частоту полного дампа. Да и смелые эксперименты могут затянутся и приходится догонять несколько дней.

Базу можно и не останавливать, но для данной задачи это не важно, зато так проще и скрипты чище.

Заббиксом конечно же удобнее мониторить в секундах, спасибо за дополнение.
0
Загрузка полного дампа на больших базах — это последнее средство, когда все плохо. У меня только дамп базы делается несколько дней, загрузка его — раза в полтора-два дольше. А накатывание архивлогов ведется в один поток, и при большом потоке изменений в базе накатить логи за 4 дня займет едва ли не сутки.

В этом случае снапшоты — наше все. Они в случае btrfs практически бесплатные — то есть расходуют только занимаемое место, по объему примерно как сжатые gzip'ом архивлоги. Хранить их можно, пока свободное место позволяет (процентов до 20).

Снапшоты в btrfs — записываемые (вернее, доступен для записи каталог, куда снапшот монтируется). Нет необходимости переводить основную реплику в мастер, можно поднять еще один постгрес (лучше еще один контейнер) на снапшоте и его перевести в мастер. В этом случае не придется нагонять репликацию — у вас всегда будет актуальная реплика, с нее можно снимать дампы (хотя в этом есть нюансы).
В таком сценарии делать снапшоты базы без ее остановки весьма удобно — у вас всегда есть некоторое количество снапшотов, для отката базы или для поднятия тонких копий в качестве девелоперской базы
0
Да, инструмент снапшотов мне тоже очень нравится. Активно его использую. А ещё классная вещь — сжатие btrfs. Раздел данных логов в elasticsearch занимает раза в полтора меньше места.

0
Да, можно и этой утилитой получить подобный результат. Но она так же завязана на WAL логи, которые так же придётся хранить и использовать для восстановления нужного состояния. Вариант со снапшотом мне кажется аккуратнее и прозрачнее.
В статья я старался сделать акцент не столько на инструмент снапшотов, сколько на широкие возможности systemd.
0
Учтя многочисленные возгласы сомнения из зала в стабильности btrfs, дополнил статью вариантом использования pg_rewind.
0
Как санитизируются чувствительные данные — емейлы, хэши паролей, профили людей?
0
Не совсем понятно, что имеется в ввиду?
Если сохранность данных, после таких операций — то никак. Тут полностью доверяем механизму надёжности WAL логов PostgreSQL
Если обезличивание данных — то тоже никак :). Сервера полностью под контролем и открытыми каналами данные передаются только в шифрованном виде.
0
Понятно. Вот так они и сливаются, персональные данные с тестовых баз, по шифрованным каналам.
0
Дело не паранойе и не в мере, а в том, сколько бизнес потеряет при сливе копии. В некоторых случаях, такие копии прямо запрещены регулятором. Вы предложили решение проблемы, это замечательно. Я всего лишь уточнил применимость решения.
0
Вероятно, имелось ввиду что девелоперская база находится в DMZ и снаружи недоступна. Непущать разработчиков продакшен базу — в целом здравая идея. Пусть разрабатывают набор начальных данных для заливки на тестовую базу. И на все вопросы отвечают — а у нас все работает ;)
0
Разработчики и без базы так отвечают. Могут и тест емейл-рассылки запустить. Всякое бывает. Вопрос был по применимости решения. Он отвечен. Похожее решение я делал с санитизацией, например. Но то вне рамок данной статьи.
0
Давно. Использую как лично, так и на серверах (где применимо). Также Synology по-умолчанию начала применять btrfs.
0
Для продакшена гонять пока боязно. Но для всяких служебных второстепенных нужд использовать такие возможности как снапшоты и сжатие очень удобно. У меня активно используется в разных вариантах и версиях — проблем пока не возникало.
+1
Для такой поделки наверное можно. Но гонять продакшн на чём то отличном от ext4 и xfs я бы лично не стал.
0
У меня на личном ноуте покрашилась после отключения питания. Данные слил бэкапом нормально, но запустить обратно саму fs не смог. ubuntu 16.04, ssd, luks partition, btrfs root & home
0
Применял для одного проекта по нейросетям, обрабатывающем фотографии. Всего было обработано 400,000 изображений (итого 800к — оригиналы и результат), никаких сбоев/проседаний или ещё чего в таком духе не было. Так что да, давно можно.
0
Ни в коем случае нельзя. Использовал на проде для мультидискового видеохранилища. В итоге начала деградировать скорость записи. Проблема выглядит так: одно из ядер CPU загружено на 100%, драйвер btrfs затыкается в коде поиска свободного блока.

Самое ужасное, что описание проблемы есть в багтрекере btrfs, но там отвечают, что «у меня всё работает, на моём 200МБайтном тестовом разделе ничего не воспроизводится».
-1
если это ответ разработчика, то о проекте можно забыть
+2
У ZFS-on-Linux нет предпосылок к успеху. Я столкнулся с тем, что ARC cache отображается в used memory, низкая производительность и деградации как следствие.
Т.е. при всём моём уважении к ZFS, он создавался не для этой OS.
0
А версия FS и утилит?
А какие параметры монтирования?
Так, для общего развития.
UFO landed and left these words here
0
Опции монтирования по умолчанию:
/dev/pg-slave-test-db on /var/lib/postgresql type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)

Тобишь CoW включён. Специального тестирования не производил, но тестовый сервер с btrfs ведёт себя так же, как и без. Тесты на данных базы проходят быстро и успешно, каких-либо отклонений в производительности в сравнению с сервером базы данных на ext4 не замечено. Восстановление состояния по WAL логам происходит быстро. Если в мастер-базу вносятся глобальные изменения, то порой база на btrfs показывает лучшую успеваемость, чем основная резервная база с ext4. Но я посмотрю внимательно в эту сторону, мало ли.
UFO landed and left these words here
0
Предложенную систему можно кстати усовершенствовать:
1) создаём снапшот
2) на снапшоте создаём triggerfile
3) запускаем postgres в docker и указываем ему наш снапшот как volume
4) реплика остаётся репликой (нетронутой), плюс у нас есть база для тестов
5) после тестов просто удаляем снапшот

P.S.> В принципе можно обойтись и без докера, нужно только при старте postgres указать другой port.

У меня была идея сделать что-то подобное пару лет назад, но к сожалению при большом количестве disk writes btrfs вела себя непредсказуемо, вся система периодически замирала, иногда на доли секунды, а иногда до нескольких секунд :(
0
А как же многочисленные предупреждения, что CoW файловые системы (btrfs, zfs) нельзя использовать как бекенд к базе данных, потому что у БД есть свой слой косвенности?
0
Поставленные цели сборка выполняет отлично. А поведение btrfs под базой данных и базы данных на btrfs буду наблюдать, на то он и тестовый стенд.
Only logged in users are able to leave comments. , please.