Выбор файловой системы для базы данных

Обновлено: 07.07.2024

Этот вопрос возникает на этапе планирования, при подготовке к покупке программы 1С и лицензий. Важны многие моменты: конфигурация, расположение офисов, количество сотрудников и т. п.

Решение о внедрении принято, дело за выбором системы управления базами данных (СУБД). Необходимо понять — из чего, собственно, выбираем. Какие у нас варианты.

СУБД для 1С

Платформа «1С:Предприятие» предлагает поддержку следующих видов:

  1. Файловый вариант (встроенный в 1С, вариант по умолчанию).
  2. Клиент-серверный вариант ( MS SQL Server, PostgreSQL, IBM DB2, Oracle Database ).

При создании информационной базы на сервере 1С тип СУБД указывается в параметрах.

Файловый вариант 1С

Штатный способ для создания информационной базы — вы просто указываете рабочий каталог (папку), в котором будут храниться файлы, либо сетевой путь с общим доступом. Вариант не требует установки дополнительного программного обеспечения.

  • Легкость в настройке.
  • Бюджетный вариант.
  • Низкая безопасность — каждый, кто работает с каталогом, имеет доступ на «запись», а значит может сделать копию базы данных.
  • Малая масштабируемость — у системы падает производительность при одновременной работе нескольких пользователей (на практике даже при 2-3 сеансах существенно падала скорость работы).
  • Ограничение функционала — регламентные задания работают, только когда открыт клиент, выполнен вход в базу; нет пользователей — задания не выполняются.
  • Ограничение в размере базы (4-12 Гб).

Максимальный размер любого внутреннего файла базы не может превышать

Размеры внутренних файлов растут неравномерно и проблемы с запуском могут начаться когда размер файла ИБ 1Cv8.1CD немногим превысит 4 Гб, но вполне возможно, что база «распухла» до 10 Гб и продолжает запускаться в файловом режиме.

Клиент-серверная СУБД

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

  • Высокая отказоустойчивость.
  • Наличие бесплатных СУБД (PostgreSQL).
  • Многопользовательский доступ.
  • Нет ограничения в размере БД.
  • Передовые СУБД — платные.
  • Требуется администрирование сервера СУБД.

✅ Если у вас небольшая организация, средний документооборот и для работы вам хватает 1-2 пользователей — начните с файлового варианта. В случае значительного объема данных и количества рабочих мест, выбирайте клиент-серверную модель.

⚡ Подписывайтесь на канал или задавайте вопрос на сайте — постараемся помочь всеми техническими силами. Безопасной и производительной работы в Windows и 1С.

130 GB. Есть несколько больших файлов (40 GB, 17 GB, 15 GB), остальные меньше. Отключение питания возможно несколько раз в год.

Что в данном случае предпочтительнее, Ext4 или xfs?


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

Здесь работает аксиома Эскобара.


2200 файлов в 60 каталогах

Нормальную реляционную БД в зависимости от проекта.

предпочтительнее настроить UPS.


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

Существует мнение, что нормальные БД используют fsync/fdatasync и журналы для обеспечения подтвержденной записи когда работают с файлами на ФС, и иногда даже пишут с O_DIRECT (но нечасто, надо признать), а нормальные сервера стоят на UPS, которые продержит их минимум 15 минут.

Так дело вовсе не в том, что она сыпется. Производительность падает. Лучше всего конечно в raw писать.


Производитель БД вообще не говорит про файловые системы в Linux.

ну ты бы хоть БД конкретизировал или ждёшь штатных телепатов? также есть разница соотношения чтения и записи


БД - Pervasive 11


XFS очень старая хрень с непонятными преимуществами. Единственная ФС на моей памяти, где после обычной перезагрузки можно обнаружить, что у тебя просто исчезла пара каталогов.

XFS очень старая хрень с непонятными преимуществами.

В линуксе активнее разве что Btrfs разрабатывается. Старая хрень это ext4, на которую RedHat начал забивать.

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

Любитель монтировать с nobarrier?


В линуксе активнее разве что Btrfs разрабатывается.

В чём понт btrfs при отключенном COW?

Тлетвоное влияние Лёни xD

В чём понт btrfs при отключенном COW?

Они продвигают XFS, а не Btrfs.


Спаси господи! (С)

и правильно делает, про них лучше вообще не говорить.


В чём понт btrfs при отключенном COW?

P.S.: если бы в ext4 был функционал CLONE_RANGE, хрен бы я на BTRFS посмотрел.


Вот если под БД подразумевается собственное хранилище, то зависит от типа и условий. Если 2200 файлов в 60 каталогах, то разница, скорее всего, будет на уровне погрешностей. Вот если будет 220000 в 600 каталогах и всё это под активным параллельным чтением и тебуется регулярно обходить каталоги (rsync/find-очистка/. ), то тут ext4 почти ложится, xfs просто тормозит, а палочкой-выручалочкой остаётся reiserfs.

В чём понт btrfs при отключенном COW?

1. хранилища на нескольких дисках (в том числе разного размера) с возможностью добавлять/убирать по одному

2. raid-образная избыточность

3. контрольные суммы


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

Никогда такого не слышал. Лет 10 назад, при жёстком выключении при падении питания без БП можно было словить (и я ловил не раз) зануление (забитие нулями) некоторых открытых в момент падения файлов. При чём это был не баг, а фича, система такое делала из соображений безопасности, чтобы тебе в файлы не попали чужие данные из-за сбоев. Но потом такое поведение исправили и я уже лет 8, как не слышал про подобное (как и не натыкался).

Вот с чем регулярно сталкиваюсь и на ext4, и на xfs — это редкие повреждения данных в файлах на больших объёмах. Что-то порядка нескольких сбоев (3-6) на 2Тб данных за месяц-два. Хорошо видно на раздачах торрентов — они ловят такое.

Ещё на ext4 нарывался пару раз на повреждение посторонних файлов при переполнении раздела.

reiserfs при работе в loop-образе в конце прошлого года стала вешать иногда всю дисковую подсистему. Я долго не мог понять причин.

Больше в последнее время проблем с ФС не было :) Вот раньше — да. ext3 однажды умерла целиком просто при нормальной работе сервера. На ext4 случались пропажи каталогов при вырубании питания. Из всех систем, с которыми работал, при аварийных ситуациях данные не пропадали только на reiserfs (был как-то адский период, когда сервер в течении пары месяцев приходилось ресетить почти каждый день, а иногда и дважды в день — и выжила, ни одной потери! :D) и ntfs.

Тут ключевой момент в способе работы fs. Ext4 сохраняет данные раз в 5 секунд, xfs регулярно не сохраняет, у нее по другому работает буфер. Если вы хотите надежности - ext4, если у вас большие данные и нужна скороть и есть бэкап - xfs

Контрольные суммы при отключении CoW отвалятся. Поэтому я никогда её не отключаю, даже если апстрим рекомендует (в systemd поставляется конфиг, отключающий CoW на /var/log/journal/).


1. хранилища на нескольких дисках (в том числе разного размера) с возможностью добавлять/убирать по одному

Надеюсь, речь не про встроенный RAID?

Вот с чем регулярно сталкиваюсь и на ext4, и на xfs — это редкие повреждения данных в файлах на больших объёмах. Что-то порядка нескольких сбоев (3-6) на 2Тб данных за месяц-два. Хорошо видно на раздачах торрентов — они ловят такое.

Память проверь, это просто огромное количество повреждений для таких смешных объёмов.


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

И даже с отключенным COW можно делать снапшоты, откатываться назад и т.д.

Так, да. Снапшоты у меня даже работали.


Это многолетняя эпопея на LOR и Juick — было несколько крупных тем :) На разных машинах, разных версиях Linux (Gentoo, Ubuntu). И на старой машине уже ничего от старого железа не осталось — и платформа другая (память/проц/мать) и винты другие. Долго под подозрением был LVM, но недавно ошибку в фотоархиве (

600Гб) словил на внешнем сервере без LVM.

Никакой мистики, это обычная статистика сбоев при чтении. Вот статистика ошибок в данных CERN, она примерно соответствует тому, на что натыкаюсь я :) — Сканер изменений в содержимом файлов, атрибуты которых не менялись. (комментарий)

Просто сбой байта на гигабайт в год многие не замечают. А я стал на это обращать внимание, когда стали попадаться битые фотки в большом семейном фотоархиве (сейчас

100 тыс. фото на 600Гб за 15+ лет).


и я уже лет 8, как не слышал про подобное (как и не натыкался).

