Сервер для MySQL и MariaDB
СУБД для веб-приложений, CMS, интернет-магазинов и бэкенд-сервисов. Производительность сильнее всего зависит от буферного пула InnoDB, дисков под redo log и данные и схемы масштабирования чтений.
- Размер данных и горячего набора — часто используемые таблицы и индексы должны помещаться в буферный пул InnoDB.
- Баланс чтения и записи — при преобладании чтений помогают реплики, при активной записи важны быстрые диски.
- Redo log — как WAL у других СУБД, он чувствителен к задержке диска.
- Число подключений — каждый поток потребляет память; важны лимиты и пул соединений.
Ориентировочные требования
| Сценарий | RAM | Диски | CPU / доступность |
|---|---|---|---|
| Сайт или небольшой сервис | 16–32 ГБ | 2 × SSD RAID1 | 4–6 ядер, дамп базы |
| Нагруженный веб-бэкенд | 64–128 ГБ | NVMe под журнал + SSD RAID10 | 8–16 ядер, реплика чтения |
| Крупная база / много записи | 128–512 ГБ | NVMe RAID10 | 16–32 ядра, пара реплик |
| Отказоустойчивый кластер | по нагрузке | быстрый стор, синхронная репликация | автоматическое переключение |
innodb_buffer_pool_size обычно задают в пределах 50–70% оперативной памяти выделенного сервера; если на машине работают и другие сервисы, долю уменьшают, оставляя память ОС и приложению.
Пример расчёта: буферный пул и диски под веб-базу
База интернет-сервиса размером 400 ГБ, в пике около 300 подключений, нагрузка со значительной долей чтения, горячая часть — примерно 40% данных. Считаем память, затем диски.
innodb_buffer_pool_size ≈ 60% ≈ 76 ГБ
горячие данные ≈ 400 × 40% = 160 ГБ — НЕ помещаются полностью
Поскольку горячий набор (160 ГБ) больше буферного пула, часть чтений уходит на диск. Варианта два: увеличить RAM до 256 ГБ (буферный пул ~150 ГБ закрывает горячие данные) либо оставить 128 ГБ и оптимизировать запросы/индексы под действительно часто читаемую часть.
Приложение должно использовать пул соединений с ограниченным числом; завышенный max_connections без контроля приводит к перерасходу RAM.
- Данные — NVMe/SAS SSD RAID10, 4–8 дисков под 400 ГБ и рост.
- Redo log — отдельный NVMe, чтобы фиксация не конкурировала с чтением данных.
- Сеть — 10/25 Гбит/с под реплику чтения и бэкапы.
При преобладании записи упор смещается на число быстрых NVMe и их выносливость (TBW); реплики чтения помогают именно отчётам и выборкам, но не ускоряют запись.
Три типовых уровня решения
- 1U, Xeon E/Silver, 4–8 ядер
- 16–64 ГБ RAM
- 2–4 SSD, RAID1/10
- Одна или несколько баз с дампами
- 1–2U, 2 × Xeon Gold, 16–32 ядра
- 128–256 ГБ RAM
- NVMe журнал + SSD RAID10 данные
- Реплика чтения для отчётов
- 2–4 × Xeon Gold/Platinum
- 256 ГБ – 1 ТБ RAM
- All-flash, синхронная репликация
- Автоматическое переключение + СХД
Готовые конфигурации
Как мы работаем
Поставка для B2B
Работаем с системными интеграторами, веб-студиями, дистрибьюторами-реселлерами и участниками тендеров. Договор, экспортные документы и доставка. Гарантия на новые серверы — до 3 лет по договору с Beijing Xinchuan Technology Co., Ltd.
Частые вопросы
MySQL или MariaDB?
MariaDB — ответвление MySQL с дополнительными движками и более открытой разработкой; MySQL остаётся основным выбором в экосистеме Oracle и части корпоративных продуктов. Приложение обычно поддерживает оба, но перед миграцией проверяют совместимость.
Сколько памяти задавать под буферный пул?
На выделенном сервере — около 50–70% RAM, чтобы таблицы и индексы читались из памяти, а не с диска. Больше не нужно: остальная память нужна ОС, соединениям и временным операциям.
Что делать, если горячие данные не помещаются в пул?
Сначала оценивают фактический горячий набор: в примере это 40% от 400 ГБ = 160 ГБ. Если он стабильно больше буферного пула, увеличивают RAM до 256 ГБ либо пересматривают запросы и индексы, оставляя в памяти действительно часто читаемую часть.
Как масштабировать чтение?
К основному серверу добавляют реплики чтения и направляют на них отчёты и выборки; запись остаётся на основном сервере. Реплики не заменяют резервные копии и не защищают от ошибочных изменений.
Нужен ли отдельный диск под redo log?
На нагруженной базе — да: журнал выносят на отдельный NVMe, чтобы фиксация не конкурировала за ввод-вывод с данными. На небольших сайтах достаточно SSD с избыточностью.
Какая гарантия?
На новые серверы — до 3 лет по договору с Beijing Xinchuan Technology Co., Ltd.; диски и адаптеры фиксируем в спецификации.