
Комментарии 17
аттрибут запрещающий 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 в виде блочных устройств (а на чём они там нарезаны я как бы хз).
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