Около пяти лет назад просто исчезла половина NoSQL БД после обычной перезагрузки сервера. Там на винтах из

120Гб было свободно 1-2Гб, после перезагрузки стало

50Гб свободного места, но никто на это внимание не обратил, пока не пошли звонки клиентов :)


Если вы хотите надежности - ext4, если у вас большие данные и нужна скороть и есть бэкап - xfs

Большие данные для xfs, размер файла какого порядка? Файл не изменяется (фильмы, образы) или изменяется (БД)?

Ну по описаниям xfs работает хорошо с большими файлами(операции с ними, чтение запись и т.д.) Большие это наверное несколько гиг

Ну по описаниям xfs работает хорошо с большими файлами(операции с ними, чтение запись и т.д.) Большие это наверное несколько гиг

Больше мегабайта. Просто эти легенды берут начало в ОЧЕНЬ далёких временах.


Хорошо видно на раздачах торрентов — они ловят такое.

А какой клиент это ловит? Или ты вручную проверку запускаешь?

Несколько лет с одного терабайтного внешнего HDD раздавал и не натыкался ни разу. ФС ext4


Мораль - тебе нужна файловая система с проверкой CRC как минимум

Да. Но вменяемых систем таких пока нет. Даже ZFS, хотя её активно советуют по этому вопросу, пока не оптимальна :)


Хорошо видно на раздачах торрентов — они ловят такое.

А какой клиент это ловит?

Разве, не любой? Торрент при раздаче отдаёт блоки с проверкой CRC. Поэтому сбой в блоке должен сразу ловиться.

Несколько лет с одного терабайтного внешнего HDD раздавал и не натыкался ни разу. ФС ext4

Значит, либо клиент не проверяет, либо автоматом исправляет/докачивает, либо история тут (у меня, галантерейщика^W кардинала^W, CERN и ещё ряда отозвавшихся лоровцев/жуйковцев) ещё более сложная :)


я бы спросил у системного администратора

Значит, либо клиент не проверяет, либо автоматом исправляет/докачивает, либо история тут (у меня, галантерейщика^W кардинала^W, CERN и ещё ряда отозвавшихся лоровцев/жуйковцев) ещё более сложная :)

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

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

В общем если файлопомойка предполагается большая лучше xfs, у нее иноды динамические и вообще она больше приспособлена для такого


В общем если файлопомойка предполагается большая лучше xfs, у нее иноды динамические

Кстати, да. Сколько раз мне ext4 этим жизнь портила. Заранее не рассчитаешь — всё, в один прекрасный момент раздел заполнен на половину, а писать уже нельзя. И на лету не поменять. Хорошо, когда LVM есть с резервом места. А когда нет — песец. Хоть loop-образ поднимай :) (и в некоторых случаях так даже быстрее работало! — пока reisrefs в loop не стал систему вешать :D)


Всегда всё оставляю по умолчанию, ну кроме noatime и discard для SSD.

Я тоже читал про глюкодром, но чем заменить?

Из того, что в ядре - нечем.


ext4 на флешке ОС стояло питание рубануло оно чот там журнал рековери мучало ,крайний раз не смогло ,переставил на xfs уже год хоть бы хны.

Каждая база данных SQL Server имеет как минимум два рабочих системных файла: файл данных и файл журнала. Файлы данных содержат данные и объекты, такие как таблицы, индексы, хранимые процедуры и представления. Файлы журнала содержат сведения, необходимые для восстановления всех транзакций в базе данных. Файлы данных могут быть объединены в файловые группы для удобства распределения и администрирования.

Файлы базы данных

SQL Server имеют три типа файлов.

Файл Описание
Первичная Содержит сведения, необходимые для запуска базы данных, и ссылки на другие файлы в базе данных. В каждой базе данных имеется один первичный файл данных. Для имени первичного файла данных рекомендуется расширение MDF.
Вторичная Необязательные определяемые пользователем файлы данных. Данные могут быть распределены на несколько дисков, в этом случае каждый файл записывается на отдельный диск. Для имени вторичного файла данных рекомендуется расширение NDF.
Журнал транзакций Журнал содержит информацию для восстановления базы данных. Для каждой базы данных должен существовать хотя бы один файл журнала. Для файлов журнала транзакций рекомендуется расширение LDF.

