Как стать автором
Обновить

Комментарии 95

Правильно понял суть, что пришлось залезть в душу сервера и всё перелопатить, а в итоге самым правильным и простым решением оказалось накатить актуальные обновления?

Тут всё же важно сфокусироваться на правильной последовательности действий:

  1. Залезли в душу сервера - нашли источник проблемы.

  2. Проверили трекер ФС - нашли исправление.

  3. Накатили исправление - получили профит.

Гораздо прискорбнее видеть, как люди в попытке исправить проблемы пытаются "сэкономить время" на шаге 1. Обновим подсистему Х! Помогло? Ой, не помогло. Обновим подсистему Y! Помогло? Ой, не помогло. И так повторять до бесконечности. Либо картинно развести руками: ох, какая сложная проблема, совсем ничего не помогает!

Симптомы бывают одни, а реально болит в совсем другом месте. И да, много проблем решается обновлением того или иного. Но чтобы найти что обновлять (а вариантов тут может быть слишком много включая железо), придётся разобраться в деталях происходящего. На первый взгляд описание тикета ZFS не имеет ничего общего с симптомами в PostgreSQL, а вот как оно вышло.

А почему был сделан выбор в пользу ZFS, а не BTRFS, который тоже вроде как умеет в копирование при записи? Интересно, там может быть такая же проблема с NUMA? Или куча других неожиданных нюансов?

Потому что БТР по сути заброшен. Красная шапка от него отказалась насколько помню. Реализации RAID5/6 там если и завезли то недавно. Ну и были кейсы с потерей данных.

Тот же ZFS в линуксе юзаю ещё со времён FUSE моделей лет 10 назад и потерь данных ни разу не было.

RedHat одновременно и от ZFS отказались )

Как понимаю, продвигают альтернативу - некий Stratis...

За ZFS они никогда и не топили, особенно учитывая что лицензия CDDL не даёт его в ядро включить уже много лет. И не факт что эта проблема решится...

А Stratis это не файловая система, а попытка реализовать часть фич ZFS используя текущие подсистемы ядра и не только (XFS/LVM/DM/LUKS/...) и обернуть это всё удобным CLI/API

The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux.

The Btrfs file system did receive numerous updates from the upstream in Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise Linux 7 series. However, this is the last planned update to this feature.

(с) https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.7_release_notes/deprecated_functionality

Я не говорю что она не развивается, но в RHEL на ней судя по всему поставили крест.

То, что BTRFS стала дефолтной рутовой ФС в Федоре, говорит о то, что этому суждено измениться, а Оракл в своей системе, основанной на красношляпе и так рекомендует BTRFS: https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Btrfs-UEK6

Ну, хорошо что кто-то за него топит, особенно учитывая что BTRFS как и ZFS родился внутри Оракла.

Ну и монополия по фичам ZFS наверное не играет ему на пользу. Если BTRFS догонит его (или уже?) то всем от этого будет только лучше - часто полезные фичи и идеи тянут друг у друга.

То, что BTRFS стала дефолтной рутовой ФС в Федоре, говорит о то, что этому суждено измениться

Я бы на самом деле не был так уверен. Федора всё же десктопный дистриб более, вот если они в CentOS это завезли то наверное уже какой-то знак...

>> ZFS родился внутри Оракла
ЛОЛ) ZFS родился внутри Sun, большую часть которого похоронил Оракл.
Если бы Sun не выпусил свои наработки в опенсорс, все это так и осталось бы закрытом. И та же JDK осталась бы узконишевой проприетарной платформой, а не стала стандартом бэка.

Согласен, просто я уже давно отождествляю Sun и Oracle т.к. слияние произошло так давно.

А почему был сделан выбор в пользу ZFS, а не BTRFS

Так BTRFS вышла в production-ready дай боже года три назад, а OpenZFS (ранее -- ZFS on Linux и собственная адаптация на FreeBSD) стабильна уже больше десяти лет. И ZFS намного фичастее. Опять же, я пока не видел примеров больших (сотни и тысячи TB) разделов с BTRFS. Как она себя вести будет, чёрт её знает.

Тот, кто знает, как жрёт RAM'у ZFS (by design, кстати говоря, не говоря уж про какой-нить dedup, упаси вас сила интернета включать его!), на сотнях и тысячах терабайт её запускать не будет. А тот, кто запустит, узнает. )

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

