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

Вот я тоже, только такую причину придумать смог Типа, а дайте сделаем, будет фичей больше. А что оно нафиг не надо, пофиг

вот может кому интересно будет, потестил тут zfs vs btrfs на ssd в качестве root раздела. суть теста -- читаем все файлы типичного рут-раздела с холодными кешами. ~14 гигабайт, ~500 тыщ файлов. читаю при помощи time tar -c /path/ >/dev/null

итак, холодные кеши: zfs: 3.8 секунд, btrfs: 3.3 секунды прогретые кеши (т.е. всё из RAM) zfs: 1.3 секунды, btrfs: 0.9 секунд

А вы про что вообще тогда спорите?) мы про копиес в зфс, пытаюсь найти причину его разработки

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

Видимо было дёшево дать управлять им для данных тоже

Видимо было дёшево дать управлять им для данных тоже

С этим согласен, с тем что выше, могу сказать, что странные люди. Грубо говоря, два диска по 1тб стоят где как один на 2тб. Но общая надёжность зеркала будет выше и скорость выше, а полезная ёмкость одинаковая. Пока вижу только вариант, что нет свободных портов для дисков, но это не особо на прод похоже

С этим согласен, с тем что выше, могу сказать, что странные люди. Грубо говоря, два диска по 1тб стоят где как один на 2тб. Но общая надёжность зеркала будет выше и скорость выше, а полезная ёмкость одинаковая. Пока вижу только вариант, что нет свободных портов для дисков, но это не особо на прод похоже

Хорошо для ноутов заходит

Zfs не только на серверах:)

Zfs не только на серверах:)

Ну солярку на ноутах не видел)))

Опенсолярку давно на свой ставил

Иллюмос тоже

Работает через задницу, но работает - эксперимент удался 😁

Иллюмос тоже

Не не. Эту ж фичу впилили на обычной солярке. Так что какую то цель последовали этм злые поклонники солнца

Я бы понял, если бы она появилась в озфс, но ее не было в обычной. Так нет же. Есть

Зфс планировалась не только, как серверная, насколько помню

Зфс планировалась не только, как серверная, насколько помню

По городской легенде снапшоты появились по причине удобной инкрементальной отправки диффов разрабу в другую страну чтоли😁 это к слову

😁😁😁👍

А по поводу перформанса под бд - минимум delphix (одна из компаний с наибОльшим количеством разрабов openzfs и ex-sunовцев) использует и продаёт zfs именно для бд

Забавности в воскресный вечер)

А по поводу перформанса под бд - минимум delphix (одна из компаний с наибОльшим количеством разрабов openzfs и ex-sunовцев) использует и продаёт zfs именно для бд

а в чем мотивация использовать zfs под бд? кроме снапшотов есть еще что-то?

а в чем мотивация использовать zfs под бд? кроме снапшотов есть еще что-то?

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

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

снапшоты базы данных? серьезно? :)))

снапшоты базы данных? серьезно? :)))

а что не так?

а что не так?

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

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

грубо говоря, какая нить команда, update x set c=c+100, поменят пару терабайт на массиве и будет через сенд слаться сутки на другой массив

грубо говоря, какая нить команда, update x set c=c+100, поменят пару терабайт на массиве и будет через сенд слаться сутки на другой массив

Это будет верно только, данные этого поля занимают в базе пару терабайт. Я с такими объемами не работаю слава богу

Зато на приемнике не нужна запущенная база, ему не нужно повторять логику запроса, нагружать процессор, выполняя логику запроса на реплики и самое главное - это просто настроить и поддерживать, в отличие от реплика сета внутри базы

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

Сделать данные гарантированно консистентными на момент создания снапшота - не проблема.

Сделать данные гарантированно консистентными на момент создания снапшота - не проблема.

как?

не забывай, это бд, и у нее свои буферы

Зато на приемнике не нужна запущенная база, ему не нужно повторять логику запроса, нагружать процессор, выполняя логику запроса на реплики и самое главное - это просто настроить и поддерживать, в отличие от реплика сета внутри базы

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

грубо говоря, снапшот это выключение питания, в ближайшей аналогии. в 99% случаев все хорошо (если это не асинхрон)

как?

Например, на mysql это делается так: flush tables with read lock;

после создания снапшота - unlock tables;

на других субд есть аналогичные механизмы

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

У вас упрощенное представление о том, что есть БД и как она работает. Это не набор файлов, как в файлопомойке. Oracle прекрасно снапшотится и создаются клоны, никаких проблем не наблюдается. Они же выпускают zfssa - хранилище для БД, которое используется,например, в exadata. Точно так же не видно проблем с снапшотами на Postgres. Просто нужно уметь готовить

Используют - используют, еще как

Либо снапшоты на уровне дисковой системы, если таковая есть, либо, например тот же ZFS

mssql вообще умеет пофайлово бекапиться за счёт поддержки shadow copy

У вас упрощенное представление о том, что есть БД и как она работает. Это не набор файлов, как в файлопомойке. Oracle прекрасно снапшотится и создаются клоны, никаких проблем не наблюдается. Они же выпускают zfssa - хранилище для БД, которое используется,например, в exadata. Точно так же не видно проблем с снапшотами на Postgres. Просто нужно уметь готовить