Например, простая база данных с именем Sales включает один первичный файл, содержащий все данные и объекты, и один файл журнала, содержащий сведения журнала транзакций. Более сложная база данных с именем Orders может содержать один первичный файл и пять вторичных файлов. Данные и объекты внутри базы данных распределяются по всем шести файлам, а четыре файла журнала содержат сведения журнала транзакций.

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

Логические и физические имена файлов

Файлы SQL Server имеют два типа имен файлов.

logical_file_name: имя, используемое для ссылки на физический файл во всех инструкциях Transact-SQL. Логическое имя файла должно соответствовать правилам для идентификаторов SQL Server и быть уникальным среди логических имен файлов в соответствующей базе данных.

os_file_name: имя физического файла, включающее путь к каталогу. Оно должно соответствовать правилам для имен файлов операционной системы.

Дополнительные сведения об аргументах NAME и FILENAME см. в статье Параметры ALTER DATABASE ((Transact-SQL)) для файлов и файловых групп.

Файлы данных и файлы журналов SQL Server могут использоваться как в файловой системе FAT, так и в системе NTFS. В системах Windows рекомендуется использовать файловую систему NTFS по причинам ее большей безопасности.

Файловые группы, доступные как для чтения, так и для записи, а также файлы журналов не поддерживаются со сжатой файловой системой NTFS. В сжатую файловую систему NTFS разрешено помещать лишь доступные только для чтения базы данных и доступные только для чтения вторичные файловые группы. Для экономии места настоятельно рекомендуется использовать сжатие данных вместо сжатия файловой системы.

Если на одном компьютере запущено несколько экземпляров SQL Server, каждый экземпляр получает отдельный каталог по умолчанию для хранения файлов баз данных, созданных в этом экземпляре. Дополнительные сведения см. в разделе Расположение файлов для экземпляра по умолчанию и именованных экземпляров SQL Server.

Размер файла

Файлы SQL Server могут автоматически увеличиваться в размерах, превосходя первоначально заданные показатели. При определении файла пользователь может указывать требуемый шаг роста. Каждый раз при заполнении файла его размер увеличивается на указанный шаг роста. Если в файловой группе имеется несколько файлов, их автоматический рост начинается лишь по заполнении всех файлов.

Дополнительные сведения о страницах и их типах см. в разделе Руководство по архитектуре страниц и экстентов.

Кроме того, можно указать максимальный размер каждого файла. Если максимальный размер файла не указан, файл может продолжать увеличиваться в размерах, пока не займет все доступное место на диске. Эта функция особенно полезна в случаях, когда SQL Server используется в качестве базы данных, внедренной в приложение, где пользователь не имеет удобного доступа к системному администратору. По мере необходимости пользователь может предоставить файлам возможность увеличиваться в размерах автоматически, тем самым снимая с администратора часть забот по наблюдению за свободным пространством базы данных и по распределению дополнительного пространства вручную.

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

Файлы моментального снимка базы данных

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

  • Данные моментального снимка базы данных, созданного пользователем, хранятся в одном или нескольких разреженных файлах. Технология разреженных файлов является свойством файловой системы NTFS. Изначально разреженный файл не содержит данных пользователя, и место на диске под него не выделяется. Общие сведения об использовании разреженных файлов в моментальных снимках базы данных и о том, как растут моментальные снимки базы данных, см. в разделе Просмотр размера разреженного файла моментального снимка базы данных.
  • Моментальные снимки базы данных могут использоваться внутренними механизмами при выполнении определенных команд DBCC. Эти команды включают DBCC CHECKDB, DBCC CHECKTABLE, DBCC CHECKALLOC и DBCC CHECKFILEGROUP. Внутренним моментальным снимком базы данных используются разреженные дополнительные потоки данных исходных файлов базы данных. Подобно разреженным файлам, дополнительные потоки данных являются свойством файловой системы NTFS. Использование разреженных дополнительных потоков данных позволяет связать несколько расположений данных с одним файлом или папкой, не затрагивая при этом размер файла или статистику тома.

Файловые группы

  • Эта файловая группа содержит первичный файл данных и все вторичные файлы, не входящие в другие файловые группы.
  • Пользовательские файловые группы могут создаваться для удобства администрирования, распределения и размещения данных.

