Обновить

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

НЛО прилетело и опубликовало эту надпись здесь

аттрибут запрещающий CoW в случае btrfs с учётом сервера для БД (а так же сервера локально хранящего vhdd виртуалок) лучше вешать не на файл а на директорию. это гарантирует что следующий созданный файл получит этот атрибут и не прийдётся делать это руками (что конечно-же скорее всего будет забыто)

У меня на папку и навешано:

sudo chattr +C /var/opt/mssql/data/btrfs/template/sof

И выше:

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

А так как все файлы в примере непустые (копируются же), то и вешать надо на директорию.

если учесть что ms sql server в проде на линукс не ставят, и то что в прод не пускают винду получается что ms sql server в прод не идёт?

В проде винда, конечно. Я пока не видел живого DBA, который бы для серьёзных и больших БД MS SQL под linux использовал.

НЛО прилетело и опубликовало эту надпись здесь

я и сам в своем роде DBA, но при мне такой х..ни (как MS SQL под линукс) не было

btrfs можно наживую сделать многодисковой, превратить в зеркало или stripe, заменить диск без даунтайма, а xfs нет

В тексте это упомянуто вскользь (в таблице нет). Но тут такое дело: большинство админов этой btrfs побаиваются, и особенно таких хитрых использований. Я уж молчу, о том, что в энтерпрайзе даже для разработчиков всё это не нужно потому что админы просто дадут нарезанную ВМ и подцепленные LUN в виде блочных устройств (а на чём они там нарезаны я как бы хз).

НЛО прилетело и опубликовало эту надпись здесь

Чем-то похожим 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, тогда это минимально влияет на скорость записи.
Ну а случай "на лету" так вообще не организовать.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации