База данных — самая ценная часть инфраструктуры и одновременно самая чувствительная к неправильной эксплуатации. Берём на себя работу администратора БД без штатной единицы: устанавливаем и настраиваем СУБД под реальную нагрузку, ведём регламентное обслуживание и мониторинг, делаем резервное копирование и проверяем восстановление базы данных, разбираем медленные запросы, настраиваем репликацию и поднимаем базу после сбоев. Работаем с PostgreSQL, MS SQL и MySQL.
Сервер купили, СУБД поставили, приложение заработало — и на этом администрирование закончилось. Дальше база живёт сама: растёт, обрастает индексами, копит устаревшую статистику, а её конфигурация остаётся такой, какой была в день установки. Настройки по умолчанию у всех популярных СУБД сознательно консервативны: разработчики рассчитывают, что база может стоять на слабой машине, и не позволяют ей занять память, которой может не оказаться. На нормальном сервере это означает, что половина ресурсов просто не используется.
Проблемы копятся тихо и всплывают все сразу: отчёт, который раньше собирался за минуту, теперь считается полчаса; свободное место кончилось в самый неподходящий момент; после отключения питания база не поднялась, а последняя копия, как выяснилось, не разворачивается. Мы берём базу под наблюдение до того, как это произойдёт, — и приводим в порядок, если уже произошло.
Разворачиваем СУБД и подбираем параметры под конкретный сервер: объём памяти под кэш и рабочие области, поведение при записи на диск, число подключений, размещение данных и журналов транзакций.
Конфигурация по умолчанию не знает, сколько у вас памяти.
Настраиваем и контролируем рутину, без которой база деградирует: обновление статистики, переиндексацию и дефрагментацию, очистку служебных данных, контроль роста таблиц и свободного места.
Выносим тяжёлые работы на ночь, чтобы не мешать людям.
Делаем резервное копирование штатными средствами СУБД, храним копии отдельно от боевого сервера и регулярно разворачиваем их, чтобы убедиться: база действительно поднимается.
Непроверенная копия — это не бэкап, а надежда на удачу.
Ставим мониторинг на то, что реально ломается: место на дисках, длительность и успешность копий, блокировки и зависшие сеансы, рост базы, ошибки в журналах, доступность сервиса.
Об исчерпании места лучше узнать заранее, а не от бухгалтерии.
Находим запросы, которые съедают ресурсы, смотрим планы выполнения, добавляем или убираем индексы, предлагаем разработчикам переписать то, что не лечится настройками.
Обычно всё упирается в несколько запросов, а не в весь код.
Переводим базы на поддерживаемые версии по плану: тест на копии, окно работ, возможность откатиться. При аварии поднимаем базу из копии или чиним на месте, если данные ещё живы.
План отката готовим до начала работ, а не по ходу аварии.
Настройка параметров под сервер, регламент, репликация, миграция с MS SQL и работа с базами 1С.
Подробнее →
Клиент-серверный режим, подбор конфигурации и перенос баз без остановки работы бухгалтерии.
Подробнее →
Копии баз и серверов по расписанию, хранение вне основной площадки, регулярные тесты восстановления.
Подробнее →Посмотрим настройки, копии, обслуживание и рост базы — и скажем прямо, что требует вмешательства сейчас, а что подождёт.
Эти работы не видны, пока их делают, и очень заметны, когда их перестают делать. Ниже — что именно происходит с базой в каждом случае.
| Работа | Что делаем | Что бывает, если не делать |
|---|---|---|
| Обновление статистики | Пересчитываем сведения о распределении данных, на которые опирается планировщик запросов | СУБД выбирает неудачный план и читает всю таблицу вместо нескольких строк |
| Переиндексация | Перестраиваем разросшиеся и фрагментированные индексы, убираем неиспользуемые | Индексы занимают место и постепенно перестают ускорять выборки |
| Очистка служебных данных | Следим за уборкой старых версий строк и историей изменений, настраиваем её агрессивность | База растёт без роста полезных данных, диск заканчивается неожиданно |
| Контроль роста | Отслеживаем размер базы, крупнейшие таблицы, журналы транзакций и свободное место | Место кончается в рабочий день, и база останавливается на записи |
| Проверка копий | Разворачиваем резервную копию на отдельном сервере и убеждаемся, что база стартует | О непригодности архива узнают в момент, когда восстанавливать уже нечего |
| Разбор журналов | Читаем сообщения об ошибках, блокировках и долгих операциях, разбираем повторяющиеся | Мелкие сбои копятся и однажды складываются в остановку сервиса |
Не всем нужен постоянный администратор баз данных. Чаще нужен человек, который приведёт базу в порядок и будет за ней присматривать.
Когда есть понятная задача с началом и концом: развернуть базу, ускорить конкретный отчёт, перевести на новую версию, настроить копии.
Когда база важна для работы компании, а держать своего администратора баз данных незачем. Мы ведём её как часть сопровождения ИТ.
Когда база уже не работает. Здесь важно не навредить: неаккуратные действия в такой момент способны превратить восстановимую ситуацию в потерю данных.
Наблюдение за базами, серверами и сервисами с уведомлениями о проблемах.
Подробнее →
Сервер под базу данных с нужным объёмом памяти и быстрыми дисками.
Подробнее →
Перенос баз и сервисов на другую площадку с планом и возможностью отката.
Подробнее →С PostgreSQL, MS SQL Server и MySQL — это покрывает подавляющее большинство задач бизнеса: учётные системы, сайты и порталы, внутренние сервисы, базы 1С. Если у вас используется что-то другое, скажем честно, беремся ли мы, а не будем изучать вашу систему за ваш счёт.
Затем же, зачем меняют масло в машине, которая едет. «Нормально» — это состояние, из которого база выходит постепенно: сначала медленнее становятся отчёты, потом заканчивается место, потом обнаруживается, что копия не разворачивается. Обслуживание дешевле восстановления, а восстановление возможно не всегда.
Часто да, и для 1С это довольно отработанный путь: PostgreSQL официально поддерживается со стороны 1С и не требует лицензионных платежей. Для собственных приложений всё зависит от того, насколько код завязан на особенности MS SQL. Мы смотрим базу и запросы и говорим, чего будет стоить переход, до его начала. Подробнее — на странице про PostgreSQL.
Главное — не пытаться чинить наугад и не запускать утилиты восстановления по совету из интернета: этим легко превратить восстановимую ситуацию в окончательную потерю. Правильный первый шаг — снять копию текущего состояния файлов, чтобы у любой попытки было куда откатиться. Дальше уже разбираемся с причиной.
Не всегда. Для небольших систем база спокойно живёт рядом с приложением. Разносить их имеет смысл, когда они начинают конкурировать за память и диск или когда базу нужно защищать и резервировать отдельно от остального. Решение принимаем по нагрузке, а не по принципу «так правильнее».
Тяжёлые регламентные работы, обновления и переключения мы стараемся выполнять в нерабочее время — именно чтобы никого не останавливать. Режим реагирования на аварии и окна плановых работ фиксируем в договоре: у круглосуточного сервиса и у офисной базы, которая нужна с девяти до шести, требования разные, и платить за лишнее незачем.
Расскажите, какая СУБД, какого размера база и что сейчас беспокоит. Разберёмся, что требует вмешательства, а что работает нормально.
Базу данных редко ломают одним неверным действием. Обычно её доводят до аварии годами мелких упущений, каждое из которых по отдельности выглядит несущественным. Ниже — те, что встречаются чаще всего.
Любая СУБД из установочного пакета настроена так, чтобы запуститься где угодно, в том числе на слабой виртуальной машине. Объёмы памяти под кэш и сортировки, поведение при сбросе данных на диск, параллелизм — всё задано с большим запасом прочности. Перенести такую конфигурацию на сервер с большим объёмом памяти и не изменить ни строчки означает оставить ресурсы простаивать. Это особенно заметно у PostgreSQL, где консервативность настроек по умолчанию — сознательное решение разработчиков.
Самый частый сценарий потери данных выглядит так: копии делались, задание отрабатывало без ошибок, а в момент аварии выяснилось, что архив неполный, повреждён или в нём нет нужной базы. Пока копию не развернули на отдельном сервере и не убедились, что база стартует и данные на месте, она остаётся файлом с неизвестным содержимым. Мы встраиваем такие проверки в регламент — и в резервном копировании считаем их обязательной частью услуги, а не дополнительной опцией.
Замедление почти никогда не бывает резким. Сегодня отчёт считается на пару секунд дольше, через полгода — на минуту, и никто не может назвать день, когда всё испортилось. Причина обычно скучная: устаревшая статистика, разросшиеся индексы, накопившиеся старые версии строк, таблица, которая выросла в десятки раз. Регламентное обслуживание возвращает базу в форму без единого рубля вложений в оборудование — и в этом смысле оно окупается лучше любого апгрейда.
Когда система «вся тормозит», в реальности ресурсы съедают несколько конкретных запросов. Мы включаем сбор статистики по длительным операциям, находим лидеров, смотрим планы выполнения и определяем причину: не хватает индекса, индекс есть, но не используется, запрос написан так, что оптимизатор не может его развернуть. Часть проблем закрывается на стороне базы, часть требует правки кода — и тогда мы формулируем задачу разработчикам конкретно, а не в виде «оптимизируйте».
Старые версии СУБД перестают получать исправления, включая исправления уязвимостей, и постепенно расходятся с требованиями прикладного софта. Обновление лучше делать заранее и по частям: развернуть копию базы на новой версии, прогнать на ней реальную нагрузку, посмотреть, не изменилось ли поведение запросов, и только потом переключать боевую систему в согласованное окно с возможностью вернуться назад.
Большинство проблем с базами данных подают сигналы заранее: растёт время выполнения, копится очередь к диску, задание копирования начинает завершаться с ошибками, свободное место тает. Всё это видно в мониторинге — если он настроен на показатели базы, а не только на доступность сервера. Для баз 1С мы обычно совмещаем это с настройкой сервера 1С, потому что причины тормозов там лежат сразу в двух плоскостях: в конфигурации СУБД и в архитектуре самой системы.