Например, Data1.ndf , Data2.ndf и Data3.ndf могут быть созданы на трех дисках соответственно и отнесены к файловой группе fgroup1 . В этом случае можно создать таблицу на основе файловой группы fgroup1 . Запросы данных из таблицы будут распределены по трем дискам, и это улучшит производительность. Подобного улучшения производительности можно достичь и с помощью одного файла, созданного на чередующемся наборе дискового массива RAID. Тем не менее файлы и файловые группы позволяют без труда добавлять новые файлы на новые диски.

Все файлы данных хранятся в файловых группах, перечисленных в следующей таблице.

Файловая группа Описание
Первичная Файловая группа, содержащая первичный файл. Все системные таблицы являются частью первичной файловой группы.
Данные, оптимизированные для памяти В основе оптимизированной для памяти файловой группы лежит файловая группа файлового потока.
Файловый поток
Определяемые пользователем маршруты Любая файловая группа, созданная пользователем при создании или изменении базы данных.

Файловая группа по умолчанию (первичная)

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

Файловая группа PRIMARY является группой по умолчанию, если только она не была изменена инструкцией ALTER DATABASE. Системные объекты и таблицы распределяются внутри первичной файловой группы, а не новой файловой группой по умолчанию.

Файловая группа данных, оптимизированных для памяти

Дополнительные сведения об оптимизированных для памяти файловых группах см. в разделе Оптимизированные для памяти файловые группы.

Файловая группа файлового потока

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

Пример файлов и файловых групп

В следующем примере создается база данных на основе экземпляра SQL Server. База данных содержит первичный файл данных, пользовательскую файловую группу и файл журнала. Первичный файл данных входит в состав первичной файловой группы, а пользовательская файловая группа состоит из двух вторичных файлов данных. Инструкция ALTER DATABASE придает пользовательской файловой группе статус файловой группы по умолчанию. Затем создается таблица, определяющая пользовательскую файловую группу. (В этом примере используется универсальный путь к c:\Program Files\Microsoft SQL Server\MSSQL.1 , чтобы не указывать версию SQL Server.)

Данная иллюстрация обобщает все вышесказанное (кроме данных файлового потока).

Стратегия заполнения файлов и файловых групп

В файловых группах для каждого файла используется стратегия пропорционального заполнения. При записи данных в файловую группу компонент Компонент SQL Server Database Engine записывает в каждый файл количество данных, пропорциональное свободному пространству этого файла, вместо записи всех данных в первый файл до его заполнения. Затем запись производится в следующий файл. Например, если в файле f1 свободно 100 МБ, а в файле f2 — 200 МБ, то в файл f1 записывается одна часть данных, а в файл f2 — две части, и так далее. Таким образом, оба файла будут заполнены примерно в одно и то же время, и достигается простейшее распределение данных между хранилищами.

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

Правила проектирования файлов и файловых групп

Для файлов и файловых групп действуют следующие правила:

  • файл или файловая группа не могут использоваться несколькими базами данных. Например, файлы sales.mdf и sales.ndf, содержащие данные и объекты базы данных sales, не могут использоваться никакой другой базой данных.
  • файл может быть элементом только одной файловой группы;
  • файлы журнала транзакций не могут входить ни в какие файловые группы.

Рекомендации

Рекомендации при работе с файлами и файловыми группами:

  • Для большинства баз данных достаточно использовать один файл данных и один файл журнала транзакций.
  • При использовании множества файлов данных создайте вторую файловую группу с дополнительным файлом и сделайте ее файловой группой по умолчанию. Тогда в первичном файле будут храниться только системные таблицы и объекты.
  • Чтобы увеличить производительность, по возможности разнесите файлы и файловые группы по нескольким доступным дискам. Объекты, активно конкурирующие за свободное пространство, поместите в разные файловые группы.
  • Используйте файловые группы для целенаправленного размещения объектов на конкретных физических дисках.
  • Помещайте разные таблицы, использующиеся в одних и тех же запросах с соединениями, в разные файловые группы. Этот этап увеличит производительность, так как для поиска соединяемых данных можно будет использовать параллельный ввод-вывод.
  • Часто используемые таблицы и некластеризованные индексы, относящиеся к ним, помещайте в разные файловые группы. Использование разных групп файлов увеличит производительность, так как можно будет использовать параллельный ввод и вывод, если файлы находятся на разных жестких дисках.
  • Не помещайте файлы журнала транзакций на тот же физический диск, где находятся другие файлы и файловые группы.
  • Если необходимо расширить том или раздел, в котором находятся файлы базы данных, с помощью таких средств, как Diskpart, следует сначала выполнить резервное копирование всех системных и пользовательских баз данных и остановить службы SQL Server. Кроме того, после успешного расширения томов дисков рекомендуется выполнить команду DBCC CHECKDB , чтобы обеспечить физическую целостность всех баз данных в томе.