или у вас). но спорить не буду. у меня самая большая база 1.5тб, и та на мсскл. бекапы сливаю средствами самой бд

mssql вообще умеет пофайлово бекапиться за счёт поддержки shadow copy

только это поддержка со стороны имено бд. грубо говоря, поверх зфс такого она не сделает

ms sql под это дело мало подходит - это из другой реальности

тоже самое с ораклом наверняка

а вот всякие мускли и постргессы врядли

хотя если запускать ms sql на linux - то вполне себе можно делать снапшоты и клогы, быстро, буквально минута независимо от размера БД

только это поддержка со стороны имено бд. грубо говоря, поверх зфс такого она не сделает

Я о том, что mssql можно бекапить пофайлово без остановки сервера всякими там бакула или бареос

хотя если запускать ms sql на linux - то вполне себе можно делать снапшоты и клогы, быстро, буквально минута независимо от размера БД

атомарно на разных вольюмах?

дык oracle тоже в общем-то бэкапится только rman на горячую, все что карсивое и с кнопками - это обертка вокруг rman

атомарно на разных вольюмах?

zfs может делать снимок дерева волюмов атомарно. Это будет ровно одна операция на файловой системе - 1 транзакция.

Я о том, что mssql можно бекапить пофайлово без остановки сервера всякими там бакула или бареос

а зачем останавливать мсскл при бекапе?

а зачем останавливать мсскл при бекапе?

я не предлагаю его останавливать, наоборот, говорю, что можно не останавливать

zfs может делать снимок дерева волюмов атомарно. Это будет ровно одна операция на файловой системе - 1 транзакция.

оппа, пошешел гуглить как сделать дерево вольюмов. интересная информация

при бекапе НЕ средствами mssql

zfs может делать снимок дерева волюмов атомарно. Это будет ровно одна операция на файловой системе - 1 транзакция.

я проверял. у этих снимков будет одна txg метка стоять

ну вижу проблем - при старте БД будет rollback/rollforward до последней закоммиченной транзации в transaction log применительно к ms sql или redo/archivelog для oracle

при бекапе НЕ средствами mssql

не средствами скл, как оно транзакции определяет? или оно все же что то там локает/комитит

ну вижу проблем - при старте БД будет rollback/rollforward до последней закоммиченной транзации в transaction log применительно к ms sql или redo/archivelog для oracle

+

не средствами скл, как оно транзакции определяет? или оно все же что то там локает/комитит

mssql знает, что его сейчас бекапят

mssql знает, что его сейчас бекапят

так это средствами скл. просто с внешней мордочкой, грубо говоря.

так это средствами скл. просто с внешней мордочкой, грубо говоря.

это не тот бекап, что встроен в mssql

оппа, пошешел гуглить как сделать дерево вольюмов. интересная информация

-r и указываем родительский датасет zfs snapshot -r tank/home@now

еще раз, если "комитить и локать" в бд, то да, можно снапить

-r и указываем родительский датасет zfs snapshot -r tank/home@now

чтто такое родительский датасет если речь про вольюмы шла?

отдельные диски, отдельные пулы

Допустим у вас Proxmox rpool rpool/ROOT rpool/ROOT/pve-1 rpool/data rpool/data/subvol-110-disk-0 rpool/data/subvol-201-disk-0 rpool/data/subvol-202-disk-0 rpool/data/subvol-203-disk-0 rpool/data/subvol-204-disk-0 rpool/data/vm-100-disk-0 rpool/data/vm-101-disk-0 rpool/data/vm-102-disk-0 rpool/data/vm-103-disk-0 rpool/data/vm-104-disk-0 rpool/data/vm-105-disk-0 rpool/data/vm-106-disk-0 rpool/data/vm-106-disk-1 Тогда надо делать снимок rpool/data@имя_снимка

не, не так, у меня есть raizd2 с кешем под данные и какой то raid10 под логи. как сделать синхронно снапшот?

зы: по рекомендациям, так сказать, для скл

не, не так, у меня есть raizd2 с кешем под данные и какой то raid10 под логи. как сделать синхронно снапшот?

если z-пулы разные - то никак.

если z-пулы разные - то никак.

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

и мало того, часто рекомендуют, что бы эти массивы были разные

тогда снимки становятся бесполезными, с моей точки зрения

кстати, qemu guest agent на венде использует VSS, соответственно, нет вообще проблем делать снапшоты вендовых виртуалок с mssql

тогда снимки становятся бесполезными, с моей точки зрения

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

кстати, qemu guest agent на венде использует VSS, соответственно, нет вообще проблем делать снапшоты вендовых виртуалок с mssql

снять то нет :))

грубо говоря, правильный, с точки зрения БД снапшот, это тот, при откате на который, потом нет в логах отката/применения транзакции

снять то нет :))

Данные в снимке будут консистентными. Но я не знаю, как оно себя поведёт, если дисков несколько.

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

обычно, всё же, это один пул, но разные датасеты

грубо говоря, правильный, с точки зрения БД снапшот, это тот, при откате на который, потом нет в логах отката/применения транзакции

Ещё раз, mssql знает, что его бекапят.