Где хранить базу 1С, WAL, LDF и tempdb

Разносить файлы базы, журналов и временных данных по отдельным дискам нужно не по ритуалу, а когда замеры показывают конкуренцию за ввод-вывод. Я покажу, что можно вынести в PostgreSQL и MS SQL, какие настройки для этого существуют и как спланировать перенос. Отдельный том не ускорит сервер сам по себе.

Когда разделение дисков помогает 1С

Если база 1С отвечает медленно, низкая загрузка процессора ещё не доказывает, что виноват диск. Нужны замеры задержки чтения и записи, очереди, пропускной способности и активности в моменты, когда пользователи ждут операцию. На Windows это смотрят в Performance Monitor и средствах SQL Server, на Linux — системными средствами мониторинга дисковых устройств. Сравнивайте периоды одинаковой нагрузки: случайный снимок в тихий час ничего не объясняет. Если ожидания связаны с блокировками, планом запроса или нехваткой памяти, второй накопитель проблему не вылечит.

У файлов базы, журнала транзакций и временных областей разные профили ввода-вывода. Поэтому размещение на разных устройствах может уменьшить конкуренцию, если один общий том действительно упирается в производительность. Microsoft рекомендует раздельное размещение файлов данных и журнала, когда оно доступно; для PostgreSQL администратор может управлять размещением объектов через табличные пространства. Это рекомендации для проектирования и диагностики, а не обещание, что любой сервер после перестановки файлов станет быстрее. Начните с графиков, а не с корзины магазина.

Сначала выясните, что именно означает слово «диск» в вашей схеме. Два раздела на одном SSD не дают независимых физических ресурсов. И наоборот, RAID-массив или виртуальный диск могут скрывать несколько накопителей за одним томом. Уточните у хостера или администратора виртуализации, где проходят реальные границы хранилища и какие ограничения действуют на IOPS и пропускную способность. Если платформа выдаёт общий пул, назначение отдельных букв дискам само по себе ничего не разделит.

Затем сопоставьте пики нагрузки с конкретными файлами СУБД. В SQL Server проверьте физические пути файлов базы и tempdb, а в PostgreSQL — каталог кластера и табличные пространства. Отдельно учитывайте файлы операционной системы, технологический журнал 1С, резервные копии и временные файлы процессов: это не один общий «лог» и не обязательно компонент базы данных. Если нужны аудит и настройка 1С на сервере, сначала зафиксируйте исходное состояние и метрики.

• Снимите показатели дисковой задержки и очереди в пиковый период.
• Проверьте реальные устройства за томами и виртуальными дисками.
• Сопоставьте метрики с файлами базы, журналом и tempdb.

PostgreSQL: где лежат данные, WAL и временные файлы

В PostgreSQL файлы кластера находятся в каталоге данных. Внутри него есть pg_wal с сегментами журнала WAL. Параметр data_directory указывает каталог кластера, а параметра wal_dir в конфигурации нет: это выдуманное имя. Для размещения WAL отдельно используют поддерживаемый операционной системой механизм символической ссылки на pg_wal; такую операцию планируют при остановленном сервере и с сохранением владельца и прав. Здесь нет безобидного переключателя, который можно поставить в postgresql.conf и забыть.

Для объектов базы PostgreSQL предлагает tablespaces. Они задают каталог хранения таблиц и индексов и позволяют вынести выбранные объекты на другую файловую систему. Параметр temp_tablespaces задаёт табличные пространства для временных таблиц, индексов и временных файлов, например при сортировках. Сначала создают tablespace в пустом каталоге с нужным владельцем, а затем задают его для подходящих объектов или настройки. Один tablespace не перемещает автоматически весь кластер и не превращает временные данные в отдельную независимую базу.