О, ну ZFS -- это вообще не про производительность. Во всяком случае на куче мелких файлов. Я в 2013, выбирая ФС под хранилище Zoneminder (он тогда видео хранил в виде отдельного JPEG'а на каждый кадр), погонял разные варианты и ужаснулся тому, насколько же ZFS on Linux тормозной на этом сценарии. Выиграл ReiserFS (правда, через пару лет пришлось сменить на EXT4 с отключённым журналом, потому что ReiserFS стала нестабильной на Ubuntu).

Не всё так однозначно. Просто CoW имеют свою специфику, её нужно понимать, и знать, где они хороши, а где — так себе. В частности, они уменьшают seek'и при записи, что для HDD просто прекрасно. Но это не решает проблему seek'ов при чтении, конечно же, а фрагментация растёт быстро, и неумолимо. И это не единственная проблема, конечно.

Ну строго говоря часть проблем с 2018 года были решены.

L2ARC уже персистентный как минимум.

С удалением vdev из raidz и его расширением тоже подвижки были, не помню в каком оно состоянии, но по-моему в 2.2 будет.

Ресильвер последовательный тоже решил проблему ребилдов (в обычном рейде ты вообще весь диск заливаешь с нуля, а тут только занятые блоки).

Ну и так далее... в любом случае - альтернатив никаких нет :)

>> Выиграл ReiserFS

На единичном диске ReiserFS так и остается лучшей системой.

$ zpool list
NAME      SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
storage   300T   286T  13.7T        -         -    56%    95%  1.00x  ONLINE  -

И таких хостов много. И, поверьте, легко потянет и петабайт. Головой просто надо пользоваться - и будет ок.

А (бесплатных) альтернатив у ZFS просто нет. Какой бы она ни была. Ну вот такова реальность.

бгг. Мне тут особенно колонка FRAG нравится. А пул-то, ведь, не такой уж и старый, да? А дефрага нет, и не будет. Ну и забивка 95 % слабо стыкуется с лозунгом дружбы с головой. В большинстве случаев те, кто дружат с головой, ставят на такие (и бОльшие) объёмы CEPH. Прочие же только думают, что дружат. )

Мне тут особенно колонка FRAG нравится. А пул-то, ведь, не такой уж и старый, да? А дефрага нет, и не будет.

Здорово, что вам нравится FRAG ! Я думаю, это отличный повод почитать, что же она таки означает ;-)

А байки-бабайки про фрагментацию оставьте детей пугать. Ах, да, там же дальше еще байка-бабайка про 95% заполненного пула... Ну давайте.

Ну и забивка 95 % слабо стыкуется с лозунгом дружбы с головой.

Слабо стыкуется только воинствующее незнание и работа сложных систем. А еще вера в байки, астрологию, арбидол и тп =)

ставят на такие (и бОльшие) объёмы CEPH.

Сравнивать тёплое и мягкое - очень весело и забавно, но, если не возражаете, мы с вами на этом завершим.

И, поверьте, легко потянет и петабайт.

Дался вам этот петабайт — вот система (у того же Мотина, кстати), где таких петабайтов 20, и 1248 дисков в одном пуле: "… This particular system is about capacity -- ~20PiB raw on 1248 disks in one ZFS pool. …".

Посчитаем, сколько должно быть RAM для обслуживания такого пула, если исходить из правила «1 TB дискача — 1 GB рамы» — ?

Посчитаем! Для массива с 1 PiB (сырых) — 1 TiB RAM'ы. А там, напоминаю, 20 их.

Нет никаких требований "Х ОЗУ на ТБ", это тот же кеш, как и в любой другой ФС. Хотите держать больше кеша - увеличиваете его. В памяти нужна только мета - отдайте ей гигабайт 10 хоть на 10 петабайт и всё.

Хотите экономить и страдать на любой ФС - задушите её по памяти, в ZFS никто вам этого не мешает сделать.

Во, да, узнаю фанатов — «задушить можно, лол, любую файловую систему». Весь прикол в том, что ZFS вы задушите там, где XFS будет дышать полной грудью. )

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

Xfs на петабайты чудесным образом работает без кеша метаданных? И её мета из lru кеша не вымывается тем же чудом?

Расскажите, пожалуйста, как без озу держать петабайты и дышать полной грудью на какой-то ФС.