Дополнительные рекомендации по управлению файлами журнала транзакций см. в разделе Управление размером файла журнала транзакций.

Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.

Выбор файловой системы, конечно, зависит от выбора ОС. Во многих системах, например в Windows, есть всего один или два варианта. С другой стороны, GNU/Linux поддерживает много разных файловых систем.

Часто задают вопрос, какая файловая система обеспечивает наилучшую производительность для комбинации MySQL с GNU/Linux, или даже более конкретно: что лучше для InnoDB, а что - для MyISAM? Эталонные тесты показывают, что во многих отношениях большинство файловых систем очень близки, но полагаться на файловую систему в деле повышения производительности - пустое занятие. Производительность файловой системы сильно зависит от рабочей нагрузки, и ни одна из них не является панацеей. Как правило, каждая конкретная файловая система работает не хуже и не лучше любой другой. Исключение составляет случай, когда вы приближаетесь к какому-то лимиту файловой системы, например возникает высокая конкурентность, образуется много файлов, нарастает фрагментация и т. д.

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

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

По возможности предпочитайте файловые системы с журналированием, например ext3, ReiserFS, XFS, ZFS или JFS. В противном случае проверка файловой системы после сбоя может занять много времени. Если этот аспект не очень важен, то файловые системы без журналирования могут работать несколько быстрее транзакционных. Например, ext2 в этом смысле лучше, чем ext3, хотя при желании можно отключить журналирование в ext3 командой tunefs. Для некоторых файловых систем имеет также значение время монтирования. Так, на многотерабайтных разделах система ReiserFS монтируется и восстанавливается довольно долго.

Для файловой системы ext3 существует три варианта журналирования данных, соответствующие параметры монтирования задаются в файле /etc/fstab:

Журналируются только изменения метаданных. Изменение метаданных не синхронизированы с записью информации. Это самая быстрая конфигурация и обычно она безопасна при работе с InnoDB, так как последняя ведет собственный журнал транзакций. Есть, правда, одно исключение: сбой в неподходящий момент может привести к повреждению frm-файла.

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

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

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

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

Вне зависимости от файловой системы существует ряд параметров, которые лучше отключить, поскольку они не дают никаких преимуществ, но сопряжены с издержками. В этой связи чаще всего упоминают регистрацию времени последнего доступа, потому что она подразумевает операцию записи даже в том случае, когда вы просто читаете файл. Чтобы отключить этот режим, добавьте в файл /etc/fstab флаг монтирования noatime; иногда таким образом удается получить выигрыш в 5-10% в зависимости от рабочей нагрузки и файловой системы (хотя в других случаях никаких ощутимых изменений не наблюдается).

Приведем пример строки файла /etc/fstab с вышеупомянутым флагом для файловой системы ext3:

/dev/sda2 /usr/lib/mysql ext3 noatime,data=writeback 0 1

Можно также отключить в файловой системе упреждающее чтение, поскольку иногда оно оказывается избыточным. Например, InnoDB самостоятельно прогнозирует, к каким страницам может быть доступ в ближайшем будущем. Отключение или ограничение упреждающего чтения особенно благотворно сказывается на файловой системе UFS в ОС Solaris. Использование флага O_DIRECT автоматически отключает упреждающее чтение.

Некоторые файловые системы могут не поддерживать необходимых функций. Например, при использовании метода сброса O_DIRECT для InnoDB (см. раздел «Как InnoDB открывает и сбрасывает файлы журнала и данных» на стр. 359) важна поддержка прямого ввода/вывода. Кроме того, одни файловые системы лучше работают с большим количеством накопителей, чем другие; так XFS часто в этом отношении гораздо лучше ext3. Наконец, если вы планируете применять мгновенные снимки менеджера логических томов (LVM) для инициализации подчиненных серверов или снятия резервных копий, убедитесь, что выбранная файловая система хорошо «ладит» с LVM.

В табл. 7.2 приведены характеристики некоторых наиболее часто используемых файловых систем.

Читайте также: