Comments 34
Нет особого смысла хранить архивлоги за большой период. Если только вам не нужно откатиться на заданную минуту в прошлом, тогда пригодятся и снапшоты и архивлоги. Для случаев отставания реплики достаточно периода в несколько дней. Само отставание (в секундах) мониторить можно так
Останавливать базу для создания снапшота необязательно, достаточно выполнить два запроса
и после создания снапшота
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();"
Архив-логи я храню с целью бекапа, позволяет уменьшить частоту полного дампа. Да и смелые эксперименты могут затянутся и приходится догонять несколько дней.
Базу можно и не останавливать, но для данной задачи это не важно, зато так проще и скрипты чище.
Заббиксом конечно же удобнее мониторить в секундах, спасибо за дополнение.
Базу можно и не останавливать, но для данной задачи это не важно, зато так проще и скрипты чище.
Заббиксом конечно же удобнее мониторить в секундах, спасибо за дополнение.
Загрузка полного дампа на больших базах — это последнее средство, когда все плохо. У меня только дамп базы делается несколько дней, загрузка его — раза в полтора-два дольше. А накатывание архивлогов ведется в один поток, и при большом потоке изменений в базе накатить логи за 4 дня займет едва ли не сутки.
В этом случае снапшоты — наше все. Они в случае btrfs практически бесплатные — то есть расходуют только занимаемое место, по объему примерно как сжатые gzip'ом архивлоги. Хранить их можно, пока свободное место позволяет (процентов до 20).
Снапшоты в btrfs — записываемые (вернее, доступен для записи каталог, куда снапшот монтируется). Нет необходимости переводить основную реплику в мастер, можно поднять еще один постгрес (лучше еще один контейнер) на снапшоте и его перевести в мастер. В этом случае не придется нагонять репликацию — у вас всегда будет актуальная реплика, с нее можно снимать дампы (хотя в этом есть нюансы).
В таком сценарии делать снапшоты базы без ее остановки весьма удобно — у вас всегда есть некоторое количество снапшотов, для отката базы или для поднятия тонких копий в качестве девелоперской базы
В этом случае снапшоты — наше все. Они в случае btrfs практически бесплатные — то есть расходуют только занимаемое место, по объему примерно как сжатые gzip'ом архивлоги. Хранить их можно, пока свободное место позволяет (процентов до 20).
Снапшоты в btrfs — записываемые (вернее, доступен для записи каталог, куда снапшот монтируется). Нет необходимости переводить основную реплику в мастер, можно поднять еще один постгрес (лучше еще один контейнер) на снапшоте и его перевести в мастер. В этом случае не придется нагонять репликацию — у вас всегда будет актуальная реплика, с нее можно снимать дампы (хотя в этом есть нюансы).
В таком сценарии делать снапшоты базы без ее остановки весьма удобно — у вас всегда есть некоторое количество снапшотов, для отката базы или для поднятия тонких копий в качестве девелоперской базы
Я не специалист в postgresql, но разве pg_rewind делает не то же самое?
Да, можно и этой утилитой получить подобный результат. Но она так же завязана на WAL логи, которые так же придётся хранить и использовать для восстановления нужного состояния. Вариант со снапшотом мне кажется аккуратнее и прозрачнее.
В статья я старался сделать акцент не столько на инструмент снапшотов, сколько на широкие возможности systemd.
В статья я старался сделать акцент не столько на инструмент снапшотов, сколько на широкие возможности systemd.
Учтя многочисленные возгласы сомнения из зала в стабильности btrfs, дополнил статью вариантом использования pg_rewind.
Как санитизируются чувствительные данные — емейлы, хэши паролей, профили людей?
Не совсем понятно, что имеется в ввиду?
Если сохранность данных, после таких операций — то никак. Тут полностью доверяем механизму надёжности WAL логов PostgreSQL
Если обезличивание данных — то тоже никак :). Сервера полностью под контролем и открытыми каналами данные передаются только в шифрованном виде.
Если сохранность данных, после таких операций — то никак. Тут полностью доверяем механизму надёжности WAL логов PostgreSQL
Если обезличивание данных — то тоже никак :). Сервера полностью под контролем и открытыми каналами данные передаются только в шифрованном виде.
Понятно. Вот так они и сливаются, персональные данные с тестовых баз, по шифрованным каналам.
Здоровая паранойя — вещь полезная, но всё хорошо в меру.
Вероятно, имелось ввиду что девелоперская база находится в DMZ и снаружи недоступна. Непущать разработчиков продакшен базу — в целом здравая идея. Пусть разрабатывают набор начальных данных для заливки на тестовую базу. И на все вопросы отвечают — а у нас все работает ;)
btrfs уже можно использовать?
Давно. Использую как лично, так и на серверах (где применимо). Также Synology по-умолчанию начала применять btrfs.
Для продакшена гонять пока боязно. Но для всяких служебных второстепенных нужд использовать такие возможности как снапшоты и сжатие очень удобно. У меня активно используется в разных вариантах и версиях — проблем пока не возникало.
Для такой поделки наверное можно. Но гонять продакшн на чём то отличном от ext4 и xfs я бы лично не стал.
У меня на личном ноуте покрашилась после отключения питания. Данные слил бэкапом нормально, но запустить обратно саму fs не смог. ubuntu 16.04, ssd, luks partition, btrfs root & home
Применял для одного проекта по нейросетям, обрабатывающем фотографии. Всего было обработано 400,000 изображений (итого 800к — оригиналы и результат), никаких сбоев/проседаний или ещё чего в таком духе не было. Так что да, давно можно.
Ни в коем случае нельзя. Использовал на проде для мультидискового видеохранилища. В итоге начала деградировать скорость записи. Проблема выглядит так: одно из ядер CPU загружено на 100%, драйвер btrfs затыкается в коде поиска свободного блока.
Самое ужасное, что описание проблемы есть в багтрекере btrfs, но там отвечают, что «у меня всё работает, на моём 200МБайтном тестовом разделе ничего не воспроизводится».
Самое ужасное, что описание проблемы есть в багтрекере btrfs, но там отвечают, что «у меня всё работает, на моём 200МБайтном тестовом разделе ничего не воспроизводится».
если это ответ разработчика, то о проекте можно забыть
Нашёл эту переписку: https://bugzilla.kernel.org/show_bug.cgi?id=74761
Уже сейчас есть люди, активно использующие ZFS on Linux на проде, и уже сейчас у ZFS больше шансов. Btrfs это ходячий труп.
Уже сейчас есть люди, активно использующие ZFS on Linux на проде, и уже сейчас у ZFS больше шансов. Btrfs это ходячий труп.
del
А версия FS и утилит?
А какие параметры монтирования?
Так, для общего развития.
А какие параметры монтирования?
Так, для общего развития.
Полгода назад было, уже не найду инфу, к сожалению.
Стоковая ubuntu 16.04 с дефолтными опциями.
Насколько помню, было что-то похожее: ошибки на чтение CRC tree, снимки не монтировались, как ro система не монтировалась, repair и init-csum-tree не помогли…
Стоковая ubuntu 16.04 с дефолтными опциями.
Насколько помню, было что-то похожее: ошибки на чтение CRC tree, снимки не монтировались, как ro система не монтировалась, repair и init-csum-tree не помогли…
UFO just landed and posted this here
Опции монтирования по умолчанию:
Тобишь CoW включён. Специального тестирования не производил, но тестовый сервер с btrfs ведёт себя так же, как и без. Тесты на данных базы проходят быстро и успешно, каких-либо отклонений в производительности в сравнению с сервером базы данных на ext4 не замечено. Восстановление состояния по WAL логам происходит быстро. Если в мастер-базу вносятся глобальные изменения, то порой база на btrfs показывает лучшую успеваемость, чем основная резервная база с ext4. Но я посмотрю внимательно в эту сторону, мало ли.
/dev/pg-slave-test-db on /var/lib/postgresql type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)
Тобишь CoW включён. Специального тестирования не производил, но тестовый сервер с btrfs ведёт себя так же, как и без. Тесты на данных базы проходят быстро и успешно, каких-либо отклонений в производительности в сравнению с сервером базы данных на ext4 не замечено. Восстановление состояния по WAL логам происходит быстро. Если в мастер-базу вносятся глобальные изменения, то порой база на btrfs показывает лучшую успеваемость, чем основная резервная база с ext4. Но я посмотрю внимательно в эту сторону, мало ли.
Предложенную систему можно кстати усовершенствовать:
1) создаём снапшот
2) на снапшоте создаём triggerfile
3) запускаем postgres в docker и указываем ему наш снапшот как volume
4) реплика остаётся репликой (нетронутой), плюс у нас есть база для тестов
5) после тестов просто удаляем снапшот
P.S.> В принципе можно обойтись и без докера, нужно только при старте postgres указать другой port.
У меня была идея сделать что-то подобное пару лет назад, но к сожалению при большом количестве disk writes btrfs вела себя непредсказуемо, вся система периодически замирала, иногда на доли секунды, а иногда до нескольких секунд :(
1) создаём снапшот
2) на снапшоте создаём triggerfile
3) запускаем postgres в docker и указываем ему наш снапшот как volume
4) реплика остаётся репликой (нетронутой), плюс у нас есть база для тестов
5) после тестов просто удаляем снапшот
P.S.> В принципе можно обойтись и без докера, нужно только при старте postgres указать другой port.
У меня была идея сделать что-то подобное пару лет назад, но к сожалению при большом количестве disk writes btrfs вела себя непредсказуемо, вся система периодически замирала, иногда на доли секунды, а иногда до нескольких секунд :(
А как же многочисленные предупреждения, что CoW файловые системы (btrfs, zfs) нельзя использовать как бекенд к базе данных, потому что у БД есть свой слой косвенности?
Sign up to leave a comment.
PostgreSQL slave + btrfs и systemd = горячая тестовая база