Комментарии 17
в табличке в конце я бы ещё добавил что btrfs можно наживую сделать многодисковой, превратить в зеркало или stripe, заменить диск без даунтайма, а xfs нет (xfs вообще двигается только в сторону увеличения одного раздела).
В продуктиве SQL Server скорее всего на Linux развёртывать не будут
1) наверное всётаки "в проде" или "в продакшене" или "в продовой инфраструктуре" ни никак не "в продуктиве"
2) если учесть что ms sql server в проде на линукс не ставят, и то что в прод не пускают винду получается что ms sql server в прод не идёт?
аттрибут запрещающий CoW в случае btrfs с учётом сервера для БД (а так же сервера локально хранящего vhdd виртуалок) лучше вешать не на файл а на директорию. это гарантирует что следующий созданный файл получит этот атрибут и не прийдётся делать это руками (что конечно-же скорее всего будет забыто)
в случае разметки в которой предполагается использовать всё пространство диска под одну фс в btrfs как и в zfs вполне себе можно использовать диск а не партицию (правда в случае zfs это обусловлено выкидыванием из схемы взаимодействия планировщика io стоящего перед родным для zfs планировщиком io которые оба в этой схеме не очень то нужны, а в случае btrfs не уверен что это принесёт какой-то профит)
аттрибут запрещающий CoW в случае btrfs с учётом сервера для БД (а так же сервера локально хранящего vhdd виртуалок) лучше вешать не на файл а на директорию. это гарантирует что следующий созданный файл получит этот атрибут и не прийдётся делать это руками (что конечно-же скорее всего будет забыто)
У меня на папку и навешано:
sudo chattr +C /var/opt/mssql/data/btrfs/template/sof
И выше:
Причём атрибут этот надо ставить на директорию до создания файлов или на пустой файл
А так как все файлы в примере непустые (копируются же), то и вешать надо на директорию.
если учесть что ms sql server в проде на линукс не ставят, и то что в прод не пускают винду получается что ms sql server в прод не идёт?
В проде винда, конечно. Я пока не видел живого DBA, который бы для серьёзных и больших БД MS SQL под linux использовал.
btrfs можно наживую сделать многодисковой, превратить в зеркало или stripe, заменить диск без даунтайма, а xfs нет
В тексте это упомянуто вскользь (в таблице нет). Но тут такое дело: большинство админов этой btrfs побаиваются, и особенно таких хитрых использований. Я уж молчу, о том, что в энтерпрайзе даже для разработчиков всё это не нужно потому что админы просто дадут нарезанную ВМ и подцепленные LUN в виде блочных устройств (а на чём они там нарезаны я как бы хз).
большинство админов этой btrfs попобаиваются
и я их понимаю, сам был таким. Когда btrfs была молода она превращалась в тыкву от каждого чиха (например от вышедшего из строя UPS'а) и восстановить данные зачастую было нереально. Когда же разработку подхватили suse они довольно серьёзно над этим поработали. Конечно самой неубиваемой фс всё ещё остаётся ext4, но например xfs уже давно отстала в этом плане от btrfs. Сейчас я не боюсь использовать btrfs в проде, это даёт возможность во многих местах отказаться от lvm и mdadm (хотя esp и swap разделы всё ещё необходимо держать на mdadm), а так же использовать сжатие что даёт зачастую довольно осязаемую экономию дискового пространства (и с момента появления полноценной поддержки zstd ещё и не насилует cpu и практически не влияет на скорость работы).
del (промахнулся веткой)
Чем-то похожим https://postgres.ai/ занимаются. Но они, как я понял, на zfs.
Почитаешь такую статью и благодаришь бога что ты не 1с-ник
Такие стенды совсем не только у 1Сников. 1Сникам даже немного проще: у них MS SQL не гвоздями прибит обычно и - долго, дорого и больно - но можно перейти на pg. В нескольких банках и НФО (больших) я видел системы, которые с MS SQL не перенести (терабайты, тысячи таблиц и ХП и миллионы строк TSQL). И стенды разработки/тестирования там жирные.
Кстати, в небольших инсталляциях, наверное до сотни гиг, решается просто прогрузкой dt. Как минимум - на свежих версиях 1с разницы либо никакой, либо на pg система быстрее.
до сотни гиг, решается просто прогрузкой dt
С dt не всё удобно. Разворачивается долго и БД потом место занимает. Это не проблема для 10 разработчиков, у которых стенды на ноутбуках, но даже для команды 20-30 разработчиков это становится важным. И уж точно не стоит вести разработку на pg, а эксплуатировать MS. А полный переход системы на pg это вообще другая история.
Как минимум - на свежих версиях 1с разницы либо никакой, либо на pg система быстрее.
Всё зависит от кучи обстоятельств. Есть сценарии, где pg часто выигрывает. Есть сценарии, в которых MS выигрывает. Есть ситуации, когда в целом побеждает одна СУБД, но есть регрессии - как назло в критических местах. Поэтому я бы не стал так категорично утверждать без уточнений.
А есть еще сама стоимость перехода. Есть (у нас) недостаток DBA, например pg. Нужно железо под новый контур в проде. Нужно разработать процесс миграции, который уложится в техническое окно. Если для вас это не проблема - я искренне рад. И именно это я имел в виду, что 1Сникам проще (им из T-SQL в PL/pgSQL километры строк не надо переписывать).
про SAP же никто не слышал и не использовал...
А зачем применять CoW для файла лога? Не проще его копировать обычным методом и сделать отдельным для каждой БД, тем более, что за счет отсутствия там CoW и производительность должна чуть вырасти, если мы говорим про запись?
Если в варианте с reflink и базой offline, то теоретически можно. Но это усложнение и увеличение количества способов выстрелить себе в ногу: файл mdf и ldf взятые не одновременно в общем случае не восстанавливают БД. Проще в образе держать совсем маленький ldf, тогда это минимально влияет на скорость записи.
Ну а случай "на лету" так вообще не организовать.
Использование copy-on-write на стендах разработки и тестирования с базами данных SQL Server