У такого разделения есть цена: потеря диска с tablespace может сделать кластер нечитаемым или помешать его запуску. Табличные пространства связаны с метаданными основного кластера и не являются самостоятельными резервными копиями. Поэтому отдельный том для временных файлов тоже нельзя считать безопасной «одноразовой» областью, если на нём лежит tablespace. Размещение, резервное копирование и восстановление нужно проектировать вместе; иначе мы просто разнесём точки отказа по разным корпусам.

С WAL похожая осторожность. Отдельное устройство может помочь при подтверждённом конфликте нагрузки, но не спасает данные при отказе диска и не заменяет резервное копирование. При выборе схемы проверьте, как резервная копия охватывает каталог данных и WAL, а также как восстановление будет работать при недоступности одного тома. Руководство PostgreSQL описывает файловую структуру и tablespaces; документация не требует трёх физических накопителей для каждой установки. Для конкретной версии PostgreSQL, совместимой с вашей платформой 1С, проверьте методику 1С перед изменением конфигурации.

• Каталог кластера содержит `pg_wal`; параметра `wal_dir` нет.
• `temp_tablespaces` управляет временными объектами и файлами.
• Tablespace зависит от основного кластера и требует общей схемы резервного копирования.

SQL Server: файлы данных, журнал и tempdb

В SQL Server файлы данных обычно имеют расширения MDF или NDF, а файл журнала — LDF. Microsoft рекомендует размещать файлы данных и журнала на разных дисках, если это возможно: на общей подсистеме они могут конкурировать за ввод-вывод. Речь о рекомендации, а не о требовании, что каждому файлу обязательно нужен собственный физический накопитель. Важны фактическая нагрузка и устройство хранения под томом. Если всё уже работает на быстром RAID-массиве без признаков дискового узкого места, искусственное дробление может добавить сложность без заметной пользы.

У tempdb отдельная роль: SQL Server пересоздаёт её при запуске экземпляра, а запросы используют её для временных объектов и части промежуточной работы. Microsoft рекомендует размещать tempdb на подсистеме с быстрым вводом-выводом. Файлы tempdb не обязаны находиться на разных дисках; в документации сказано переносить их на отдельные диски от пользовательских баз, если обнаружена конкуренция за дисковый ввод-вывод. Не «самый быстрый NVMe любой ценой», а измерение и подходящий ресурс.

tempdb требует внимания к размеру, росту и свободному месту. Microsoft рекомендует заранее выделить размер под типичную нагрузку, оставить автоувеличение для непредвиденного роста и обеспечить одинаковые начальные размеры и настройки роста файлов данных tempdb. Несколько равных файлов могут помочь при конкуренции за страницы распределения, но их число зависит от версии, конфигурации и нагрузки. Не копируйте настройку «по числу ядер» из чужой статьи без диагностики.

Путь существующих файлов можно узнать через представления SQL Server, например sys.database_files; для tempdb доступны tempdb.sys.database_files. Перенос пользовательской базы требует корректной процедуры и окна работ. Изменение пути файла через ALTER DATABASE ... MODIFY FILE само по себе не перемещает файл: затем нужны предусмотренные действия и перезапуск экземпляра в нужный момент. Для tempdb механизм иной, поскольку база создаётся заново при старте. Выполняйте процедуру по инструкции Microsoft для вашей версии, с резервной копией и проверенным планом возврата.

• MDF/NDF — файлы данных; LDF — журнал транзакций.
• tempdb размещают на быстром хранилище, а отделяют при подтверждённой конкуренции.
• Размер, автоувеличение и свободное место проверяют отдельно.

Как читать замеры и не купить диск вслепую

Для SQL Server зафиксируйте задержки по каждому тому, очередь и долю времени активного диска, а также ожидания движка и загрузку tempdb. Смотрите на длительность и повторяемость пиков, а не на единственное значение «100 %». Для PostgreSQL нужны метрики операционной системы вместе с наблюдением за запросами, контрольными точками и временными файлами. Рост активности записи WAL может быть нормальной частью работы; сам по себе он не доказывает, что журналу требуется отдельный NVMe.

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