А вы думаете, что требования к RAM у XFS и ZFS одинаковы что ли, лол

И если кэшем файловых данных зачастую можно пренебречь, то внутренние структуры самой файловой системы, так просто из песни не выкинешь.
В zfs можно отказаться от кеширования непосредственно файлов и оставить только метаданные через primarycache=metadata. Потребление ОЗУ тогда будет ничтожным, по сравнению со стандартным all.

В zfs можно отказаться от кеширования непосредственно файлов

Да можно, конечно, и отказаться. Более того, как я уже писал (вообще говоря, я использовал ZFS в Solars, FreeBSD и Linux), если включить primarycache=metadata, то и в L2ARC можно будет максимум только их (metadata) и получить. Кстати, надо было бы там упомянуть ещё и про неоптимальный расход диска при ashift=12, может допишу. ;-)

Ну так вот — если вспомнить о чём тут статья была, то она про Postgresql. Который (в отличие от MySQL's InnoDB) крайне полагается на кэш файловой системы, и для него рекомендация «отключить» будет означать жёсточайшую просадку производительности.

Вы recordsize 8k/16k когда-нибудь пробовали применять, например? В курсе, что для баз данных (и не только) это типичная рекомендация, потому что иначе будет дичайший write amplification? А в курсе, что будет происходить с потреблением памяти, когда терабайтный пул таких вот "8k" будет основательно заполнен? И да, я сейчас не про ARC, как тут некоторые пионеры вообразили.

Ну и как бы тут кто-то не пытался жопкой крутить, а зверский 1/4 RAM (ЕМНИП), как минималка ARC по-умолчанию, неспроста стоит. Потому что, опять же, иначе производительность пулов будет устраивать только пионерские файлопомойки, которыми они гордятся на хабрике. )

Жрёт безумно, да. К примеру у меня на домашней файлопомойке при 16Тб места ажно 512М под ARC отрезано. И то с запасом так, от души. На серверах под ARC позволено забирать гораздо больше из расчета на терабайт, но всё равно чот не хочет жрать как не в себя.

К примеру у меня на домашней файлопомойке при 16Тб места ажно 512М под ARC отрезано

Ну если ARC — это единственное, о чём хватает тяму рассуждать по теме использования памяти ZFS, то тут остаётся засвидетельствовать лишь потрясащей в своей убогости уровень (не)знаний, и порекомендовать хотя бы `slabtop` на свой файловой помойке запустить.

А потом сходить поплакать.

А давайте таки о нормальном функционировании говорить, а? А то я багов могу таких на любую ФС ведрами накопать, тем более с единичными жалобами, на больших массивах и для версий двухлетней давности.
не говоря уж про какой-нить dedup, упаси вас сила интернета включать его!

а что не так с дедупликацией? просто нужно понимать применимость принятого в zfs подхода.


вот пример с реального сервера:


 dedup: DDT entries 9863796, size 715B on disk, 230B in core

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    5.10M   20.4T   4.12T   3.86T    5.10M   20.4T   4.12T   3.86T
     2    1.94M   7.76T   3.35T   3.13T    4.71M   18.8T   7.64T   7.15T
     4     535K   2.09T    626G    586G    2.79M   11.2T   3.14T   2.94T
     8     311K   1.21T    399G    373G    3.30M   13.2T   4.30T   4.02T
    16     967K   3.78T    931G    872G    26.1M    104T   25.0T   23.4T
    32     591K   2.31T    539G    506G    21.5M   85.8T   20.0T   18.7T
    64    20.6K   82.3G   24.6G   23.0G    1.71M   6.86T   2.10T   1.97T
   128    1.89K   7.57G   4.40G   4.11G     306K   1.19T    699G    653G
   256      223    892M    683M    638M    77.1K    308G    235G    219G
   512       39    156M   47.4M   44.3M    25.5K    102G   30.9G   28.9G
    1K       13     52M   22.2M   20.8M    20.1K   80.2G   35.1G   32.8G
    2K       33    128M   46.9M   43.9M    99.2K    388G    145G    136G
    4K        4     16M   6.11M   5.71M    20.8K   83.2G   32.7G   30.6G
 Total    9.41M   37.6T   9.93T   9.30T    65.7M    263T   67.4T   63.1T

таблица дедупликации занимает в памяти 9863796 ⋅ 230 ≈ 2 ГБ, экономит более 50 ТБ на дисках.