Перед изменениями снимите исходные показатели и проверьте резервную копию восстановлением на стенде. Определите объём файлов, свободное место, резерв на рост, права службы и возможность отката. Переносите данные в согласованное окно; если для операции требуется остановка сервиса, предупредите пользователей. После изменения повторите тот же сценарий нагрузки и сравните метрики. Иначе нельзя отличить эффект размещения от изменения числа пользователей, времени суток или состава запросов.

Если данные размещаются на виртуальном сервере, проверьте ограничения хранилища у провайдера. Два виртуальных тома могут опираться на один физический пул и конкурировать за общую квоту. В локальном сервере RAID-контроллер, кэш и прошивка тоже влияют на результат. Иногда быстрее и надёжнее перевести файлы на другой массив; иногда достаточно изменить расписание резервного копирования или найти запрос, который заставляет tempdb расти. Ответ даёт повторяемый замер до и после, не название интерфейса SSD.

• Сравнивайте одинаковые сценарии до и после изменения.
• Проверяйте задержки, очереди, tempdb и общие ограничения массива.
• Сделайте тестовое восстановление до миграции.

Кейс: проверяем схему у производителя макетов

В исходных данных для этого разбора задан условный производитель макетов «Масштаб-центр», 16 рабочих мест. Этого достаточно, чтобы описать план диагностики, но недостаточно, чтобы выдавать за подтверждённые факты прежние цифры про загрузку диска на 100 %, сотни элементов в очереди, три NVMe, отклик в доли секунды или перенос за несколько часов. В статье они были представлены как измеренный результат, хотя экспертная база этого не подтверждает. Я убрал эти цифры: красивый график, взятый с потолка, остаётся потолком.

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

После согласования схемы перенос выполняется по процедуре для конкретной СУБД и её версии. Мы сохраняем исходные файлы до завершения проверки, сверяем доступность базы, повторяем пользовательские сценарии и контролируем журналы ошибок. Только затем сравниваем результат с исходными измерениями и фиксируем, что именно изменилось. Так можно честно сказать, помогло ли размещение, и не приписывать новому диску эффект от других изменений.

Смысл практического разбора — не продать три накопителя, а сузить причину задержки до проверяемой гипотезы. Если конкуренция за ввод-вывод подтверждена, дополнительное устройство или иной уровень хранения может быть оправдан. Если нет, покупка диска просто добавит ещё один том для мониторинга. Иногда это тоже бизнес-процесс, но обычно не тот, за который хочется платить.

План переноса и безопасная проверка результата

Начните с инвентаризации: версия платформы 1С, версия СУБД, расположение файлов, схема RAID или виртуального хранилища, свободное место и действующая политика резервного копирования. Сверьте совместимость PostgreSQL с вашей версией платформы по материалам 1С. Определите, какие именно файлы требуется переместить и зачем: база, WAL, tempdb, журнал технологического журнала 1С и резервная копия — разные объекты. Не складывайте их в общий список «логи», иначе план миграции будет ошибочным.

Затем подготовьте целевой том, права учётной записи службы, мониторинг свободного места и план отката. Для PostgreSQL изучите официальный порядок работы с tablespaces или отдельным расположением WAL; резервные копии и восстановление должны учитывать оба места хранения. Для SQL Server используйте документацию Microsoft по переносу файлов нужной базы или tempdb. Не редактируйте пути вручную и не перемещайте файлы, пока соответствующий процесс работает. Если процедура требует остановки службы, организуйте окно простоя.

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

Не путайте размещение и отказоустойчивость. Разнесение файлов по двум накопителям не создаёт резервную копию, а может увеличить число точек, отказ которых останавливает кластер. Защитой служат проверенные резервные копии и план восстановления, а для доступности применяются соответствующие механизмы хранения и СУБД. Шифрование диска тоже не является настройкой производительности: влияние зависит от процессора, реализации и нагрузки, поэтому его оценивают на своей системе. Универсального процента потери скорости нет.

Частые вопросы