как CoW файловые системы помогут с бакапами если основной ее потребитель — база данных, которую неправильно копировать на живую средствами файловой системы?

что происходит если берется снапшот CoW для файлов базы данных, postgres как то гарантирует что данные не будут потеряны?

у баз обычно журналы есть. Поэтому по-факту будет откат до последней консистентной «версии», с который можно дальше догонять мастер, при желании.

Копирование на живую - это не атомарная операция, в отличии от взятия снэпшота и отката.

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

я говорю про то что для восстановленной из копии базы данных, если копирование было на уровне файлов — равнозначно запуску после аппаратной перезагрузки по reset, у CoW систем есть конечно бонус, защищающий данные от сбоев, но речь о вероятностях а не о гарантиях

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

ZFS CoW снепшот атомарен, моментален, не вызывает деградации производительности и не требует больших расходов. Гарантии есть.

В чём плюс такой схемы с ZFS снепшотам, что можно восстановиться на любой момент времени. Выбирается точка во времени, откатывается на снепшот перед точкой, а потом добираются WAL-ы которые лежат в следующем снепшоте. И делается recovery.

А и про бекапы - снепшоты инкрементально отправляются в СРК или на реплику ZFS-а через zfs send/receive. То есть можно держать 100500 снепшотов в СРК, а на мастере хранить за последние сутки.

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

wal_archive/wal_recieve + PITR позволяют перематывать состояние реплики, разве нет?

Про деградацию производительности — она там изначально, by design. Просто выглядит это обычно как небольшой налог, по сравнению с non-CoW, поэтому он до поры-до времени фанатами^W энтузиастами не замечается, а потом, бац — и приходит понимание, что за всё нужно платить. )

И я понимю, почему у зэтки так много фанатов среди пользователей BSD — просто у них файловой системы нормальной никогда не было. ) UFS традиционно тормоз, вторая версия, конечно, получше, но всё же даже не EXT4, и не XFS. Хаммерфс, Дилоном запиленный, вообще мало кто помнит (а он есть). Так что не, ZFS, конечно, ничё так, местами, но высоконагруженные базы данных это не её конёк.

<бгг>В вашем ответе, что характерно, конкретики не просто не хватает, её там просто нет вообще. В отличие от текста по ссылке.</бгг>

Ну так профактчекайте, вместо selection bias, статью.
Но это ж лень, это ж думать надо матчасть изучать. Сотни <бгг></бгг> не будут написаны! ;)

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

Замкнутый круг.
Вообще, пожалуй, этому стоит поблагодарить poige за пару минут здорового смеха. Все-таки, попикасту про NTFS все уже забыли: ту, в которой рекомендовалось отключать загрузку драйвера ntfs.sys, чтобы сэкономить 2 мегабайта памяти (особенно актуально для Vista и старше =) ). Последний раз она попадалась на глаз года три-четыре назад, и то: то ли на пикабу, то ли вообще на дётичке.

<бгг2>Пока всё как обычно — фанатики так и не осилили опровергнуть ни один из перечисленных в статье "ZFS is RAID5 of 2010s" тезисов, и пламени из заднеприводных сопел хватило только на обсуждение «человеческих нюансов», коих у себя они никогда заметить не были способны.</бгг2>

А нам незачем опровергать. Мы в курсе текущего состояния дел, вы — нет, но вам и не нужно. Какой смысл пересказывать общедоступную информацию в принципе, а тем более пересказывать тому, кому не интересно?

Трамвайный хам,
Админ куберов локалхоста
Матчасть не чёл
Но и не мог молчать, ведь
Три дня бежал он
Чтоб кричать вдогонку
"Смердит не от меня!"


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


  • Dedup. Результаты тестов где? Нету. Хотя бы умозрительные рассуждения зависимости размера DDT от volblocksize/recordsize, хоть что-нибудь, что выдало бы знание матчасти и/или фактический опыт? Нету. Бессмысленный вопль — есть. И что же тут предполагается опровергать?
  • persistent L2ARC — вошло в 2.0, но об этом-то знают не только лишь все. Чего тут обратно опровергать?
  • Reliability degradation on pool extension — поржал. А, типа, если вы решите собрать 0 из 5 и 6 — то все будет зашибись. Про расширение пула заменой дисков в онлайне вы скромно умолчали — цель-то была обгадить, а не в матчасти ковыряться.
  • Recovery time Ну и от чего же оно зависит, а? Правильно, не от размера дисков, а от количества занятого места — спасибо голосу из зрительного зала! Кстати, там в 0.7, 0.8 и 2.0 навалили мешок оптимизаций в это дело — но это уже zpool_v5000 feature flags, а статья про zpool_v28.
  • 4k drives poor support — еще смешнее, особенно, если развернуть утверждение. Потому что получится назло мамке отморожу уши буду использовать ashift=9 вместо 12 и страдать, потому что иначе не сказать, что zfs плохая!11адынадын. Т.е. вы и сами отлично понимаете "актуальность" этого пункта.
  • Single host FS — если это недостаток, то где статьи того же автора с таким же пунктом, обличающим xfs, extN, f2fs, reiserfs и прочих? А нетути! Снова мимо, та шо ж такое.

Всего один, видимо, случайно затесавшийся, справедливый пункт: отношение ARC/L2ARC к primary_cache=metadata. И то, и над этим ведутся работы.
Ну и что в этой коллекции лулзов и некомпетентности изобличать, право?
Разве что агрессивное хамье с лексиконом нифаната с 3Dnews.

Оно… которое тут пыжится в стишки, и при этом, слово «нюанс» с мягким знаком пишет. Ты убого ровно настолько, что убогость твоя не позволяет этого понять. Да и статью на английском, лишь частично.

ОК, я так спрошу -- вы пробовали средствами самой БД бэкапить 180Тб?

Прошу прощения за глупый вопрос. Если снапшотом снимать копию с постгри во время работы - копия будет консистентна? Белые люди так делают?

Делают.
Но database files и wal files должны быть в одном датасете.


Механизм, как этот понял, примерно таков:
Снепшот снимается всегда по границе транзакции, которая, в свою очередь, ограничена вызовом fsync. Если для БД выделен отдельный датасет, в который больше никто не пишет, то в момент снятия снепшота вы получаете консистентное состояние файлов с точки зрения самой БД (если не отключили в ней использование fsync, конечно).
Но даже если нет, все, что упало в wal, доиграется при запуске, а то что упало не до конца — будет отброшено.

Спасибо. А то собирал скриптами инструмент, который позволяет держать почасовые копии постгри почти так же удобно как MSSQL. Правда под винду. Сейчас запланировал переход на постгри на линуксе, а тот в свою очередь находится на zfs (lxc, чтобы избежать лишних слоёв виртуализации). Снапы поудобнее, чем ловить этот WAL. Попробую, в общем.

WAL можно ловить каким-нибудь syncthing даже.
А бинарную репликацию, кстати, не пробовали?

Не пробовал. Гугл тоже не в курсе, что за "бинарная репликация postgresql"
Может есть какие-то иные названия?

Нашёл. Это физическая. Да, пробовал. Без неё не знаю как ещё делать почасовые копии. Меня весь этот механизм удручает. А именно держать разные базы в разных службах Postgres для того, чтобы вести почасовые копии какой-то одной базы. Либо все базы будут в твоей копии, либо делай логическую. Я для себя пришёл к выводу, что просто надо заводить несколько постгресов под разные базы, и рисовать какую-то управлялку.

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

Да, она.
Тоже пришли к такому выводу: пока поднимаем дополнительные инстансы, по одному на базу.
Отдельно складываем снэпшоты zfs: суточный полный и диффы от него.

fsync тут ни при чём.
как только приложение сказало write, данные попали в цепкие лапы файловой системы. даже если они ещё не записаны на накопитель, файловая система уже работает с новой версией данных.
соответственно, снапшот неконсистентным быть не может (если, разумеется, в самой БД не накосячили).


fsync же нужен чтобы гарантировать консистентность данных на накопителе в случае внезапного отключения питания/ребута (в тот промежуток времени, когда данные уже были переданы фс, но только частично записаны на накопитель, из-за переупорядочивания операций можно словить разные любопытные эффекты)

Этот имел ввиду, что при работе БД fsync будет вызываться чаще, чем таймер сброса данных в транзакцию zfs.


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

Вызванный же на рабочий каталог fsync сообщает системе, что текущее состояние должно быть сброшено на диски — и управление вернется после того, как все слои хранилища отрапортуют об успешной записи, — разве нет?

так. но причём тут снапшоты? на них fsync никак на влияет

ЕМНИП, если не вырублен sync на датасете, то будет сформирован и выгружен txg, формируя новое консистентное состояние на диске. А снэпшот, являясь консистентным слепком, выдет выровнен во временной линии по этому состоянию.


Впрочем, и с sync=disabled оно будет так же, просто не все данные доедут сразу.

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

Реплика это не бэкап. Если кто-то сделает `DELETE FROM table` то реплика радостно это исполнит и данных не будет нигде.

отвечу вам обоим
я отлично понимаю что такое снапшоты, юзаю их давно с btrfs, и прекрасно знаю чем чреват master-slave репликация

просто я пользуюсь ими обоими, останавливаешь slave базу, делаешь снапшот файловой файловой системы где она лежит, запускаешь базу — репликация подтягивает накопивушюся разницу (в основном время тут — остановка базы чтобы завершить транзакции), в результате у тебя бонусы инкрементальных снапшотов (а btrfs их позволяет складывать в файл и использовать потом — дико удобно) и гарантия консистенции базы для ее восстановления

Вы про какую базу сейчас вещаете? В случае той же InnoDB, достаточно взять Percona XtraBackup (или её MariaDB'шное подобие) и безо всяких дисковых snapshot'ов получить и консистентый полный снимок базы, и инкрементальные понаделать.

Что не означает, что нельзя на Btrfs держать. Можно. Просто это значит, что этот setup больше про удобство, чем про быстродействие базы.

Пока у вас мелкая ненагруженная база, вам и sql dump в текстовый файлик покатит. А вот когда у вас база размером в X терабайт, то бэкапить силами инструментов типа xtrabackup — смерти подобно. У вас бэкап сниматься будет дольше требуемого бизнесом интервала между этими самыми бэкапами. А уж держать под оперативные бэкапы сторадж размером X Тб * N копий, да приплясывать пока такой бэкап копируется назад в случае необходимости — вообще космос.

А вот когда у вас база размером в X терабайт, то бэкапить силами инструментов типа xtrabackup — смерти подобно.

\@

Для этого в «инструментах типа» есть режим инкрементального бэкапирования. Вы когда уже доки будете читать, вместо того, чтобы публиковать тут скудоумие своё(?)…

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

Именно. Так что RTFM. Да и вообще READ, ибо вон там выше, прежде, чем пыжиться отвечать на мой коммент, на который вот так вот получилось частично обгадиться, нужно открыть зенки пошире и узреть «Что не означает, что нельзя на Btrfs держать. Можно. Просто это значит, что этот setup больше про удобство, чем про быстродействие базы.»

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

Не надо OLTP решение использовать для аналитики. 180Тб уже стоит запихать в приспособленное для этого решение, коих масса.

ребята продают поддержку Postgres
странно от них ожидать рекомендацию использовать Clickhouse, Vertica, etc

Ну, тут не о них речь, а о некоем клиенте который такую схему придумал. Хотя может это они ему посоветовали, конечно...

В первую очередь не надо БД (не так важно какую) ставить на ФС с COW. Сама БД обеспечивает консистентность путем избыточной записи на диск. Добавляем сюда файловую систему на своем уровне обеспечивающую консистентность путем добавочной нагрузки на диски. А дополнительная нагрузка должна получаться нехилая - БД постоянно меняет одни и те же блоки, ФС старательно сохраняет все их версии. Postgres дополнительно еще сверху проходится autovacuum'ом еще раз меняя блоки и заставляя ФС писать их новый версии. Стоит ли такой оверхэд удобной возможности откатиться на некий снэпшот в прошлом?

Oracle не зря в свое время выпускала версию вообще без ФС - с прямым управлением дисками. БД в любом случае лучше знает что как и когда писать на диск, чем сторонний софт общего назначения.

Спасибо, интересный документ, полистал с удовольствием.

Возможность сделать тестовый снэпшот рабочей базы минимальными затратами ресурсов очень привлекательна

Samsung делает свой key-value ssd c фронтом RocksDB

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

Контроллер SSD это еще один слой абстракции, влияющий на общую производительность, такая себе ФС на железе. В целом время записи на SSD сильно меньше чем на HDD, но у SSD временами случаются существенные просадки скорости записи (перераспределение данных в сценарии когда мы циклически пишем/стираем данные) На этот случай оракл в экзадата придумали достаточно оригинальное решение - данные параллельно пишутся на HDD и SSD, транзакция считается завершенной по факту успешной записи на тот или иной диск, какой быстрее успеет записать.

кстати такое поведение можно настроить на блочном устройстве linux bcache (writeback mode), очень удобно

>Её можно откатывать к предыдущим состояниям, так что можно даже обходиться без бэкапов

Феерично. На полуэкспериментальной FS без бэкапов. Данные должна жать и бэкапить СУБД.

На самом деле никогда не поверю, что нужно реально строить отчёты по 180ТБ. Вот прямо сразу по всем 180ТБ... Насколько знаю наша ERP (системообразующего предприятия) в несколько раз меньше занимает.

Феерично. На полуэкспериментальной FS без бэкапов. Данные должна жать и бэкапить СУБД.
Если это база для анализа объединенной аналитики, то все данные получаются дублированы в отдельных базах и потеря этой аналитической базы может быть легко восстановлена из них. То есть исходные базы откуда сливают фактически и являются бэкапом интегрированной.
Базы нешуточные: две базы, в каждой по 180ТБ. В них сливаются данные из многих других, непостгресовых баз. А этими, огромными напрямую пользуются аналитики компании, и эта деятельность критически важная.

Ну, справедливости ради ZFS крайне стабилен и проблем с ним очень мало если использовать с умом. Использую его 10+ лет уже.

А аналитика по OLTP базе такого объема... да, идея сильно так себе. Кликхаус или Вертика решает с таком случае.

ZFS сжала эти базы в два раза — теперь каждая занимает на диске по 90 ТБ, железу бы вздохнуть с облегчением
А с чего бы должно стать легче?

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

Устройств там вполне могло остаться столько же, а за счёт сжатия мы уменьшаем количество IO (но это зависит от паттерна нагрузки) при этом увеличивая расходы на CPU (хоть и незначительно - LZ4 легко выдаёт гигабайты в секунду при распаковке).

А с чего бы должно стать легче?

С дисков нужно меньше читать.

А ссылку на скрипт можно получить pg_diagdump.sh ?

Надо написать об этом желании в Postgres Professional.

Долгоиграющие незавершённые транзакции не дают автовакууму вычистить «старые» данные
оказалось, что некоторым, рекордным транзакциям исполнилось уже 3 дня
сессии с состоянием idle in transaction ... Среди этих транзакций тоже нашилсь висевшие часами.

Тема долгоиграющих транзакций не раскрыта.
Очевидно, это вопросы к приложениям, а не к БД.

Процессоры работают вовсю, но вхолостую, а с точки зрения Postgres
транзакции проводят время в праздности (idle), и автовакуумы штурмуют
таблицы и индексы раз за разом.

Ну какой же тут idle?
Это либо ожидание чтения блоков, либо ожидание свободных блоков буферного
пула, либо ожидание сброса буфера лога.

И да, 180 Тбайт на PostgreSQL с аналитическими запросами... ну такое, на любителя.

>Итого: клиенту посоветовали перейти на свежие версии ZFS (2.1+)

Заодно можно и на zstd_compress перейти.

>Александр Мотин из компании iXsystems (США) наблюдал такое поведение на 40-ядерной машине под FreeBSD и сделал патч, который убирает лишние операции со счётчиками.

Статью только до aggsum дочитал и сразу вспомнил этот патч. Иногда полезно смотреть коммиты, issues и PR.

У меня был печальный опыт с ZFS + постгрес, база данных на 3 Тб. Вроде бы оно работает, но если запустить тяжелый запрос на несколько часов, система стабильно виснет намертво. После перезагрузки ZFS говорит, что все ОК и нормально монтируется, но база данных в хлам, постгрес вообще не запускается. Только бекапы спасали.

Глубоко копать не стали, перешли на UFS и все стало хорошо, даже по свободной памяти выиграли. Снапшотами не пользовались из-за ограничений по объему диска. Но они и не спасли бы, все равно часть транзакций потерялась бы.

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

К подобным статьям нужно приводить настройки тюнинга ZFS в системе и PostreSQL (для ZFS).

Добрый день!

У Вас написано "Свой скрипт pg_diagdump.sh (по просьбе клиента его можно загрузить)", только не совсем понятно откуда его можно загрузить?

Добрый день. Надо написать об этом желании в Postgres Professional.

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